Network Working Group J. Schaad Request for Comments: 4055 Soaring Hawk Consulting Updates: 3279 B. Kaliski Category: Standards Track RSA Laboratories R. Housley Vigil Security June 2005 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. Schaad, et al. Standards Track [Page 1]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005 Table of Contents 1. Introduction ....................................................2 1.1. Terminology ................................................3 1.2. RSA Public Keys ............................................3 2. Common Functions ................................................5 2.1. One-way Hash Functions .....................................5 2.2. Mask Generation Functions ..................................6 3. RSASSA-PSS Signature Algorithm ..................................7 3.1. RSASSA-PSS Public Keys .....................................8 3.2. RSASSA-PSS Signature Values ...............................10 3.3. RSASSA-PSS Signature Parameter Validation .................10 4. RSAES-OAEP Key Transport Algorithm .............................10 4.1. RSAES-OAEP Public Keys ....................................11 5. PKCS #1 Version 1.5 Signature Algorithm ........................13 6. ASN.1 Module ...................................................14 7. References .....................................................20 7.1. Normative References ......................................20 7.2. Informative References ....................................21 8. Security Considerations ........................................21 9. IANA Considerations ............................................24 1. Introduction This document supplements RFC 3279 [PKALGS]. This document describes the conventions for using the RSASSA-PSS signature algorithm and the RSAES-OAEP key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI) [PROFILE]. Both of these RSA-based algorithms are specified in [P1v2.1]. The algorithm identifiers and associated parameters for subject public keys that employ either of these algorithms, and the encoding format for RSASSA-PSS signatures are specified. Also, the algorithm identifiers for using the SHA-224, SHA-256, SHA-384, and SHA-512 one-way hash functions with the PKCS #1 version 1.5 signature algorithm [P1v1.5] are specified. This specification supplements RFC 3280 [PROFILE] which profiles the X.509 Certificates and Certificate Revocation Lists (CRLs) for use in the Internet. This specification extends the list of algorithms discussed in RFC 3279 [PKALGS]. The X.509 Certificate and CRL definitions use ASN.1 [X.208-88], the Basic Encoding Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER) [X.509-88]. This specification defines the contents of the signatureAlgorithm, signatureValue, signature, and subjectPublicKeyInfo fields within Internet X.509 Certificates and CRLs. For each algorithm, the appropriate alternatives for the keyUsage certificate extension are provided. Schaad, et al. Standards Track [Page 2]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [STDWORDS]. 1.2. RSA Public Keys RFC 3280 [PROFILE] specifies the profile for using X.509 Certificates in Internet applications. When an RSA public key is used for RSASSA-PSS digital signatures or RSAES-OAEP key transport, the conventions specified in this section augment RFC 3280. Traditionally, the rsaEncryption object identifier is used to identify RSA public keys. However, to implement all of the recommendations described in Security Considerations (Section 8), the certificate user needs to be able to determine the form of digital signature or key transport that the RSA private key owner associates with the public key. The rsaEncryption object identifier continues to identify the subject public key when the RSA private key owner does not wish to limit the use of the public key exclusively to either RSASSA-PSS or RSAES-OAEP. In this case, the rsaEncryption object identifier MUST be used in the algorithm field within the subject public key information, and the parameters field MUST contain NULL. rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } Further discussion of the conventions associated with use of the rsaEncryption object identifier can be found in RFC 3279 (see [PKALGS], Section 2.3.1). When the RSA private key owner wishes to limit the use of the public key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object identifier MUST be used in the algorithm field within the subject public key information, and, if present, the parameters field MUST contain RSASSA-PSS-params. The id-RSASSA-PSS object identifier value and the RSASSA-PSS-params syntax are fully described in Section 3. When the RSA private key owner wishes to limit the use of the public key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object identifier MUST be used in the algorithm field within the subject public key information, and, if present, the parameters field MUST contain RSAES-OAEP-params. The id-RSAES-OAEP object identifier value and the RSAES-OAEP-params syntax are fully described in Section 4. Schaad, et al. Standards Track [Page 3]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005 Note: It is not possible to restrict the use of a key to a set of algorithms (i.e., RSASSA-PSS and RSAES-OAEP). Regardless of the object identifier used, the RSA public key is encoded in the same manner in the subject public key information. The RSA public key MUST be encoded using the type RSAPublicKey type: RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER } -- e Here, the modulus is the modulus n, and publicExponent is the public exponent e. The DER encoded RSAPublicKey is carried in the subjectPublicKey BIT STRING within the subject public key information. The intended application for the key MAY be indicated in the keyUsage certificate extension (see [PROFILE], Section 4.2.1.3). If the keyUsage extension is present in an end-entity certificate that conveys an RSA public key with the id-RSASSA-PSS object identifier, then the keyUsage extension MUST contain one or both of the following values: nonRepudiation; and digitalSignature. If the keyUsage extension is present in a certification authority certificate that conveys an RSA public key with the id-RSASSA-PSS object identifier, then the keyUsage extension MUST contain one or more of the following values: nonRepudiation; digitalSignature; keyCertSign; and cRLSign. When a certificate conveys an RSA public key with the id-RSASSA-PSS object identifier, the certificate user MUST only use the certified RSA public key for RSASSA-PSS operations, and, if RSASSA-PSS-params is present, the certificate user MUST perform those operations using the one-way hash function, mask generation function, and trailer field identified in the subject public key algorithm identifier parameters within the certificate. Schaad, et al. Standards Track [Page 4]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005 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: keyEncipherment; and dataEncipherment. However, both keyEncipherment and dataEncipherment SHOULD NOT be present. When a certificate that conveys an RSA public key with the id-RSAES-OAEP object identifier, the certificate user MUST only use the certified RSA public key for RSAES-OAEP operations, and, if RSAES-OAEP-params is present, the certificate user MUST perform those operations using the one-way hash function and mask generation function identified in the subject public key algorithm identifier parameters within the certificate. 2. Common Functions The RSASSA-PSS signature and the RSAES-OAEP key transport algorithms make use of one-way hash functions and mask generation functions. 2.1. One-way Hash Functions PKCS #1 version 2.1 [P1v2.1] supports four one-way hash functions for use with the RSASSA-PSS signature algorithm and the RSAES-OAEP key transport algorithm: SHA-1, SHA-256, SHA-384, and SHA-512 [SHA2]. This document adds support for SHA-224 [SHA-224] with both the RSASSA-PSS and the RSAES-OAEP algorithms. While support for additional one-way hash functions could be added in the future, no other one-way hash functions are supported by this specification. These one-way hash functions are identified by the following object identifiers: id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 } id-sha224 OBJECT IDENTIFIER ::= {{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 } id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 } id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 } Schaad, et al. Standards Track [Page 5]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 } There are two possible encodings for the AlgorithmIdentifier parameters field associated with these object identifiers. The two alternatives arise from the loss of the OPTIONAL associated with the algorithm identifier parameters when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax. Later the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history some implementations encode parameters as a NULL element while others omit them entirely. The correct encoding is to omit the parameters field; however, when RSASSA-PSS and RSAES-OAEP were defined, it was done using the NULL parameters rather than absent parameters. All implementations MUST accept both NULL and absent parameters as legal and equivalent encodings. To be clear, the following algorithm identifiers are used when a NULL parameter MUST be present: sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL } sha224Identifier AlgorithmIdentifier ::= { id-sha224, NULL } sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL } sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL } sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL } 2.2. Mask Generation Functions One mask generation function is used with the RSASSA-PSS signature algorithm and the RSAES-OAEP key transport algorithm: MGF1 [P1v2.1]. No other mask generation functions are supported by this specification. MGF1 is identified by the following object identifier: id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } The parameters field associated with id-mgf1 MUST have a hashAlgorithm value which identifies the hash function being used with MGF1. This value MUST be sha1Identifier, sha224Identifier, sha256Identifier, sha384Identifier, or sha512Identifier, as specified in Section 2.1. Implementations MUST support the default value, sha1Identifier, and MAY support the other four values. Schaad, et al. Standards Track [Page 6]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005 The following algorithm identifiers have been assigned for each of these alternatives: mgf1SHA1Identifier AlgorithmIdentifier ::= { id-mgf1, sha1Identifier } mgf1SHA224Identifier AlgorithmIdentifier ::= { id-mgf1, sha224Identifier } mgf1SHA256Identifier AlgorithmIdentifier ::= { id-mgf1, sha256Identifier } mgf1SHA384Identifier AlgorithmIdentifier ::= { id-mgf1, sha384Identifier } mgf1SHA512Identifier AlgorithmIdentifier ::= { id-mgf1, sha512Identifier } 3. RSASSA-PSS Signature Algorithm This section describes the conventions for using the RSASSA-PSS signature algorithm with the Internet X.509 Certificate and CRL profile [PROFILE]. The RSASSA-PSS signature algorithm is specified in PKCS #1 version 2.1 [P1v2.1]. The five one-way hash functions discussed in Section 2.1 and the one mask generation function discussed in Section 2.2 can be used with RSASSA-PSS. 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. CAs that use the RSASSA-PSS algorithm for signing certificates SHOULD include RSASSA-PSS-params in the subjectPublicKeyInfo algorithm parameters in their own certificates. CAs that use the RSASSA-PSS algorithm for signing certificates or CRLs MUST include RSASSA-PSS- params in the signatureAlgorithm parameters in the TBSCertificate or TBSCertList structures. Entities that validate RSASSA-PSS signatures MUST support SHA-1. They MAY also support any other one-way hash functions in Section 2.1. The data to be signed (e.g., the one-way hash function output value) is formatted for the signature algorithm to be used. Then, a private key operation (e.g., RSA decryption) is performed to generate the signature value. This signature value is then ASN.1 encoded as a BIT STRING and included in the Certificate or CertificateList in the signatureValue field. Section 3.2 specifies the format of RSASSA-PSS signature values. Schaad, et al. Standards Track [Page 7]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005 3.1. RSASSA-PSS Public Keys When RSASSA-PSS is used in an AlgorithmIdentifier, the parameters MUST employ the RSASSA-PSS-params syntax. The parameters may be either absent or present when used as subject public key information. The parameters MUST be present when used in the algorithm identifier associated with a signature value. When signing, it is RECOMMENDED that the parameters, except for possibly saltLength, remain fixed for all usages of a given RSA key pair. id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1Identifier, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1Identifier, saltLength [2] INTEGER DEFAULT 20, trailerField [3] INTEGER DEFAULT 1 } The fields of type RSASSA-PSS-params have the following meanings: hashAlgorithm The hashAlgorithm field identifies the hash function. It MUST be one of the algorithm identifiers listed in Section 2.1, and the default hash function is SHA-1. Implementations MUST support SHA-1 and MAY support any of the other one-way hash functions listed in Section 2.1. Implementations that perform signature generation MUST omit the hashAlgorithm field when SHA-1 is used, indicating that the default algorithm was used. Implementations that perform signature validation MUST recognize both the sha1Identifier algorithm identifier and an absent hashAlgorithm field as an indication that SHA-1 was used. maskGenAlgorithm The maskGenAlgorithm field identifies the mask generation function. The default mask generation function is MGF1 with SHA-1. For MGF1, it is strongly RECOMMENDED that the underlying hash function be the same as the one identified by hashAlgorithm. Implementations MUST support MGF1. MGF1 requires a one-way hash function that is identified in the parameters field of the MGF1 algorithm identifier. Implementations MUST support SHA-1 and MAY support any of the Schaad, et al. Standards Track [Page 8]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005 other one-way hash functions listed in section Section 2.1. The MGF1 algorithm identifier is comprised of the id-mgf1 object identifier and a parameter that contains the algorithm identifier of the one-way hash function employed with MGF1. The SHA-1 algorithm identifier is comprised of the id-sha1 object identifier and an (optional) parameter of NULL. Implementations that perform signature generation MUST omit the maskGenAlgorithm field when MGF1 with SHA-1 is used, indicating that the default algorithm was used. 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. saltLength The saltLength field is the octet length of the salt. For a given hashAlgorithm, the recommended value of saltLength is the number of octets in the hash value. Unlike the other fields of type RSASSA-PSS-params, saltLength does not need to be fixed for a given RSA key pair; a different value could be used for each RSASSA-PSS signature generated. trailerField The trailerField field is an integer. It provides compatibility with IEEE Std 1363a-2004 [