$Revision: 2.0 $
December, 2005
Copyright (C) 2005 RSA Laboratories, a division of RSA Security
Inc. License to copy this document is granted provided that it is
identified as "RSA Security Inc. Public-Key Cryptography Standards
(PKCS)" in all material mentioning or referencing this document.
This note lists known errors in PKCS #1: RSA Cryptography Standard,
version 2.1, and should be incorporated into that version. Some of
these errors were previously published in PKCS #1 v2.1 Errata and some
were previously published as part of IETF RFC 3447 Errata.
-Section 5.1.2: Note should refer to step 2.b rather than 2.a.
-Section 5.2.1: Note should refer to step 2.b rather than 2.a.
-Section 7.1.1: {RSAES-OAEP} Encryption Operation - page 21
Figure 1 does not represent correctly DB as specified in
step 2.c. on page 20
- Modify Figure 1 from:
+----------+---------+-------+
DB = | lHash | PS | M |
+----------+---------+-------+
|
+----------+ V
| seed |--> MGF --->xor
+----------+ |
| |
+--+ V |
|00| xor <----- MGF <-----|
+--+ | |
| | |
V V V
+--+----------+----------------------------+
EM = |00|maskedSeed| maskedDB |
+--+----------+----------------------------+
-to:
+----------+--------+--+-------+
DB = | lHash | PS |01| M |
+----------+--------+--+-------+
|
+----------+ V
| seed |--> MGF ---> xor
+----------+ |
| |
+--+ V |
|00| xor <----- MGF <-----|
+--+ | |
| | |
V V V
+--+----------+------------------------------+
EM = |00|maskedSeed| maskedDB |
+--+----------+------------------------------+
-Section "8.2.2 {RSASSA-PKCS1-v1_5} Signature verification
-Operation"
-In 'step 2.c.', in fact "EM" is computed, not "EM'" -- as stated
-in the text; see also 'step 3.' below.
- Therefore replace:
c. Convert the message representative m to an encoded message
EM of length k octets (see Section 4.1):
EM' = I2OSP (m, k).
-by:
c. Convert the message representative m to an encoded message
EM of length k octets (see Section 4.1):
EM = I2OSP (m, k).
-Section B.1: Hash functions
-The new "Secure Hash Standard", FIPS Pub 180-2 has been published
-on "2002 August 1" and became "effective on February 1, 2003".
-Therefore, in the first sentence of the second paragraph Appendix B.1
-replace:
Six hash functions are given as examples for the encoding methods
in this document: MD2 [33], MD5 [41], SHA-1 [38], and the
proposed algorithms SHA-256, SHA-384, and SHA-512 [39].
-by:
Six hash functions are given as examples for the encoding methods
in this document: MD2 [33], MD5 [41], and the algorithms SHA-1,
SHA-256, SHA-384, and SHA-512 [38].
-In the NIST parameters field definition for the SHA algorithms
-implementations containing a SHA algorithm MUST accept
-AlgorithmIdentifier values both without parameters and with NULL
-parameters.
-Therefore to align PKCS #1 v2.1 with the NIST definitions in the first
-paragraph following the ASN.1 statements replace the text:
The parameters field associated with these OIDs in a value of
type AlgorithmIdentifier shall have a value of type NULL.
-with the text:
The parameters field associated with id-md2 and id-md5 in a value of
type AlgorithmIdentifier shall have a value of type NULL.
The parameters field associated with id-sha1, id-sha256, id-sha384,
and id-sha512 should generally be omitted, but if present, shall have
a value of type NULL.
This is to align with the definitions originally promulgated by NIST.
For the SHA algorithms, implementations MUST accept
AlgorithmIdentifier values both without parameters and with NULL
parameters.
Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5
(see 9.2), the parameters field associated with id-sha1, id-sha256,
id-sha384 and id-sha512 SHALL have a value of type NULL. This is to
maintain compatibility with existing implementations and with the
numeric information values already published for EMSA-PKCS1-V1.5
which are also reflected in IEEE 1363a-2004[27].
-Section C: After the definition of PKCS1-v1_5 DigestAlgorithms, add
the text
-- When id-md2 and id-md5 are used in an AlgorithmIdentifier the
-- parameters field SHALL have a value of type NULL.
-- When id-sha1, id-sha256, id-sha384 and id-sha512 are used in an
-- AlgorithmIdentifier the parameters (which are optional) SHOULD
-- be omitted, but if present, SHALL have a value of type NULL.
-- However, implementations MUST accept AlgorithmIdentifier values
-- both without parameters and with NULL parameters.
Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5
(see 9.2), the parameters field associated with id-sha1, id-sha256,
id-sha384 and id-sha512 SHALL have a value of type NULL. This is to
maintain compatibility with existing implementations and with the
numeric information values already published for EMSA-PKCS1-V1.5
which are also reflected in IEEE 1363a-2004[27].
-Also, although not errors, the references should be updated as
-follows to reflect new publication data:
[25] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002. Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[27] IEEE 1363a-2004: Standard Specifications For Public Key
Cryptography - Amendment 1: Additional Techniques, 2004,
Available from http://grouper.ieee.org/groups/1363/P1363a/
[32] J. Jonsson and B. Kaliski. On the Security of RSA Encryption
in TLS. In M. Yung, editor, Advances in Cryptology - CRYPTO
2002, vol. 2442 of Lecture Notes in Computer Science, pp. 127 -
142. Springer Verlag, 2002.
[38] National Institute of Standards and Technology (NIST).
FIPS Publication 180-2: Secure Hash Standard. February
2002.
-Reference [39] should be deleted (it is superseeded by the updated [38]).
December, 2005
Copyright (C) 2005 RSA Laboratories, a division of RSA Security
Inc. License to copy this document is granted provided that it is
identified as "RSA Security Inc. Public-Key Cryptography Standards
(PKCS)" in all material mentioning or referencing this document.
This note lists known errors in PKCS #1: RSA Cryptography Standard,
version 2.1, and should be incorporated into that version. Some of
these errors were previously published in PKCS #1 v2.1 Errata and some
were previously published as part of IETF RFC 3447 Errata.
-Section 5.1.2: Note should refer to step 2.b rather than 2.a.
-Section 5.2.1: Note should refer to step 2.b rather than 2.a.
-Section 7.1.1: {RSAES-OAEP} Encryption Operation - page 21
Figure 1 does not represent correctly DB as specified in
step 2.c. on page 20
- Modify Figure 1 from:
+----------+---------+-------+
DB = | lHash | PS | M |
+----------+---------+-------+
|
+----------+ V
| seed |--> MGF --->xor
+----------+ |
| |
+--+ V |
|00| xor <----- MGF <-----|
+--+ | |
| | |
V V V
+--+----------+----------------------------+
EM = |00|maskedSeed| maskedDB |
+--+----------+----------------------------+
-to:
+----------+--------+--+-------+
DB = | lHash | PS |01| M |
+----------+--------+--+-------+
|
+----------+ V
| seed |--> MGF ---> xor
+----------+ |
| |
+--+ V |
|00| xor <----- MGF <-----|
+--+ | |
| | |
V V V
+--+----------+------------------------------+
EM = |00|maskedSeed| maskedDB |
+--+----------+------------------------------+
-Section "8.2.2 {RSASSA-PKCS1-v1_5} Signature verification
-Operation"
-In 'step 2.c.', in fact "EM" is computed, not "EM'" -- as stated
-in the text; see also 'step 3.' below.
- Therefore replace:
c. Convert the message representative m to an encoded message
EM of length k octets (see Section 4.1):
EM' = I2OSP (m, k).
-by:
c. Convert the message representative m to an encoded message
EM of length k octets (see Section 4.1):
EM = I2OSP (m, k).
-Section B.1: Hash functions
-The new "Secure Hash Standard", FIPS Pub 180-2 has been published
-on "2002 August 1" and became "effective on February 1, 2003".
-Therefore, in the first sentence of the second paragraph Appendix B.1
-replace:
Six hash functions are given as examples for the encoding methods
in this document: MD2 [33], MD5 [41], SHA-1 [38], and the
proposed algorithms SHA-256, SHA-384, and SHA-512 [39].
-by:
Six hash functions are given as examples for the encoding methods
in this document: MD2 [33], MD5 [41], and the algorithms SHA-1,
SHA-256, SHA-384, and SHA-512 [38].
-In the NIST parameters field definition for the SHA algorithms
-implementations containing a SHA algorithm MUST accept
-AlgorithmIdentifier values both without parameters and with NULL
-parameters.
-Therefore to align PKCS #1 v2.1 with the NIST definitions in the first
-paragraph following the ASN.1 statements replace the text:
The parameters field associated with these OIDs in a value of
type AlgorithmIdentifier shall have a value of type NULL.
-with the text:
The parameters field associated with id-md2 and id-md5 in a value of
type AlgorithmIdentifier shall have a value of type NULL.
The parameters field associated with id-sha1, id-sha256, id-sha384,
and id-sha512 should generally be omitted, but if present, shall have
a value of type NULL.
This is to align with the definitions originally promulgated by NIST.
For the SHA algorithms, implementations MUST accept
AlgorithmIdentifier values both without parameters and with NULL
parameters.
Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5
(see 9.2), the parameters field associated with id-sha1, id-sha256,
id-sha384 and id-sha512 SHALL have a value of type NULL. This is to
maintain compatibility with existing implementations and with the
numeric information values already published for EMSA-PKCS1-V1.5
which are also reflected in IEEE 1363a-2004[27].
-Section C: After the definition of PKCS1-v1_5 DigestAlgorithms, add
the text
-- When id-md2 and id-md5 are used in an AlgorithmIdentifier the
-- parameters field SHALL have a value of type NULL.
-- When id-sha1, id-sha256, id-sha384 and id-sha512 are used in an
-- AlgorithmIdentifier the parameters (which are optional) SHOULD
-- be omitted, but if present, SHALL have a value of type NULL.
-- However, implementations MUST accept AlgorithmIdentifier values
-- both without parameters and with NULL parameters.
Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5
(see 9.2), the parameters field associated with id-sha1, id-sha256,
id-sha384 and id-sha512 SHALL have a value of type NULL. This is to
maintain compatibility with existing implementations and with the
numeric information values already published for EMSA-PKCS1-V1.5
which are also reflected in IEEE 1363a-2004[27].
-Also, although not errors, the references should be updated as
-follows to reflect new publication data:
[25] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002. Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[27] IEEE 1363a-2004: Standard Specifications For Public Key
Cryptography - Amendment 1: Additional Techniques, 2004,
Available from http://grouper.ieee.org/groups/1363/P1363a/
[32] J. Jonsson and B. Kaliski. On the Security of RSA Encryption
in TLS. In M. Yung, editor, Advances in Cryptology - CRYPTO
2002, vol. 2442 of Lecture Notes in Computer Science, pp. 127 -
142. Springer Verlag, 2002.
[38] National Institute of Standards and Technology (NIST).
FIPS Publication 180-2: Secure Hash Standard. February
2002.
-Reference [39] should be deleted (it is superseeded by the updated [38]).