RFC Errata System
2018-03-18 15:29:13 UTC
The following errata report has been held for document update
for RFC4055, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5199
--------------------------------------
Status: Held for Document Update
Type: Editorial
Reported by: Bernd Eckenfels <bernd-***@eckenfels.net>
Date Reported: 2017-12-05
Held by: Kathleen Moriarty (IESG)
Section: 4.1
Original Text
-------------
The pSourceFunc field identifies the source (and possibly the value)
of the encoding parameters, commonly called P.
Corrected Text
--------------
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.
--------------------------------------
RFC4055 (draft-ietf-pkix-rsa-pkalgs-03)
--------------------------------------
Title : Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Publication Date : June 2005
Author(s) : J. Schaad, B. Kaliski, R. Housley
Category : PROPOSED STANDARD
Source : Public-Key Infrastructure (X.509)
Area : Security
Stream : IETF
Verifying Party : IESG
for RFC4055, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5199
--------------------------------------
Status: Held for Document Update
Type: Editorial
Reported by: Bernd Eckenfels <bernd-***@eckenfels.net>
Date Reported: 2017-12-05
Held by: Kathleen Moriarty (IESG)
Section: 4.1
Original Text
-------------
The pSourceFunc field identifies the source (and possibly the value)
of the encoding parameters, commonly called P.
Corrected Text
--------------
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.
--------------------------------------
RFC4055 (draft-ietf-pkix-rsa-pkalgs-03)
--------------------------------------
Title : Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Publication Date : June 2005
Author(s) : J. Schaad, B. Kaliski, R. Housley
Category : PROPOSED STANDARD
Source : Public-Key Infrastructure (X.509)
Area : Security
Stream : IETF
Verifying Party : IESG