Request for Comments: 4055 Soaring Hawk Consulting
Category: Standards Track B. Kaliski
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.
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.
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.
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.
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 }
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.
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.
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
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 [P1363A]. The value
MUST be 1, which represents the trailer field with hexadecimal
value 0xBC. Other trailer fields, including the trailer field
composed of HashID concatenated with 0xCC that is specified in
IEEE Std 1363a, are not supported. Implementations that
perform signature generation MUST omit the trailerField field,
indicating that the default trailer field value was used.
Implementations that perform signature validation MUST
recognize both a present trailerField field with value 1 and an
absent trailerField field.
If the default values of the hashAlgorithm, maskGenAlgorithm, and
trailerField fields of RSASSA-PSS-params are used, then the algorithm
identifier will have the following value:
rSASSA-PSS-Default-Identifier AlgorithmIdentifier ::= {
id-RSASSA-PSS, rSASSA-PSS-Default-Params }
rSASSA-PSS-Default-Params RSASSA-PSS-Params ::= {
sha1Identifier, mgf1SHA1Identifier, 20, 1}
3.2. RSASSA-PSS Signature Values
The output of the RSASSA-PSS signature algorithm is an octet string,
which has the same length in octets as the RSA modulus n.
Signature values in CMS [CMS] are represented as octet strings, and
the output is used directly. However, signature values in
certificates and CRLs [PROFILE] are represented as bit strings, and
conversion is needed.
To convert a signature value to a bit string, the most significant
bit of the first octet of the signature value SHALL become the first
bit of the bit string, and so on through the least significant bit of
the last octet of the signature value, which SHALL become the last
bit of the bit string.
3.3. RSASSA-PSS Signature Parameter Validation
Three possible parameter validation scenarios exist for RSASSA-PSS
signature values.
1. The key is identified by the rsaEncryption algorithm identifier.
In this case no parameter validation is needed.
2. The key is identified by the id-RSASSA-PSS signature algorithm
identifier, but the parameters field is absent. In this case no
parameter validation is needed.
3. The key is identified by the id-RSASSA-PSS signature algorithm
identifier and the parameters are present. In this case all
parameters in the signature structure algorithm identifier MUST
match the parameters in the key structure algorithm identifier
except the saltLength field. The saltLength field in the
signature parameters MUST be greater or equal to that in the key
parameters field.
4. RSAES-OAEP Key Transport Algorithm
This section describes the conventions for using the RSAES-OAEP key
transport algorithm with the Internet X.509 Certificate and CRL
profile [PROFILE]. RSAES-OAEP 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 RSAES-OAEP. Conforming CAs and applications MUST support
RSAES-OAEP key transport algorithm using SHA-1. The other four one-
way hash functions MAY also be supported.
CAs that issue certificates with the id-RSAES-OAEP algorithm
identifier SHOULD require the presence of parameters in the
publicKeyAlgorithms field for all certificates. Entities that use a
certificate with a publicKeyAlgorithm value of id-RSA-OAEP where the
parameters are absent SHOULD use the default set of parameters for
RSAES-OAEP-params. Entities that use a certificate with a
publicKeyAlgorithm value of rsaEncryption SHOULD use the default set
of parameters for RSAES-OAEP-params.
4.1. RSAES-OAEP Public Keys
When id-RSAES-OAEP is used in an AlgorithmIdentifier, the parameters
MUST employ the RSAES-OAEP-params syntax. The parameters may be
either absent or present when used as subject public key information.