PKCS #1 v2.1 Errata ------------------- $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]).