PKIX Working Group R. Housley (RSA Laboratories)
Internet Draft B. Kaliski (RSA Laboratories)
expires June 2003 December 2002
Additional Algorithms and Identifiers for RSA Cryptography
for use in the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile
<draft-ietf-pkix-rsa-pkalgs-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Drafts Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document supplements RFC 3279. It describes the conventions for
using the RSASSA-PSS signature algorithm, the RSAES-OAEP key
transport algorithm, and additional one-way hash functions with the
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.
Housley & Kaliski [Page 1]
INTERNET DRAFT December 2002
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 3
1.2 RSA Public Keys . . . . . . . . . . . . . . . . . . . . 3
2 Common Functions . . . . . . . . . . . . . . . . . . . . . . 5
2.1 One-way Hash Functions . . . . . . . . . . . . . . . . . 6
2.2 Mask Generation Functions . . . . . . . . . . . . . . . 7
3 RSASSA-PSS Signature Algorithm . . . . . . . . . . . . . . . 7
3.1 RSASSA-PSS Public Keys . . . . . . . . . . . . . . . . . 8
3.2 RSASSA-PSS Signature Values . . . . . . . . . . . . . . 10
4 RSAES-OAEP Key Transport Algorithm . . . . . . . . . . . . . 10
4.1 RSAES-OAEP Public Keys . . . . . . . . . . . . . . . . . 11
5 PKCS #1 Version 1.5 Signature Algorithm . . . . . . . . . . . 12
6 ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 14
7 References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1 Normative References . . . . . . . . . . . . . . . . . . 18
7.2 Informative References . . . . . . . . . . . . . . . . . 19
8 Security Considerations . . . . . . . . . . . . . . . . . . . 19
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10 Author Addresses . . . . . . . . . . . . . . . . . . . . . . 22
11 Full Copyright Statement . . . . . . . . . . . . . . . . . . 22
Housley & Kaliski [Page 2]
INTERNET DRAFT December 2002
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 are specified, and the encoding format for RSASSA-PSS
signatures is specified. Also, the algorithm identifiers for using
the 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 profile 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 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 a RSA public key will be 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 the Security Considerations section of
this document (see 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.
Housley & Kaliski [Page 3]
INTERNET DRAFT December 2002
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 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 of this
document.
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 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 of this
document.
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 key
usage 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 key usage extension MUST contain one or both of
Housley & Kaliski [Page 4]
INTERNET DRAFT December 2002
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 key usage extension MUST contain one or
more of the following values:
nonRepudiation;
digitalSignature;
keyCertSign; and
cRLSign.
When a certificate that 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 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 that conveys an
RSA public key with the id-RSAES-OAEP object identifier, then the key
usage 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 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 algorithm and the RSAES-OAEP key transport
algorithm make use of one-way hash functions and mask generation
functions.
Housley & Kaliski [Page 5]
INTERNET DRAFT December 2002
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].
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-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 fact that when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax the OPTIONAL
associated with the algorithm identifier parameters got lost. 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
and others omit them entirely. The correct encoding is to omit the
parameters field; however, implementations must also handle an
algorithm identifier parameters field which contains a NULL.
The AlgorithmIdentifier parameters field is OPTIONAL. If present,
the parameters field must contain a NULL. Implementations MUST
accept an AlgorithmIdentifiers with absent parameters as well as
AlgorithmIdentifiers with NULL parameters. Within this
specification, there are many places where a NULL parameter is
REQUIRED. To be clear, the following algorithm identifiers are used
Housley & Kaliski [Page 6]
INTERNET DRAFT December 2002
when a NULL parameter MUST be present:
sha1Identifier AlgorithmIdentifier ::= { id-sha1, 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, sha256Identifier,
sha384Identifier, or sha512Identifier, as specified in section 2.1.
Implementations MUST support the default value, sha1Identifier, and
implementations MAY support the other three values.
The following algorithm identifiers have been assigned for each of
these alternatives:
mgf1SHA1Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha1Identifier }
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
Housley & Kaliski [Page 7]
INTERNET DRAFT December 2002
in PKCS #1 version 2.1 [P1v2.1]. The four 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. Conforming CAs
and applications MUST support RSASSA-PSS digital signatures using
SHA-1. The other three one-way hash functions MAY also be supported.
Certificates and CRLs conforming to [PROFILE] may be signed with any
public key signature algorithm. The certificate or CRL indicates the
algorithm through an algorithm identifier which appears in the
signatureAlgorithm field within the Certificate or CertificateList.
This algorithm identifier is an object identifier (OID) and optional
parameters. Section 3.1 specifies the object identifier and
parameters for RSASSA-PSS digital signatures.
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 encryption) 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
signature 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 be present, and the parameters MUST employ the RSASSA-PSS-params
syntax.
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 implementations MAY support other one-way
hash functions listed in section 2.1. Implementations that
perform signature generation MUST omit the hashAlgorithm field
Housley & Kaliski [Page 8]
INTERNET DRAFT December 2002
when SHA-1 is used, indicating that the default algorithm was
used. Implementations that perform signature validation MUST
recognize both the id-sha1 object identifier and an absent
hashAlgorithm field as an indication that SHA-1 was used.
maskGenAlgorithm
The maskGenAlgorithm field identifies the mask generation
function. It MUST be an algorithm identifier, and 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, and
it is identified in the parameter field of the MGF1 algorithm
identifier. Implementations MUST support SHA-1, and
implementations MAY support other one-way hash functions listed
in 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 a 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. Implementations that
perform signature validation MUST recognize both the id-mgf1
and id-sha1 object identifiers as well as an absent
maskGenAlgorithm field as an indication that MGF1 with SHA-1
was used.
saltLength
The saltLength field is the octet length of the salt. It MUST
be an integer. For a given hashAlgorithm, the default 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 the draft IEEE P1363a [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 P1363a, are not supported. Implementations that perform
signature generation MUST omit the trailerField field,
indicating that the default trailer field value was used.
Housley & Kaliski [Page 9]
INTERNET DRAFT December 2002
Implementations that perform signature validation MUST
recognize both a present 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,
{ 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.
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 four 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 three one-
way hash functions MAY also be supported.
Certificates and CRLs conforming to [PROFILE] may be signed with any
public key signature algorithm. The certificate or CRL indicates the
algorithm through an algorithm identifier which appears in the
signatureAlgorithm field within the Certificate or CertificateList.
This algorithm identifier is an object identifier (OID) and optional
parameters. Section 4.1 specifies the object identifier and
parameters for RSAES-OAEP key transport.
Housley & Kaliski [Page 10]
INTERNET DRAFT December 2002
4.1 RSAES-OAEP Public Keys
When RSAES-OAEP is used in an AlgorithmIdentifier, the parameters
MUST be present, and the parameters MUST employ the RSAES-OAEP-params
syntax.
id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 }
RSAES-OAEP-params ::= SEQUENCE {
hashFunc [0] AlgorithmIdentifier DEFAULT
sha1Identifier,
maskGenFunc [1] AlgorithmIdentifier DEFAULT
mgf1SHA1Identifier,
pSourceFunc [2] AlgorithmIdentifier DEFAULT
pSpecifiedEmptyIdentifier }
pSpecifiedEmptyIdentifier AlgorithmIdentifier ::=
{ id-pSpecified, nullOctetString }
nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
The fields of type RSAES-OAEP-params have the following meanings:
hashFunc
The hashFunc field identifies the one-way 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 implementations MAY support other one-way
hash functions listed in section 2.1. Implementations that
perform encryption MUST omit the hashFunc field when SHA-1 is
used, indicating that the default algorithm was used.
Implementations that perform decryption MUST recognize both the
id-sha1 object identifier and an absent hashFunc field as an
indication that SHA-1 was used.
maskGenFunc
The maskGenFunc field identifies the mask generation function.
It MUST be an algorithm identifier, and 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 hashFunc. Implementations MUST
support MGF1. MGF1 requires a one-way hash function, and it is
identified in the parameter field of the MGF1 algorithm
identifier. Implementations MUST support SHA-1, and
Housley & Kaliski [Page 11]
INTERNET DRAFT December 2002
implementations MAY support other one-way hash functions listed
in 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 a parameter of NULL.
Implementations that perform encryption MUST omit the
maskGenFunc field when MGF1 with SHA-1 is used, indicating that
the default algorithm was used. Implementations that perform
decryption MUST recognize both the id-mgf1 and id-sha1 object
identifiers as well as an absent maskGenFunc field as an
indication that MGF1 with SHA-1 was used.
pSourceFunc
The pSourceFunc field identifies the source (and possibly the
value) of the encoding parameters, commonly called P.
Implementations MUST represent P by an algorithm identifier,
id-pSpecified, indicating that P is explicitly provided as an
OCTET STRING in the parameters. The default value for P is an
empty string. In this case, pHash in EME-OAEP contains the
hash of a zero length string. Implementations MUST support a
zero length P value. Implementations that perform encryption
MUST omit the pSourceFunc field when a zero length P value is
used, indicating that the default value was used.
Implementations that perform decryption MUST recognize both the
id-pSpecified object identifier and an absent pSourceFunc field
as an indication that a zero length P value was used.
Implementations that perform decryption MUST support a zero
length P value, and they MAY support other values.
If the default values of the hashFunc, maskGenFunc, and pSourceFunc
fields of RSAES-OAEP-params are used, then the algorithm identifier
will have the following value:
rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::=
{ id-RSAES-OAEP,
{ sha1Identifier,
mgf1SHA1Identifier,
pSpecifiedEmptyIdentifier } }
5 PKCS #1 Version 1.5 Signature Algorithm
RFC 2313 [P1v1.5] specifies the PKCS #1 Version 1.5 signature
algorithm. This specification is also included in PKCS #1 Version
2.1 [P1v2.1]. RFC 3279 [PKALGS] specifies the use of the PKCS #1
Version 1.5 signature algorithm with the MD2, MD5, and the SHA-1 one-
Housley & Kaliski [Page 12]
INTERNET DRAFT December 2002
way hash functions. This section specifies the algorithm identifiers
for using the SHA-256, SHA-384, and SHA-512 one-way hash functions
with the PKCS #1 version 1.5 signature algorithm.
The RSASSA-PSS signature algorithm is preferred over the PKCS #1
Version 1.5 signature algorithm. Although no attacks are known
against PKCS #1 Version 1.5 signature algorithm, in the interest of
increased robustness, RSASSA-PSS signature algorithm is recommended
for eventual adoption, especially by new applications. This section
is included for compatibility with existing applications, and while
still appropriate for new applications, a gradual transition to the
RSASSA-PSS signature algorithm is encouraged.
The PKCS #1 Version 1.5 signature algorithm with these one-way hash
functions and the RSA encryption algorithm is implemented using the
padding and encoding conventions described in RFC 2313 [P1v1.5]. The
message digest is computed using the SHA-256, SHA-384, or SHA-512
one-way hash function.
The PKCS #1 version 1.5 signature algorithm, as specified in RFC 2313
includes a data encoding step. In this step, the message digest and
the object identifier for the one-way hash function used to compute
the message digest are combined. When performing the data encoding
step, the id-sha256, id-sha384, and id-sha512 object identifiers (see
section 2.1) MUST be used to specify the SHA-256, SHA-384, and
SHA-512 one-way hash functions, respectively.
The object identifier used to identify the PKCS #1 version 1.5
signature algorithm with SHA-256 is:
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
The object identifier used to identify the PKCS #1 version 1.5
signature algorithm with SHA-384 is:
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
The object identifier used to identify the PKCS #1 version 1.5
signature algorithm with SHA-512 is:
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
When any of these three object identifiers appears within an
AlgorithmIdentifier, the parameters MUST be NULL.
The RSA signature generation process and the encoding of the result
is described in detail in RFC 2313 [P1v1.5].
Housley & Kaliski [Page 13]
INTERNET DRAFT December 2002
6 ASN.1 Module
PKIX1-PSS-OAEP-Algorithms
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs(TBD) }
DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- EXPORTS All;
IMPORTS
AlgorithmIdentifier
FROM PKIX1Explicit88 -- RFC 3280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) };
-- ============================
-- Basic object identifiers
-- ============================
pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) 1 }
-- When rsaEncryption is used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
-- When id-RSAES-OAEP is used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be RSAES-OAEP-params.
id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 }
-- When id-pSpecified is used in an AlgorithmIdentifier the
-- parameters MUST be an OCTET STRING.
id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 }
Housley & Kaliski [Page 14]
INTERNET DRAFT December 2002
-- When id-RSASSA-PSS is used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be RSASSA-PSS-params.
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
-- When id-mgf1 is used in an AlgorithmIdentifier the parameters
-- MUST be present and MUST be a HashAlgorithm.
id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }
-- When the following OIDs are used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
-- When the following OIDs are used in an AlgorithmIdentifier the
-- parameters SHOULD be absent, but if the parameters are present,
-- they MUST be NULL.
id-sha1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) oiw(14)
secsig(3) algorithms(2) 26 }
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 }
Housley & Kaliski [Page 15]
INTERNET DRAFT December 2002
-- =============
-- Constant
-- =============
nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
-- =========================
-- Algorithm Identifiers
-- =========================
sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL }
sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL }
sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL }
mgf1SHA1Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha1Identifier }
mgf1SHA256Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha256Identifier }
mgf1SHA384Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha384Identifier }
mgf1SHA512Identifier AlgorithmIdentifier ::=
{ id-mgf1, sha512Identifier }
pSpecifiedEmptyIdentifier AlgorithmIdentifier ::=
{ id-pSpecified, nullOctetString }
rSASSA-PSS-Default-Identifier AlgorithmIdentifier ::= {
{ id-RSASSA-PSS,
{ sha1Identifier,
mgf1SHA1Identifier,
20,
1 } }
rSASSA-PSS-SHA256-Identifier AlgorithmIdentifier ::= {
{ id-RSASSA-PSS,
{ sha256Identifier,
mgf1SHA256Identifier,
20,
1 } }
Housley & Kaliski [Page 16]
INTERNET DRAFT December 2002
rSASSA-PSS-SHA384-Identifier AlgorithmIdentifier ::= {
{ id-RSASSA-PSS,
{ sha384Identifier,
mgf1SHA384Identifier,
20,
1 } }
rSASSA-PSS-SHA512-Identifier AlgorithmIdentifier ::= {
{ id-RSASSA-PSS,
{ sha512Identifier,
mgf1SHA512Identifier,
20,
1 } }
rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::=
{ id-RSAES-OAEP,
{ sha1Identifier,
mgf1SHA1Identifier,
pSpecifiedEmptyIdentifier } }
rSAES-OAEP-SHA256-Identifier AlgorithmIdentifier ::=
{ id-RSAES-OAEP,
{ sha256Identifier,
mgf1SHA256Identifier,
pSpecifiedEmptyIdentifier } }
rSAES-OAEP-SHA384-Identifier AlgorithmIdentifier ::=
{ id-RSAES-OAEP,
{ sha384Identifier,
mgf1SHA384Identifier,
pSpecifiedEmptyIdentifier } }
rSAES-OAEP-SHA512-Identifier AlgorithmIdentifier ::=
{ id-RSAES-OAEP,
{ sha512Identifier,
mgf1SHA512Identifier,
pSpecifiedEmptyIdentifier } }
-- ===================
-- Main structures
-- ===================
-- Used in SubjectPublicKeyInfo of X.509 Certificate.
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
Housley & Kaliski [Page 17]
INTERNET DRAFT December 2002
-- AlgorithmIdentifier parameters for id-RSASSA-PSS.
-- Note that the tags in this Sequence are explicit.
RSASSA-PSS-params ::= SEQUENCE {
hashAlgorithm [0] HashAlgorithm DEFAULT
sha1Identifier,
maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT
mgf1SHA1Identifier,
saltLength [2] INTEGER DEFAULT 20,
trailerField [3] INTEGER DEFAULT 1 }
HashAlgorithm ::= AlgorithmIdentifier
MaskGenAlgorithm ::= AlgorithmIdentifier
-- AlgorithmIdentifier parameters for id-RSAES-OAEP.
-- Note that the tags in this Sequence are explicit.
RSAES-OAEP-params ::= SEQUENCE {
hashFunc [0] AlgorithmIdentifier DEFAULT
sha1Identifier,
maskGenFunc [1] AlgorithmIdentifier DEFAULT
mgf1SHA1Identifier,
pSourceFunc [2] AlgorithmIdentifier DEFAULT
pSpecifiedEmptyIdentifier }
END
7 References
This section provides normative and informative references.
7.1 Normative References
[P1v1.5] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
RFC 2313, March 1998.
[P1v2.1] J. Jonsson, J., and B. Kaliski, "PKCS #1: RSA
Cryptography Specifications Version 2.1", Internet-Draft,
August 2002. <draft-jonsson-pkcs1-v2dot1-00.txt>
[PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and CRL
Profile", RFC 3280, April 2002.
Housley & Kaliski [Page 18]
INTERNET DRAFT December 2002
[SHA2] National Institute of Standards and Technology (NIST),
FIPS 180-2: Secure Hash Standard, 1 August 2002.
[STDWORDS] S. Bradner, "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[X.208-88] CCITT Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1), 1988.
[X.209-88] CCITT Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1),
1988.
[X.509-88] CCITT Recommendation X.509: The Directory -
Authentication Framework. 1988.
7.2 Informative References
[CMS] Housley, R, "Cryptographic Message Syntax", RFC 3369,
August 2002.
[GUIDE] National Institute of Standards and Technology,
Second Draft: "Key Management Guideline, Part 1:
General Guidance." June 2002.
[http://csrc.nist.gov/encryption/kms/guideline-1.pdf]
[P1363a] IEEE P1363 working group, IEEE P1363a D11: Standard
Specifications for Public Key Cryptography: Additional
Techniques, December 16, 2002
Available from http://grouper.ieee.org/groups/1363/.
[PKALGS] Polk, W., Housley, R., and L. Bassham, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
Lists (CRL) Profile", RFC 3279, April 2002.
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security, RFC 1750, December 1994.
8 Security Considerations
This specification supplements RFC 3280 [PROFILE]. The security
considerations section of that document applies to this specification
as well.
Implementations must protect the RSA private key. Compromise of the
RSA private key may result in the disclosure of all messages
Housley & Kaliski [Page 19]
INTERNET DRAFT December 2002
protected with that key.
The generation of RSA public/private key pairs relies on a random
numbers. The use of inadequate pseudo-random number generators
(PRNGs) to generate cryptographic keys can result in little or no
security. An attacker may find it much easier to reproduce the PRNG
environment that produced the keys, searching the resulting small set
of possibilities, rather than brute force searching the whole key
space. The generation of quality random numbers is difficult. RFC
1750 [RANDOM] offers important guidance in this area.
Generally, good cryptographic practice employs a given RSA key pair
in only one scheme. This practice avoids the risk that vulnerability
in one scheme may compromise the security of the other, and may be
essential to maintain provable security. While PKCS #1 Version 1.5
[P1v1.5] has been employed for both key transport and digital
signature without any known bad interactions, such a combined use of
an RSA key pair is not recommended in the future. Therefore, an RSA
key pair used for RSASSA-PSS signature generation should not also be
used for other purposes. For similar reasons, one RSA key pair
should always be used with the same RSASSA-PSS parameters. Likewise,
an RSA key pair used for RSAES-OAEP key transport should not also be
used for other purposes. For similar reasons, one RSA key pair
should always be used with the same RSAES-OAEP parameters.
This specification requires implementation to support the SHA-1 one-
way hash function for interoperability, but support for other one-way
hash function is permitted. At the time of this writing, the best
(known) collision attacks against SHA-1 are generic attacks with
complexity 2^80, where 80 is one-half the bit length of the hash
value. In general, when a one-way hash function is used with a
digital signature scheme, a collision attack is easily translated
into a signature forgery. Therefore, the use of SHA-1 in a digital
signature scheme provides a security level of no more than 80 bits.
If a greater level of security is desired, then a secure one-way hash
function with a longer hash value is needed. SHA-256, SHA-384, and
SHA-512 are reasonable choices [SHA2].
The metrics for choosing a one-way hash function for use in digital
signatures do not directly apply to the RSAES-OAEP key transport
algorithm, since a collision attack on the one-way hash function does
not directly translate into an attack on the key transport algorithm,
unless the encoding parameters P varies (in which case a collision
the hash value for different encoding parameters might be exploited).
Nevertheless, for consistency with the practice for digital signature
schemes, and in case the encoding parameters P is not the empty
string, it is recommended that the same rule of thumb be applied to
Housley & Kaliski [Page 20]
INTERNET DRAFT December 2002
selection of a one-way hash function for use with RSAES-OAEP. That
is, the one-way hash function should be selected so that the bit
length of the hash value is at least twice as long as the desired
security level in bits.
This specification does not constrain the size of public keys or
their parameters for use in the Internet PKI. However, the key size
selected impacts the strength achieved when implementing
cryptographic services. Selection of appropriate key sizes is
critical to implementing appropriate security. However, a 1024-bit
RSA public key and SHA-1 both provide a security level of about 80
bits. In [GUIDE], the National Institute of Standards and Technology
(NIST) suggests that a security level of 80 bits is adequate for the
protection of sensitive information until 2015. If a security level
greater than 80 bits is needed, then a longer RSA public key and a
secure one-way hash function with a longer hash value are needed.
Again, SHA-256, SHA-384, and SHA-512 are reasonable choices for such
a one-way hash function. For this reason, the algorithm identifiers
for these one-way hash functions are included in the ASN.1 module in
section 5.
When using RSASSA-PSS, the same one-way hash function should be
employed for the hashAlgorithm and the maskGenAlgorithm, but it is
not required. Using the same one-way hash function helps with
security analysis, and it reduces implementation complexity.
When using RSAES-OAEP, the same one-way hash function should be
employed for the hashFunc and the maskGenFunc, but it is not
required. Using the same one-way hash function helps with security
analysis, and it reduces implementation complexity.
9 IANA Considerations
Within the certificates and CRLs, algorithms are identified by object
identifiers. All of the object identifiers used in this document
were assigned in Public-Key Cryptography Standards (PKCS) documents
or by the National Institute of Standards and Technology (NIST). No
further action by the IANA is necessary for this document or any
anticipated updates.
Housley & Kaliski [Page 21]
INTERNET DRAFT December 2002
10 Author Addresses
Russell Housley
RSA Laboratories
918 Spring Knoll Drive
Herndon, VA 20170
USA
rhousley@rsasecurity.com
Burt Kaliski
RSA Laboratories
174 Middlesex Turnpike
Bedford, MA 01730
USA
bkaliski@rsasecurity.com
11 Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.
In addition, the ASN.1 modules presented in Section 5 may be used in
whole or in part without inclusion of the copyright notice. However,
this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process shall be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
Housley & Kaliski [Page 22]
