RFC Errata
Found 8 records.
Status: Verified (4)
RFC 4210, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", September 2005
Note: This RFC has been updated by RFC 6712, RFC 9480, RFC 9481
Source of RFC: pkix (sec)
Errata ID: 3949
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.
Errata ID: 5201
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Edänge
Date Reported: 2017-12-12
Verifier Name: Roman Danyliw
Date Verified: 2022-02-04
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:
There is a typo in Appendix D.4 -- "MS_MAC_ALG" should be "MSG_MAC_ALG"
Errata ID: 7549
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rufus Buschart
Date Reported: 2023-06-23
Verifier Name: Roman Danyliw
Date Verified: 2023-06-23
Section 3.1.2. point 11 says:
correct RA of CA public key
It should say:
correct RA or CA public key
Notes:
From the context it is obvious that there is a typo in the original text. This claim is supported by the fact that the "r" and the "f" key are next to each other on the keyboard.
Status: Held for Document Update (4)
RFC 4210, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", September 2005
Note: This RFC has been updated by RFC 6712, RFC 9480, RFC 9481
Source of RFC: pkix (sec)
Errata ID: 5731
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Lijun Liao
Date Reported: 2019-05-22
Held for Document Update by: Roman Danyliw
Date Held: 2022-04-27
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.
Errata ID: 2615
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.
Errata ID: 7888
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sylvain Etienne
Date Reported: 2024-04-09
Held for Document Update by: RFC Editor
Date Held: 2024-04-09
Section 5.3.2. says:
An Initialization response message contains as the PKIBody an CertRepMessage data structure,
It should say:
An Initialization response message contains as the PKIBody a CertRepMessage data structure,
Notes:
typo (an > a)