RFC Errata
Found 6 records.
Status: Verified (2)
RFC 4055, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", June 2005
Note: This RFC has been updated by RFC 5756
Source of RFC: pkix (sec)
Errata ID: 1468
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2008-07-09
Verifier Name: Tim Polk
Date Verified: 2008-11-19
Section 3 says:
CAs that issue certificates with the id-RSASSA-PSS algorithm identifier SHOULD require the presence of parameters in the publicKeyAlgorithms field if the cA boolean flag is set in the basic constraints certificate extension. CAs MAY require that the parameters be present in the publicKeyAlgorithms field for end-entity certificates.
It should say:
CAs that issue certificates with the id-RSASSA-PSS algorithm identifier SHOULD require the presence of parameters in the subjectPublicKeyInfo algorithm field if the cA boolean flag is set in the basic constraints certificate extension. CAs MAY require that the parameters be present in the subjectPublicKeyInfo algorithm field for end-entity certificates.
Notes:
The correct name of the field is "subjectPublicKeyInfo algorithm field" as opposed to "publicKeyAlgorithms field". Note that this change is also included in the draft-ietf-pkix-rfc4055-update ID.
Errata ID: 1676
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-02
Verifier Name: Sean Turner
Date Verified: 2010-04-19
Section 3.1, 4.1 says:
a) Section 3.1, explanation of maskGenAlgorithm, last paragraph (2nd paragraph on page 9) b) Section 4.1, explanation of maskGenFunc, last paragraph (2nd paragraph on page 11) both say: Although mfg1SHA1Identifier is defined as the default value for this field, implementations MUST accept both the default value encoding (i.e., an absent field) and mfg1SHA1Identifier to be explicitly present in the encoding.
It should say:
both a) and b) should say: Although mgf1SHA1Identifier is defined as the default value for this field, implementations MUST accept both the default value encoding (i.e., an absent field) and mgf1SHA1Identifier to be explicitly present in the encoding.
Notes:
Rationale: 4 instances of the same character twister:
mfg1SHA1Identifier
--- ^^
mgf1SHA1Identifier
Note: "MGF" is the abbreviation of "Mask Generation Function".
Status: Held for Document Update (4)
RFC 4055, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", June 2005
Note: This RFC has been updated by RFC 5756
Source of RFC: pkix (sec)
Errata ID: 1677
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-02-02
Held for Document Update by: Tim Polk
Section 6, pg. 18 says:
rSASSA-PSS-SHA512-Identifier AlgorithmIdentifier ::= { algorithm id-RSASSA-PSS, | parameters rSSASSA-PSS-SHA512-params } ^^^^ vvvv | rSSASSA-PSS-SHA512-params RSASSA-PSS-params ::= { hashAlgorithm sha512Identifier, maskGenAlgorithm mgf1SHA512Identifier, saltLength 20, trailerField 1 }
It should say:
rSASSA-PSS-SHA512-Identifier AlgorithmIdentifier ::= { algorithm id-RSASSA-PSS, | parameters rSASSA-PSS-SHA512-params } ^^^ vvv | rSASSA-PSS-SHA512-params RSASSA-PSS-params ::= { hashAlgorithm sha512Identifier, maskGenAlgorithm mgf1SHA512Identifier, saltLength 20, trailerField 1 }
Notes:
repeated Typo; s/rSSA/rSA/
Errata ID: 2724
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2011-02-16
Held for Document Update by: Tim Polk
Section 2.1 says:
id-sha224 OBJECT IDENTIFIER ::= {{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 }
It should say:
id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 }
Notes:
There's an extra "{". This is incorrect ASN.1. I marked it as editorial because the ASN.1 module does not contain this error.
Errata ID: 5199
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bernd Eckenfels
Date Reported: 2017-12-05
Held for Document Update by: Kathleen Moriarty
Date Held: 2018-03-18
Section 4.1 says:
The pSourceFunc field identifies the source (and possibly the value) of the encoding parameters, commonly called P.
It should say:
The pSourceFunc field identifies the source (and possibly the value) of the encoding parameters, commonly called P. (Note: it is referred to as label L in [P1v2.1], and it is referred to as P throughout [P1v2.0], although the ASN.1 structures in both document use the letter “p”.)
Notes:
There is no place where P is linked to the parameter name L as used in
referenced [P1v2.1]
Per Burt Kaliski (and edited by Russ Housley):
"""
The text in Sec. 4.1 of RFC4055 including the syntax of RSAES-OAEP-params largely follows Sec. 11.2.1 of RFC2437 (PKCS #1 v2.0), which uses the term “encoding parameters P”, rather than the Sec. A.2.1 of RFC3447 (PKCS #1 v2.1), which uses the term “label L”. (RFC3560, the CMS profile for these algorithms, similarly follows RFC2437.)
RFC3447 acknowledges that “In previous versions of this specification, the term ‘encoding parameters’ was used”. Given that RFC4055 inserts “commonly called” before RFC2437’s “P”, it appears that RFC4055 is attempting to bridge between RFC3447 and RFC2437.
"""
I observe that RFC 2437, RFC 3447, and RFC 4055 all use the same ASN.1 structure for RSAES-OAEP-params. While the description of RSAES-OAEP in [P1v2.1] uses "L" instead of "P", this change in terminology did not carry through to the ASN.1 structure.
I think that this should not be classified as a technical errata. Perhaps a better text would be:
The pSourceFunc field identifies the source (and possibly the value)
of the encoding parameters, commonly called P. (Note: it is referred
to as label L in Section 7.1.1 of [P1v2.1], and it is referred to as P
throughout [P1v2.0] and Section A.2.1 of [P1v2.1].)
[P1v2.0] = RFC 2437
I don’t see an error here, so I think the corrected errata should be approved as editorial.
Errata ID: 5325
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ryan Sleevi
Date Reported: 2018-04-13
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-10-10
Section 4055 says:
If the keyUsage extension is present in a certificate conveys an RSA public key with the id-RSAES-OAEP object identifier, then the keyUsage extension MUST contain only the following values:
It should say:
If the keyUsage extension is present in a certificate that conveys an RSA public key with the id-RSAES-OAEP object identifier, then the keyUsage extension MUST contain only the following values:
Notes:
The certificate, rather than the keyUsage extension, conveys the id-RSAES-OAEP OID.
This was likely a typo based on the wording of the previous paragraph, "When a certificate conveys an RSA public key". This aligns the language with the paragraph earlier in this section, "If the keyUsage extension is present in an end-entity certificate that conveys an RSA public key".