RFC Errata
Found 5 records.
Status: Verified (1)
RFC 5272, "Certificate Management over CMS (CMC)", June 2008
Source of RFC: pkix (sec)
Errata ID: 2063
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-03-04
Verifier Name: Tim Polk
Date Verified: 2010-04-28
Section Appendix A says:
EnrollmentMessageSyntax
{ iso(1) identified-organization(3) dod(4) internet(1)
security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) }
It should say:
EnrollmentMessageSyntax
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) }
Notes:
ASN.1 Object Identifiers are assigned based on the number not the name, this means that the current module is assigned in a name space that is not under our control.
Status: Reported (2)
RFC 5272, "Certificate Management over CMS (CMC)", June 2008
Source of RFC: pkix (sec)
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 }
Errata ID: 4775
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kees-Jan Hermans
Date Reported: 2016-08-11
Section B.1 says:
eContentType = id-ct-PKIData
It should say:
eContentType = id-cct-PKIData
Notes:
This is repeated a few times throughout Appendix B.
Status: Held for Document Update (1)
RFC 5272, "Certificate Management over CMS (CMC)", June 2008
Source of RFC: pkix (sec)
Errata ID: 2731
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2011-02-23
Held for Document Update by: Tim Polk
Section 2.2 says:
Full PKI Response ------------------------ +----------------+ | CMS ContentInfo| | CMS SignedData | | or Auth Data | | object | +----------------+--------+ | | | PKIResponseBody |
It should say:
Full PKI Response ------------------------ +----------------+ | CMS ContentInfo| | CMS SignedData | | or Auth Data | | object | +----------------+--------+ | | | PKIResponse |
Notes:
PKIResponse should be PKIResponse. It's the name of the content type. PKIResponseBody only appears once in this RFC and it's in Figure 2.
Status: Rejected (1)
RFC 5272, "Certificate Management over CMS (CMC)", June 2008
Source of RFC: pkix (sec)
Errata ID: 4186
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Pierce Leonberger
Date Reported: 2014-11-18
Rejected by: Kathleen Moriarty
Date Rejected: 2015-03-31
Section 3.2.1.3.2 says:
The Data content type allows for general transport of unstructured
data.
The Data content type is used by this document for:
Holding the encrypted random value y for POP proof in the
encrypted POP control (see Section 6.7).
It should say:
See Notes
Notes:
It's invalid for the encoding of an ANY or OpenType to have "unstructured" data. See X.690 section 8.15:
8.15 Encoding of an open type
The value of an open type is also a value of some (other) ASN.1 type. The encoding of such a value shall be the complete encoding herein specified for the value considered as being of that other type.
Note there's similar wording in X.209 section 21 for ANY:
21 Encoding of a value of the ANY type
The encoding of an ANY type shall be the complete encoding specified in this Recommendation for the type of the value of the ANY type.
--VERIFIER NOTES--
The Data content type being referenced here is the Data content type from CMS. This type is defined as using an OCTET STRING wrapper around the data. Therefore unstructured data is not being placed at the ASN.1 level and the referenced text does not apply.