draft-ietf-smime-cms-rsa-kem-07.txt   draft-ietf-smime-cms-rsa-kem-08.txt 
S/MIME Working Group James Randall, Randall Consulting S/MIME Working Group James Randall, Randall Consulting
Internet Draft Burt Kaliski, EMC Internet Draft Burt Kaliski, EMC
John Brainard, RSA John Brainard, RSA
Sean Turner, IECA Sean Turner, IECA
Expires: January 7, 2010 Category: Standards Expires: June 6, 2010 Category: Standards
July 7, 2009 December 7, 2009
Use of the RSA-KEM Key Transport Algorithm in CMS Use of the RSA-KEM Key Transport Algorithm in CMS
<draft-ietf-smime-cms-rsa-kem-07.txt> <draft-ietf-smime-cms-rsa-kem-08.txt>
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 4, line 30 skipping to change at page 4, line 30
chosen-ciphertext attacks. The RSAES-OAEP Key Transport Algorithm has chosen-ciphertext attacks. The RSAES-OAEP Key Transport Algorithm has
also been proposed as a replacement (see [PKCS1] and [CMS-OAEP]). also been proposed as a replacement (see [PKCS1] and [CMS-OAEP]).
RSA-KEM has the advantage over RSAES-OAEP of a tighter security RSA-KEM has the advantage over RSAES-OAEP of a tighter security
proof, but the disadvantage of slightly longer encrypted keying data. proof, but the disadvantage of slightly longer encrypted keying data.
2.1. Underlying Components 2.1. Underlying Components
A CMS implementation that supports the RSA-KEM Key Transport A CMS implementation that supports the RSA-KEM Key Transport
Algorithm MUST support at least the following underlying components: Algorithm MUST support at least the following underlying components:
o For the key derivation function, KDF2 (see [ANS-X9.44]) (see o For the key derivation function, KDF3 (see [IEEE-P1363a]) based on
[IEEE-P1363a]) based on SHA-1 (see [FIPS-180-2]) (this function is SHA-256 (see [FIPS-180-2]). KDF3 is an instantiation of the
also specified as the key derivation function in [ANS-X9.63]), and Concatenation Key Derivation Function defined in [SP800-56A].
KDF3 (see [IEEE-P1363a]) based on SHA-256 (see [FIPS-180-2]).
o For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key Wrap o For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key Wrap
with a 128-bit key encrypting key (see [AES-WRAP]) with a 128-bit key encrypting key (see [AES-WRAP])
An implementation SHOULD also support KDF3 based on SHA-1 and KDF2 An implementation SHOULD also support KDF2 (see [ANS-X9.44]) based on
based on SHA-256. The Camellia key wrap algorithm (see [CAMELLIA]) SHA-1 (this function is also specified as the key derivation function
in [ANS-X9.63]). The Camellia key wrap algorithm (see [CAMELLIA])
SHOULD be supported, and, if 3DES is supported as a content- SHOULD be supported, and, if 3DES is supported as a content-
encryption cipher, then the Triple-DES Key Wrap (see [3DES-WRAP]) encryption cipher, then the Triple-DES Key Wrap (see [3DES-WRAP])
SHOULD also be supported. SHOULD also be supported.
It MAY support other underlying components. When AES or Camellia are It MAY support other underlying components. When AES or Camellia are
used the data block size is 128 bits while the key size can be 128, used the data block size is 128 bits while the key size can be 128,
192, or 256 bits while Triple DES requires a data block size of 64 192, or 256 bits while Triple DES requires a data block size of 64
bits and a key size of 112 or 168 bits. bits and a key size of 112 or 168 bits.
2.2. RecipientInfo Conventions 2.2. RecipientInfo Conventions
skipping to change at page 5, line 25 skipping to change at page 5, line 25
o keyEncryptionAlgorithm.parameters MUST be a value of type o keyEncryptionAlgorithm.parameters MUST be a value of type
GenericHybridParameters, identifying the RSA-KEM key encapsulation GenericHybridParameters, identifying the RSA-KEM key encapsulation
mechanism (see Appendix B) mechanism (see Appendix B)
o encryptedKey MUST be the encrypted keying data output by the o encryptedKey MUST be the encrypted keying data output by the
algorithm, where the keying data is the content-encryption algorithm, where the keying data is the content-encryption
key.(see Appendix A) key.(see Appendix A)
2.3. Certificate Conventions 2.3. Certificate Conventions
The conventions specified in this section augment RFC 3280 [PROFILE]. The conventions specified in this section augment RFC 5280 [PROFILE].
A recipient who employs the RSA-KEM Key Transport Algorithm MAY A recipient who employs the RSA-KEM Key Transport Algorithm MAY
identify the public key in a certificate by the same identify the public key in a certificate by the same
AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using
the rsaEncryption object identifier [PKCS1]. The fact that the user the rsaEncryption object identifier [PKCS1]. The fact that the user
will accept RSA-KEM with this public key is not indicated by the use will accept RSA-KEM with this public key is not indicated by the use
of this identifier. This may be signed by the use of the appropriate of this identifier. This may be signed by the use of the appropriate
SMIME Capabilities either in a message or in the certificate. SMIME Capabilities either in a message or in the certificate.
If the recipient wishes only to employ the RSA-KEM Key Transport If the recipient wishes only to employ the RSA-KEM Key Transport
skipping to change at page 10, line 19 skipping to change at page 10, line 19
[ISO-IEC-18033-2] ISO/IEC 18033-2:2005 Information technology -- [ISO-IEC-18033-2] ISO/IEC 18033-2:2005 Information technology --
Security techniques -- Encryption algorithms -- Security techniques -- Encryption algorithms --
Part 2: Asymmetric Ciphers. ISO/IEC, 2005. Part 2: Asymmetric Ciphers. ISO/IEC, 2005.
[NESSIE] NESSIE Consortium. Portfolio of Recommended [NESSIE] NESSIE Consortium. Portfolio of Recommended
Cryptographic Primitives. February 27, 2003. Cryptographic Primitives. February 27, 2003.
Available via http://www.cryptonessie.org/. Available via http://www.cryptonessie.org/.
[NIST-GUIDELINE] National Institute of Standards and Technology. [NIST-GUIDELINE] National Institute of Standards and Technology.
Special Publication 800-57: Recommendation for Special Publication 800-57: Recommendation for
Pairwise Key Establishment Schemes Using Discrete
Logarithm Cryptography March 2007. Available via:
http://csrc.nist.gov/publications/index.html.
[NIST-SP800-56A] National Institute of Standards and Technology.
Special Publication 800-56A: Recommendation for
Key Management. Part 1: General Guideline. Key Management. Part 1: General Guideline.
August 2005. Available via: August 2005. Available via:
http://csrc.nist.gov/publications/index.html. http://csrc.nist.gov/publications/index.html.
[PKCS1] Jonsson, J. and B. Kaliski. PKCS #1: RSA [PKCS1] Jonsson, J. and B. Kaliski. PKCS #1: RSA
Cryptography Specifications Version 2.1. RFC Cryptography Specifications Version 2.1. RFC
3447. February 2003. 3447. February 2003.
[RANDOM] Eastlake, D., S. Crocker, and J. Schiller. [RANDOM] Eastlake, D., S. Crocker, and J. Schiller.
Randomness Recommendations for Security. RFC Randomness Recommendations for Security. RFC
skipping to change at page 25, line 7 skipping to change at page 25, line 7
camellia256-wrap(4) } camellia256-wrap(4) }
camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap } camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap }
camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap } camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap }
camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap } camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap }
END END
B.4 Examples B.4 Examples
As an example, if the key derivation function is KDF2 based onSHA-256 As an example, if the key derivation function is KDF3 based on SHA-
and the symmetric key-wrapping scheme is the AES Key Wrap with a 128- 256 and the symmetric key-wrapping scheme is the AES Key Wrap with a
bit KEK, the AlgorithmIdentifier for the RSA-KEM Key Transport 128-bit KEK, the AlgorithmIdentifier for the RSA-KEM Key Transport
Algorithm will have the following value: Algorithm will have the following value:
SEQUENCE { SEQUENCE {
id-rsa-kem, -- RSA-KEM cipher id-rsa-kem, -- RSA-KEM cipher
SEQUENCE { -- GenericHybridParameters SEQUENCE { -- GenericHybridParameters
SEQUENCE { -- key encapsulation mechanism SEQUENCE { -- key encapsulation mechanism
id-kem-rsa, -- RSA-KEM id-kem-rsa, -- RSA-KEM
SEQUENCE { -- RsaKemParameters SEQUENCE { -- RsaKemParameters
SEQUENCE { -- key derivation function SEQUENCE { -- key derivation function
id-kdf-kdf2, -- KDF2 id-kdf-kdf3, -- KDF3
SEQUENCE { -- KDF2-HashFunction SEQUENCE { -- KDF2-HashFunction
id-sha256 -- SHA-256; no parameters (preferred) id-sha256 -- SHA-256; no parameters (preferred)
}, },
16 -- KEK length in bytes 16 -- KEK length in bytes
}, },
SEQUENCE { -- data encapsulation mechanism SEQUENCE { -- data encapsulation mechanism
id-aes128-Wrap -- AES-128 Wrap; no parameters id-aes128-Wrap -- AES-128 Wrap; no parameters
} }
} }
} }
skipping to change at page 25, line 41 skipping to change at page 25, line 41
This AlgorithmIdentifier value has the following DER encoding (?? This AlgorithmIdentifier value has the following DER encoding (??
indicates the algorithm number which is to be assigned): indicates the algorithm number which is to be assigned):
30 53 30 53
06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? -- id-rsa-kem 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? -- id-rsa-kem
30 44 30 44
30 25 30 25
06 07 28 81 8c 71 02 02 04 -- id-kem-rsa 06 07 28 81 8c 71 02 02 04 -- id-kem-rsa
30 1a 30 1a
30 16 30 16
06 07 28 81 8c 71 02 05 02 -- id-kdf-kdf2 06 07 28 81 8c 71 02 05 02 -- id-kdf-kdf3
30 0b 30 0b
06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 06 09 60 86 48 01 65 03 04 02 01 -- id-sha256
02 10 -- 16 bytes 02 10 -- 16 bytes
30 0b 30 0b
06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap 06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap
The DER encodings for other typical sets of underlying components are The DER encodings for other typical sets of underlying components are
as follows: as follows:
o KDF2 based on SHA-384, AES Key Wrap with a 192-bit KEK o KDF3 based on SHA-384, AES Key Wrap with a 192-bit KEK
30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02 30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02
01 02 30 44 30 25 06 07 28 81 8c 71 02 02 04 30 01 02 30 44 30 25 06 07 28 81 8c 71 02 02 04 30
1a 30 16 06 07 28 81 8c 71 02 05 02 30 0b 06 09 1a 30 16 06 07 28 81 8c 71 02 05 02 30 0b 06 09
60 86 48 01 65 03 04 02 02 02 18 30 0b 06 09 60 60 86 48 01 65 03 04 02 02 02 18 30 0b 06 09 60
86 48 01 65 03 04 01 19 86 48 01 65 03 04 01 19
o KDF2 based on SHA-512, AES Key Wrap with a 256-bit KEK o KDF3 based on SHA-512, AES Key Wrap with a 256-bit KEK
30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02 30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02
01 02 30 44 30 25 06 07 28 81 8c 71 02 02 04 30 01 02 30 44 30 25 06 07 28 81 8c 71 02 02 04 30
1a 30 16 06 07 28 81 8c 71 02 05 02 30 0b 06 09 1a 30 16 06 07 28 81 8c 71 02 05 02 30 0b 06 09
60 86 48 01 65 03 04 02 03 02 20 30 0b 06 09 60 60 86 48 01 65 03 04 02 03 02 20 30 0b 06 09 60
86 48 01 65 03 04 01 2d 86 48 01 65 03 04 01 2d
o KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK (two- o KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK (two-
key triple-DES) key triple-DES)
30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02 30 46 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 02
01 02 30 44 30 21 06 07 28 81 8c 71 02 02 04 30 01 02 30 44 30 21 06 07 28 81 8c 71 02 01 04 30
16 30 12 06 07 28 81 8c 71 02 05 02 30 07 06 05 16 30 12 06 07 28 81 8c 71 02 05 02 30 07 06 05
2b 0e 03 02 1a 02 10 30 0f 06 0b 2a 86 48 86 f7 2b 0e 03 02 1a 02 10 30 0f 06 0b 2a 86 48 86 f7
0d 01 09 10 03 06 05 00 0d 01 09 10 03 06 05 00
IANA Considerations IANA Considerations
Within the CMS, algorithms are identified by object identifiers Within the CMS, algorithms are identified by object identifiers
(OIDs). With one exception, all of the OIDs used in this document (OIDs). With one exception, all of the OIDs used in this document
were assigned in other IETF documents, in ISO/IEC standards were assigned in other IETF documents, in ISO/IEC standards
documents, by the National Institute of Standards and Technology documents, by the National Institute of Standards and Technology
 End of changes. 12 change blocks. 
18 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/