RFC 5272, "Certificate Management over CMS (CMC)", June 2008

Note: This RFC has been updated by RFC 6402

Errata ID: 7379
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jaime Hablutzel
Date Reported: 2023-03-08

Throughout the document, when it says:

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.

It should say:

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 }

Report New Errata