RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 8 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 (4)

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: 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.

Report New Errata



Advanced Search