RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

Source of RFC: pkix (sec)

Errata ID: 1468
Status: Verified
Type: Editorial

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

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: Reported (1)

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

Source of RFC: pkix (sec)

Errata ID: 5325
Status: Reported
Type: Editorial

Reported By: Ryan Sleevi
Date Reported: 2018-04-13

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

Status: Held for Document Update (3)

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

Source of RFC: pkix (sec)

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

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

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

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.

Report New Errata