RFC Errata
Found 10 records.
Status: Verified (2)
RFC 5272, "Certificate Management over CMS (CMC)", June 2008
Note: This RFC has been updated by RFC 6402
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.
Errata ID: 7627
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Piotr Popis
Date Reported: 2023-09-04
Verifier Name: RFC Editor
Date Verified: 2023-09-05
Section 6.7 says:
See Section 5 of [CRMF] for a detailed discussion of POP.
It should say:
See Section 4 of [CRMF] for a detailed discussion of POP.
Notes:
This is a purely editorial change.
Status: Reported (6)
RFC 5272, "Certificate Management over CMS (CMC)", June 2008
Note: This RFC has been updated by RFC 6402
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: 7628
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Piotr Popis
Date Reported: 2023-09-04
Section 3.2.1.3.1. says:
AuthenticatedData content type is used by this document for: The id-cmc-authData control (Section 6.16), and The top-level wrapper in environments where an encryption-only key is being certified.
It should say:
AuthenticatedData content type is used by this document for: The id-cmc-authData control (Section 6.16), and The top-level wrapper in environments where an encryption-only key is being certified or where a shared-secret exists, but a PKI-based trust (needed for SignedData) has not yet been established.
Notes:
For consistency with the same paragraph and the rest of the document.
Errata ID: 7629
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Piotr Popis
Date Reported: 2023-09-04
Section 3.2.1.3.4. says:
For the PKI Response, SignedData allows the server to sign the returning data, if any exists, and to carry the certificates and CRLs corresponding to the PKI Request. If no data is being returned beyond the certificates and CRLs, the EncapsulatedInfo and SignerInfo fields are not populated.
It should say:
For the PKI Response, SignedData allows the server to sign the returning data, if any exists, and to carry the certificates and CRLs corresponding to the PKI Request. If no data is being returned beyond the certificates and CRLs, the eContent field in the EncapsulatedContentInfo and SignerInfo fields are not populated. Only if the server is unable to sign the response (and unable to use any RecipientInfo options of the AuthenticatedData content type), and at the same time it should send a negative response, Full PKI Response SignedData type containing a CMC Status Info control MUST be returned using a CMCFailInfo with a value of internalCAError and a bodyPartID of 0, and the eContent field in the EncapsulatedContentInfo as well as SignerInfo fields MUST not be populated.
Notes:
This change is needed to comply with Errata ID 7379 (the first para) and covers the case (the second para) where the server shall send a negative response (Full PKI Response) as it is unable to sign the certificate and at the same time it is unable to sign the response itself (e.g. due to a loss in connection to the HSM).
Errata ID: 8027
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Wallace
Date Reported: 2024-07-11
Section Appendix B says:
recipientInfos.riid.issuerSerialNumber = <NULL, 201>
It should say:
recipientInfos.riid.issuerSerialNumber = <NULL-DN, 201>
Notes:
In ASN.1, NULL is a type that is encoded as 0x0500. NULL is not appropriate in this context because the corresponding field is defined as a Name. NULL-DN is defined in RFC4210 as "a zero-length SEQUENCE OF RelativeDistinguishedNames". A NULL-DN is encoded as 0x3000. This is almost certainly what was intended here. Note, RFC4210 is not referenced by RFC5272 currently, so that would need to be changed as well to reference NULL-DN.
Errata ID: 8137
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David von Oheimb
Date Reported: 2024-10-12
Section C.1 says:
NoSignatureValue contains the hash of the certification request.
It should say:
NoSignatureValue contains the SHA-1 hash value of the certification request. The hash value given by NoSignatureValue SHOULD be ignored.
Notes:
The hash value was not sufficiently defined because the choice of the hash algorithm was not specified.
At that time presumably the use of SHA-1 was implied.
I suggest requiring SHA-1 here simply for backward compatibility.
From today's perspective more flexibility may be demanded and SHA-1 likely no more is the best choice.
Anyway I see no real value in NoSignatureValue (pun intended), so it should not matter.
For this reason I propose ignoring the hash value.
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
Note: This RFC has been updated by RFC 6402
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
Note: This RFC has been updated by RFC 6402
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.