draft-ietf-smime-cms-rsaes-oaep-05.txt   draft-ietf-smime-cms-rsaes-oaep-06.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet Draft RSA Laboratories Internet Draft RSA Laboratories
expires in six months July 2002 expires in six months August 2002
Use of the RSAES-OAEP Key Transport Algorithm in CMS Use of the RSAES-OAEP Key Transport Algorithm in CMS
<draft-ietf-smime-cms-rsaes-oaep-05.txt> <draft-ietf-smime-cms-rsaes-oaep-06.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 6, line 25 skipping to change at page 6, line 25
parameters. The default value for P is an empty string. In this 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. case, pHash in EME-OAEP contains the hash of a zero length string.
Implementations MUST support a zero length P value. Implementations MUST support a zero length P value.
Implementations that perform encryption MUST omit the pSourceFunc Implementations that perform encryption MUST omit the pSourceFunc
field when a zero length P value is used, indicating that the field when a zero length P value is used, indicating that the
default value was used. Implementations that perform decryption default value was used. Implementations that perform decryption
MUST recognize both the id-pSpecified object identifier and an MUST recognize both the id-pSpecified object identifier and an
absent pSourceFunc field as an indication that a zero length P absent pSourceFunc field as an indication that a zero length P
value was used. value was used.
4. SMIMECapabilities Attribute Conventions 4. Certificate Conventions
RFC 3280 [PROFILE] specifies the profile for using X.509 Certificates
in Internet applications. When a RSA public key will be used for
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 7), the certificate user needs to be able
to determine the form of 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 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
[CERTALGS], section 2.3.1).
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 3 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 a certificate that conveys an RSA
public key with the id-RSAES-OAEP object identifier, then the key
usage extension MUST contain a combination of 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
parameters identified in the certificate.
5. SMIMECapabilities Attribute Conventions
RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed
attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be
used to specify a partial list of algorithms that the software used to specify a partial list of algorithms that the software
announcing the SMIMECapabilities can support. When constructing a announcing the SMIMECapabilities can support. When constructing a
signedData object, compliant software MAY include the signedData object, compliant software MAY include the
SMIMECapabilities signed attribute announcing that it supports the SMIMECapabilities signed attribute announcing that it supports the
RSAES-OAEP algorithm. RSAES-OAEP algorithm.
When all of the default settings are selected, the SMIMECapability When all of the default settings are selected, the SMIMECapability
skipping to change at page 7, line 43 skipping to change at page 9, line 12
the maskGenFunc, the SMIMECapability SEQUENCE representing RSAES-OAEP the maskGenFunc, the SMIMECapability SEQUENCE representing RSAES-OAEP
is the rSAES-OAEP-SHA512-Identifier, as specified in Appendix A. The is the rSAES-OAEP-SHA512-Identifier, as specified in Appendix A. The
SMIMECapability SEQUENCE representing rSAES-OAEP-SHA512-Identifier SMIMECapability SEQUENCE representing rSAES-OAEP-SHA512-Identifier
MUST be DER-encoded as the following hexadecimal string: MUST be DER-encoded as the following hexadecimal string:
30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30 30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30
0D 06 09 60 86 48 01 65 03 04 02 03 05 00 30 1A 0D 06 09 60 86 48 01 65 03 04 02 03 05 00 30 1A
06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60 06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60
86 48 01 65 03 04 02 03 05 00 86 48 01 65 03 04 02 03 05 00
5. References 6. References
This section provides normative and informative references. This section provides normative and informative references.
5.1. Normative References 6.1. Normative References
3DES American National Standards Institute. ANSI X9.52-1998, 3DES American National Standards Institute. ANSI X9.52-1998,
Triple Data Encryption Algorithm Modes of Operation. 1998. Triple Data Encryption Algorithm Modes of Operation. 1998.
CMS Housley, R. Cryptographic Message Syntax. RFC <TBD>. CMS Housley, R. Cryptographic Message Syntax. RFC <TBD>.
<TBD DATE>. <TBD DATE>.
MSG Ramsdell, B. S/MIME Version 3 Message Specification. MSG Ramsdell, B. S/MIME Version 3 Message Specification.
RFC 2633. June 1999. RFC 2633. June 1999.
skipping to change at page 8, line 35 skipping to change at page 10, line 5
X.208-88 CCITT. Recommendation X.208: Specification of Abstract X.208-88 CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
X.209-88 CCITT. Recommendation X.209: Specification of Basic X.209-88 CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One Encoding Rules for Abstract Syntax Notation One
(ASN.1). 1988. (ASN.1). 1988.
X.509-88 CCITT. Recommendation X.509: The Directory - X.509-88 CCITT. Recommendation X.509: The Directory -
Authentication Framework. 1988. Authentication Framework. 1988.
5.2. Informative References 6.2. Informative References
CERTALGS Polk, W., R. Housley, and L. Bassham. "Algorithms
and Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile. RFC 3279. April 2002.
CRYPTO98 Bleichenbacher, D. "Chosen Ciphertext Attacks Against CRYPTO98 Bleichenbacher, D. "Chosen Ciphertext Attacks Against
Protocols Based on the RSA Encryption Standard PKCS #1," Protocols Based on the RSA Encryption Standard PKCS #1,"
in H. Krawczyk (editor), Advances in Cryptology - in H. Krawczyk (editor), Advances in Cryptology -
CRYPTO '98 Proceedings, Lecture Notes in Computer CRYPTO '98 Proceedings, Lecture Notes in Computer
Science 1462 (1998), Springer-Verlag, pp. 1-12. Science 1462 (1998), Springer-Verlag, pp. 1-12.
MMA Rescorla, E. Preventing the Million Message Attack on MMA Rescorla, E. Preventing the Million Message Attack on
Cryptographic Message Syntax. RFC 3218. January 2002. Cryptographic Message Syntax. RFC 3218. January 2002.
skipping to change at page 9, line 25 skipping to change at page 11, line 5
Hash Standard." May 2001. Hash Standard." May 2001.
[http://csrc.nist.gov/encryption/shs/dfips-180-2.pdf] [http://csrc.nist.gov/encryption/shs/dfips-180-2.pdf]
SSL Freier, A., P. Karlton, and P. Kocher. The SSL Protocol, SSL Freier, A., P. Karlton, and P. Kocher. The SSL Protocol,
Version 3.0. Netscape Communications. November 1996. Version 3.0. Netscape Communications. November 1996.
[http://wp.netscape.com/eng/ssl3/draft302.txt] [http://wp.netscape.com/eng/ssl3/draft302.txt]
TLS Dierks, T. and C. Allen. The TLS Protocol Version 1.0. TLS Dierks, T. and C. Allen. The TLS Protocol Version 1.0.
RFC 2246. January 1999. RFC 2246. January 1999.
6. Security Considerations 7. Security Considerations
Implementations must protect the RSA private key and the content- Implementations must protect the RSA private key and the content-
encryption key. Compromise of the RSA private key may result in the encryption key. Compromise of the RSA private key may result in the
disclosure of all messages protected with that key. Compromise of disclosure of all messages protected with that key. Compromise of
the content-encryption key may result in disclosure of the associated the content-encryption key may result in disclosure of the associated
encrypted content. encrypted content.
The generation of RSA public/private key pairs relies on a random The generation of RSA public/private key pairs relies on a random
numbers. The use of inadequate pseudo-random number generators numbers. The use of inadequate pseudo-random number generators
(PRNGs) to generate cryptographic keys can result in little or no (PRNGs) to generate cryptographic keys can result in little or no
skipping to change at page 9, line 50 skipping to change at page 11, line 30
1750 [RANDOM] offers important guidance in this area. 1750 [RANDOM] offers important guidance in this area.
Generally, good cryptographic practice employs a given RSA key pair Generally, good cryptographic practice employs a given RSA key pair
in only one scheme. This practice avoids the risk that vulnerability in only one scheme. This practice avoids the risk that vulnerability
in one scheme may compromise the security of the other, and may be in one scheme may compromise the security of the other, and may be
essential to maintain provable security. While PKCS #1 Version 1.5 essential to maintain provable security. While PKCS #1 Version 1.5
[PKCS#1v1.5] has been employed for both key transport and digital [PKCS#1v1.5] has been employed for both key transport and digital
signature without any known bad interactions, such a combined use of signature without any known bad interactions, such a combined use of
an RSA key pair is not recommended in the future. Therefore, an RSA an RSA key pair is not recommended in the future. Therefore, an RSA
key pair used for RSAES-OAEP key transport should not also be used key pair used for RSAES-OAEP key transport should not also be used
for other purposes. 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- This specification requires implementation to support the SHA-1 one-
way hash function for interoperability, but support for other one-way way hash function for interoperability, but support for other one-way
hash function is permitted. At the time of this writing, the best hash function is permitted. At the time of this writing, the best
(known) collision attacks against SHA-1 are generic attacks with (known) collision attacks against SHA-1 are generic attacks with
complexity 2^80, where 80 is one-half the bit length of the hash complexity 2^80, where 80 is one-half the bit length of the hash
value. When a one-way hash function is used with a digital signature value. When a one-way hash function is used with a digital signature
scheme, a collision attack is easily translated into a signature scheme, a collision attack is easily translated into a signature
forgery. Therefore, the use of SHA-1 in a digital signature scheme 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 provides a security level of no more than 80 bits. If a greater
skipping to change at page 10, line 44 skipping to change at page 12, line 25
80 bits is needed, then a longer RSA public key and a secure one-way 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, hash function with a longer hash value are needed. Again, SHA-256,
SHA-384, and SHA-512 are likely candidates for such a one-way hash SHA-384, and SHA-512 are likely candidates for such a one-way hash
function. For this reason, the algorithm identifiers for these one- function. For this reason, the algorithm identifiers for these one-
way hash functions are included in the ASN.1 module in Appendix A. way hash functions are included in the ASN.1 module in Appendix A.
The same one-way hash function should be employed for the hashFunc 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 and the maskGenFunc, but it is not required. Using the same one-way
hash function reduces the potential for implementation errors. hash function reduces the potential for implementation errors.
7. Acknowledgments 8. Acknowledgments
This document is the result of contributions from many professionals. This document is the result of contributions from many professionals.
I appreciate the hard work of all members of the IETF S/MIME Working I appreciate the hard work of all members of the IETF S/MIME Working
Group. Further, I extend a special thanks to Burt Kaliski, Jakob Group. Further, I extend a special thanks to Burt Kaliski, Jakob
Jonsson, Francois Rousseau, and Jim Schaad. Jonsson, Francois Rousseau, and Jim Schaad.
8. Author Address 9. Author Address
Russell Housley Russell Housley
RSA Laboratories RSA Laboratories
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
rhousley@rsasecurity.com rhousley@rsasecurity.com
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
skipping to change at page 11, line 36 skipping to change at page 13, line 26
IMPORTS IMPORTS
AlgorithmIdentifier AlgorithmIdentifier
FROM PKIX1Explicit88 -- RFC 3280 FROM PKIX1Explicit88 -- RFC 3280
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) }; id-pkix1-explicit(18) };
pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-1(1) } rsadsi(113549) pkcs(1) pkcs-1(1) }
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 }
RSAES-OAEP-params ::= SEQUENCE { RSAES-OAEP-params ::= SEQUENCE {
hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier,
maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier,
pSourceFunc [2] AlgorithmIdentifier DEFAULT pSourceFunc [2] AlgorithmIdentifier DEFAULT
pSpecifiedEmptyIdentifier } pSpecifiedEmptyIdentifier }
sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL } sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/