Re: [Technical Errata Reported] RFC5272 (7379)

I believe this is correct and should be verified.  In the examples I’ve seen of a certs-only message, the encapContentInfo.eContentType field is set to id-data and the signerInfo is absent.

> On Mar 8, 2023, at 13:51, RFC Errata System <[email protected]> wrote:
> 
> The following errata report has been submitted for RFC5272,
> "Certificate Management over CMS (CMC)".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7379
> 
> --------------------------------------
> Type: Technical
> Reported by: Jaime Hablutzel <[email protected]>
> 
> Section: GLOBAL
> 
> Original Text
> -------------
> 2.2. Protocol Requests/Responses says:
> 
>> Simple PKI Response
>> ...
>> encapsulatedContentInfo is absent.
> 
> 4.1. Simple PKI Response says:
> 
>> The Simple PKI Response consists of a SignedData with no EncapsulatedContentInfo
> and no SignerInfo.
> 
> Corrected Text
> --------------
> 2.2. Protocol Requests/Responses should say:
> 
>> Simple PKI Response
>> ...
>> encapContentInfo eContent field is absent.
> 
> 4.1. Simple PKI Response should say:
> 
>> The Simple PKI Response consists of a SignedData with no eContent field in the EncapsulatedContentInfo and no SignerInfo.
> 
> 
> Notes
> -----
> This change is required for consistency with RFC 8551:
> 
>> 3.8.  Creating a Certificate Management Message
>>   The certificate management message or MIME entity is used to
>>   transport certificates and/or Certificate Revocation Lists (CRLs),
>>   such as in response to a registration request.
>>   Step 1.  The certificates and/or CRLs are made available to the CMS
>>            generating process that creates a CMS object of type
>>            SignedData.  The SignedData encapContentInfo eContent field
>>            MUST be absent, and the signerInfos field MUST be empty.
> 
> Additionally, RFC 3852 doesn't allow for the absence of the EncapsulatedContentInfo in a SignedData:
> 
>> The signed-data content type shall have ASN.1 type SignedData:
>> SignedData ::= SEQUENCE {
>> version CMSVersion,
>> digestAlgorithms DigestAlgorithmIdentifiers,
>> encapContentInfo EncapsulatedContentInfo,
>> certificates [0] IMPLICIT CertificateSet OPTIONAL,
>> crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
>> signerInfos SignerInfos }
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC5272 (draft-ietf-pkix-2797-bis-07)
> --------------------------------------
> Title               : Certificate Management over CMS (CMC)
> Publication Date    : June 2008
> Author(s)           : J. Schaad, M. Myers
> Category            : PROPOSED STANDARD
> Source              : Public-Key Infrastructure (X.509)
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix