RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (2)

RFC 4210, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", September 2005

Source of RFC: pkix (sec)

Errata ID: 3949
Status: Verified
Type: Editorial

Reported By: Tom Biskupic
Date Reported: 2014-04-02
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 5.3.4 says:

CertRepMessage ::= SEQUENCE {
         caPubs          [1] SEQUENCE SIZE (1..MAX) OF Certificate
                             OPTIONAL,
         response            SEQUENCE OF CertResponse
     }

It should say:

CertRepMessage ::= SEQUENCE {
         caPubs       [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
                          OPTIONAL,
         response         SEQUENCE OF CertResponse
     }

Notes:

The definition in the text is different to the one in the ASN.1 module contained in Appendix F. The correct text is assumed to be the one from Appendix F

CMPCertificate is a superset of Certificate which has one element. The new structure would allow for a new certificate type to be included. Not sure that it would ever happen.

Errata ID: 4078
Status: Verified
Type: Editorial

Reported By: Lijun Liao
Date Reported: 2014-08-11
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 5.3.4 says:

     CertOrEncCert ::= CHOICE {
         certificate     [0] Certificate,
         encryptedCert   [1] EncryptedValue
     }

It should say:

     CertOrEncCert ::= CHOICE {
         certificate     [0] CMPCertificate,
         encryptedCert   [1] EncryptedValue
     }

Notes:

The definition of CertOrEncCert in Section 5.3.4 and Appendix F of CertOrEncCert differs.

This is a change that makes no difference on the wire. This is the same issue as errata 3949.

Status: Reported (2)

RFC 4210, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", September 2005

Source of RFC: pkix (sec)

Errata ID: 5201
Status: Reported
Type: Editorial

Reported By: Simon Edänge
Date Reported: 2017-12-12

Section Appendix D.4 says:

   Initialization Response -- ip

   Field                Value

   sender               CA name
     -- the name of the CA who produced the message
   messageTime          present
     -- time at which CA produced message
   protectionAlg        MS_MAC_ALG
     -- only MAC protection is allowed for this response

It should say:

   Initialization Response -- ip

   Field                Value

   sender               CA name
     -- the name of the CA who produced the message
   messageTime          present
     -- time at which CA produced message
   protectionAlg        MSG_MAC_ALG
     -- only MAC protection is allowed for this response

Notes:

In Appendix D.2 it is denoted as MSG_MAC_ALG

Errata ID: 5731
Status: Reported
Type: Editorial

Reported By: Lijun Liao
Date Reported: 2019-05-22

Throughout the document, when it says:

N/A

It should say:

N/A

Notes:

In appendixes D.4, D.5, E.5 and E.6, the recipient field of requests and the sender field of responses are specified as "the name of the CA". It is no problem for CA which signs the CMP response.

However, as best practice, the CA's private key which is used to sign the certificates, is NOT RECOMMENDED to sign/decrypt the communication messages. In this case, another entity (private key + certificate) is used to decrypt the incoming messages and sign the outgoing ones.

The text and comment for the fields "recipient" in requests and "sender" in responses need to be corrected to the case described above. If you think the original text and comment are correct, then we need instruction on how to handle this case.

Status: Held for Document Update (2)

RFC 4210, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", September 2005

Source of RFC: pkix (sec)

Errata ID: 2615
Status: Held for Document Update
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2010-11-08
Held for Document Update by: Sean Turner

Section Appendix C says:

   -- **********
   -- * For the purposes of this specification, the ASN.1 comment
   -- * given in [CRMF] pertains not only to certTemplate, but
   -- * also to the altCertTemplate control.  That is,
   -- **********

It should say:

   -- **********
   -- * For the purposes of this specification, the ASN.1 comment
   -- * given in [CRMF] pertains not only to certTemplate, but
   -- * also to the altCertTemplate control. 
   -- **********

Errata ID: 2616
Status: Held for Document Update
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2010-11-09
Held for Document Update by: Sean Turner

Section 5.1.3.1 says:

   Note: it is RECOMMENDED that the fields of PBMParameter remain
   constant throughout the messages of a single transaction (e.g.,
   ir/ip/certConf/pkiConf) in order to reduce the overhead associated
   with PasswordBasedMac computation).

It should say:

   Note: it is RECOMMENDED that the fields of PBMParameter remain
   constant throughout the messages of a single transaction (e.g.,
   ir/ip/certConf/pkiConf) in order to reduce the overhead associated
   with PasswordBasedMac computation.

Report New Errata