 1/draftietfsmimecmsrsakem12.txt 20100601 21:13:01.000000000 +0200
+++ 2/draftietfsmimecmsrsakem13.txt 20100601 21:13:02.000000000 +0200
@@ 1,27 +1,27 @@
S/MIME WG James Randall, Randall Consulting
Internet Draft Burt Kaliski, EMC
Intended Status: Standards Track John Brainard, RSA
Sean Turner, IECA
Expires: September 8, 2010 March 8, 2010
+Expires: November 29, 2010 May 29, 2010
Use of the RSAKEM Key Transport Algorithm in CMS

+
Abstract
The RSAKEM Key Transport Algorithm is a onepass (storeandforward)
mechanism for transporting keying data to a recipient using the
recipient's RSA public key. This document specifies the conventions
for using the RSAKEM Key Transport Algorithm with the Cryptographic
 Message Syntax (CMS). The ASN.1 syntax is aligned with ANS X9.44 and
 ISO/IEC 180332.
+ Message Syntax (CMS). The ASN.1 syntax is aligned with an expected
+ forthcoming change to ANS X9.44.
Status of this Memo
This InternetDraft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
@@ 39,21 +39,21 @@
InternetDrafts 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 InternetDrafts as reference
material or to cite them other than as "work in progress."
The list of current InternetDrafts can be accessed at
http://www.ietf.org/ietf/1idabstracts.txt
The list of InternetDraft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
 This InternetDraft will expire on September 8, 2010.
+ This InternetDraft will expire on November 29, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/licenseinfo) in effect on the date of
publication of this document. Please review these documents
@@ 73,35 +73,35 @@
1. Introduction...................................................3
2. Use in CMS.....................................................4
2.1. Underlying Components.....................................4
2.2. RecipientInfo Conventions.................................5
2.3. Certificate Conventions...................................5
2.4. SMIMECapabilities Attribute Conventions...................6
3. Security Considerations........................................7
4. IANA Considerations............................................9
5. Acknowledgements...............................................9
 6. References.....................................................9
 6.1. Normative References......................................9
 6.2. Informative References...................................10
+ 6. References....................................................10
+ 6.1. Normative References.....................................10
+ 6.2. Informative References...................................11
Appendix A. RSAKEM Key Transport Algorithm......................11
 A.1. Underlying Components....................................11
+ A.1. Underlying Components....................................12
A.2. Sender's Operations......................................12
A.3. Recipient's Operations...................................13
 Appendix B. ASN.1 Syntax.........................................14
+ Appendix B. ASN.1 Syntax.........................................15
B.1. RSAKEM Key Transport Algorithm..........................15
 B.2 Selected Underlying Components............................17
+ B.2. Selected Underlying Components...........................17
B.2.1. Key Derivation Functions............................17
 B.2.2 Symmetric KeyWrapping Schemes.......................19
 B.3 ASN.1 module..............................................20
 B.4 Examples..................................................25
 Authors' Addresses...............................................27
+ B.2.2. Symmetric KeyWrapping Schemes......................19
+ B.3. ASN.1 module.............................................20
+ B.4. Examples.................................................26
+ Authors' Addresses...............................................28
1. Introduction
The RSAKEM Key Transport Algorithm is a onepass (storeandforward)
mechanism for transporting keying data to a recipient using the
recipient's RSA public key.
Most previous key transport algorithms based on the RSA publickey
cryptosystem (e.g., the popular PKCS #1 v1.5 algorithm [PKCS1]) have
the following general form:
@@ 140,22 +140,32 @@
result, the algorithm enjoys a "tight" security proof in the random
oracle model. (In other padding schemes, such as PKCS #1 v1.5, the
input has structure and/or depends on the keying data, and the
provable security assurances are not as strong.) The approach is also
architecturally convenient because the publickey operations are
separate from the symmetric operations on the keying data. Another
benefit is that the length of the keying data is bounded only by the
symmetric keywrapping scheme, not the size of the RSA modulus.
The RSAKEM Key Transport Algorithm in various forms is being adopted
 in several draft standards as well as in ANSX9.44 and ISO/IEC 18033
 2. It has also been recommended by the NESSIE project [NESSIE].
+ in several draft standards as well as in ANSX9.44 [ANS9.44]. It has
+ also been recommended by the NESSIE project [NESSIE]. Originally,
+ [ANS9.44] specified the of different object identifier to identify
+ the RSAKEM Key Transport Algorithm. [ANS9.44] used idacgeneric
+ hybrid while this document uses idrsakem. These OIDs are used in
+ the KeyTransportInfo field to indicate the key encryption algorithm,
+ in certificates to allow recipients to restrict their public keys for
+ use with RSAKEM only, and in SMIME Capability attributes to allow
+ recipients to advertise their support for RSAKEM. Legacy
+ implementations that wish to interoperate with [ANSX9.44] should
+ consult that specification for more information on idacgeneric
+ hybrid.
For completeness, a specification of the algorithm is given in
Appendix A of this document; ASN.1 syntax is given in Appendix B.
NOTE: The term KEM stands for "key encapsulation mechanism" and
refers to the first three steps of the process above. The
formalization of key transport algorithms (or more generally,
asymmetric encryption schemes) in terms of key encapsulation
mechanisms is described further in research by Victor Shoup leading
to the development of the ISO/IEC 180332 standard [SHOUP].
@@ 165,67 +175,68 @@
The RSAKEM Key Transport Algorithm MAY be employed for one or more
recipients in the CMS envelopeddata content type (Section 6 of
[CMS]), where the keying data processed by the algorithm is the CMS
contentencryption key.
2.1. Underlying Components
A CMS implementation that supports the RSAKEM Key Transport
Algorithm MUST support at least the following underlying components:
 o For the key derivation function, KDF3 (see [IEEEP1363a]) based on
+ o For the key derivation function, KDF3 (see [ANS9.44]) based on
SHA256 (see [FIPS1803]). KDF3 is an instantiation of the
 Concatenation Key Derivation Function defined in [NISTSP80056A].
+ Concatenation Key Derivation Function defined in [NISTSP800
+ 56A].
 o For the keywrapping scheme, AESWrap128, i.e., the AES Key Wrap
 with a 128bit key encrypting key (see [AESWRAP]).
+ o For the keywrapping scheme, AESWrap128, i.e., the AES Key
+ Wrap with a 128bit key encrypting key (see [AESWRAP]).
An implementation SHOULD also support KDF2 (see [ANSX9.44]) based on
SHA1 (this function is also specified as the key derivation function
in [ANSX9.63]). The Camellia key wrap algorithm (see [CAMELLIA])
SHOULD be supported if Camellia is supported as a contentencryption
cipher. The TripleDES Key Wrap (see [3DESWRAP]) SHOULD also be
supported if TripleDES is supported as a contentencryption cipher.
It MAY support other underlying components. When AES or Camellia are
used, the data block size is 128 bits and the key size can be 128,
192, or 256 bits, while Triple DES requires a data block size of 64
bits and a key size of 112 or 168 bits.
2.2. RecipientInfo Conventions
When the RSAKEM Key Transport Algorithm is employed for a recipient,
the RecipientInfo alternative for that recipient MUST be
KeyTransRecipientInfo. The algorithmspecific fields of the
KeyTransRecipientInfo value MUST have the following values:
 o keyEncryptionAlgorithm.algorithm MUST be idrsakem (see Appendix
 B);
+ o keyEncryptionAlgorithm.algorithm MUST be idrsakem (see
+ Appendix B);
o keyEncryptionAlgorithm.parameters MUST be a value of type
 GenericHybridParameters, identifying the RSAKEM key encapsulation
 mechanism (see Appendix B);
+ GenericHybridParameters, identifying the RSAKEM key
+ encapsulation mechanism (see Appendix B);
o encryptedKey MUST be the encrypted keying data output by the
 algorithm, where the keying data is the contentencryption key (see
 Appendix A).
+ algorithm, where the keying data is the contentencryption key
+ (see Appendix A).
2.3. Certificate Conventions
The conventions specified in this section augment RFC 5280 [PROFILE].
A recipient who employs the RSAKEM Key Transport Algorithm MAY
identify the public key in a certificate by the same
AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using
the rsaEncryption object identifier [PKCS1]. The fact that the user
will accept RSAKEM with this public key is not indicated by the use
 of this identifier. This may be signalled by the use of the
+ of this identifier. This MAY be signaled by the use of the
appropriate SMIME Capabilities either in a message or in the
certificate.
If the recipient wishes only to employ the RSAKEM Key Transport
Algorithm with a given public key, the recipient MUST identify the
public key in the certificate using the idrsakem object identifier
(see Appendix B). When the idrsakem algorithm identifier appears in
the SubjectPublicKeyInfo algorithm field, the encoding SHALL omit the
parameters field from AlgorithmIdentifier. That is, the
AlgorithmIdentifier SHALL be a SEQUENCE of one component, the object
@@ 305,33 +316,33 @@
be particularly weak to lead to an attack that is not possible in the
random oracle model.
The RSA key size and the underlying components should be selected
consistent with the desired symmetric security level for an
application. Several security levels have been identified in NIST
FIPS PUB 80057 [NISTGUIDELINE]. For brevity, the first three levels
are mentioned here:
o 80bit security. The RSA key size SHOULD be at least 1024 bits,
 the hash function underlying the KDF SHOULD be SHA1 or above, and
 the symmetric keywrapping scheme SHOULD be AES Key Wrap, TripleDES
 Key Wrap, or Camellia Key Wrap.
+ the hash function underlying the KDF SHOULD be SHA1 or above,
+ and the symmetric keywrapping scheme SHOULD be AES Key Wrap,
+ TripleDES Key Wrap, or Camellia Key Wrap.
o 112bit security. The RSA key size SHOULD be at least 2048 bits,
 the hash function underlying the KDF SHOULD be SHA224 or above, and
 the symmetric keywrapping scheme SHOULD be AES Key Wrap, TripleDES
 Key Wrap, or Camellia Key Wrap.
+ the hash function underlying the KDF SHOULD be SHA224 or above,
+ and the symmetric keywrapping scheme SHOULD be AES Key Wrap,
+ TripleDES Key Wrap, or Camellia Key Wrap.
o 128bit security. The RSA key size SHOULD be at least 3072 bits,
 the hash function underlying the KDF SHOULD be SHA256 or above, and
 the symmetric keywrapping scheme SHOULD be AES Key Wrap or Camellia
 Key Wrap.
+ the hash function underlying the KDF SHOULD be SHA256 or above,
+ and the symmetric keywrapping scheme SHOULD be AES Key Wrap or
+ Camellia Key Wrap.
Note that the AES Key Wrap or Camellia Key Wrap MAY be used at all
three of these levels; the use of AES or Camellia does not require a
128bit security level for other components.
Implementations MUST protect the RSA private key and the content
encryption key. Compromise of the RSA private key may result in the
disclosure of all messages protected with that key. Compromise of the
contentencryption key may result in disclosure of the associated
encrypted content.
@@ 405,20 +416,25 @@
6.1. Normative References
[3DESWRAP] Housley, R. TripleDES and RC2 Key Wrapping. RFC
3217. December 2001.
[AESWRAP] Schaad, J. and R. Housley. Advanced Encryption
Standard (AES) Key Wrap Algorithm. RFC 3394.
September 2002.
+ [ANSX9.44] ASC X9F1 Working Group. American National Standard
+ X9.44: Public Key Cryptography for the Financial
+ Services Industry  Key Establishment Using
+ Integer Factorization Cryptography. 2007.
+
[ANSX9.63] American National Standard X9.632002: Public Key
Cryptography for the Financial Services Industry:
Key Agreement and Key Transport Using Elliptic
Curve Cryptography.
[CAMELLIA] Kato, A., Moriai, S., and Kanda, M.: Use of the
Camellia Encryption Algorithm in Cryptographic
Message Syntax. RFC 3657. December 2005.
[CMS] Housley, R. Cryptographic Message Syntax. RFC
@@ 442,37 +458,24 @@
[STDWORDS] Bradner, S. Key Words for Use in RFCs to Indicate
Requirement Levels. RFC 2119. March 1997.
6.2. Informative References
[AESWRAPPAD] Housley, R., and M. Dworkin. Advanced Encryption
Standard (AES) Key Wrap with Padding Algorithm.
RFC 5649. August 2009.
 [ANSX9.44] ASC X9F1 Working Group. American National Standard
 X9.44: Public Key Cryptography for the Financial
 Services Industry  Key Establishment Using
 Integer Factorization Cryptography. 2007.

[CMSOAEP] Housley, R. Use of the RSAESOAEP Key Transport
Algorithm in the Cryptographic Message Syntax
(CMS). RFC 3560. July 2003.
 [IEEEP1363a] IEEE Std 1363a2004: Standard Specifications for
 Public Key Cryptography: Additional Techniques.
 IEEE, 2004.

 [ISOIEC180332] ISO/IEC 180332:2005 Information technology 
 Security techniques  Encryption algorithms 
 Part 2: Asymmetric Ciphers. ISO/IEC, 2005.

[NESSIE] NESSIE Consortium. Portfolio of Recommended
Cryptographic Primitives. February 27, 2003.
Available via http://www.cryptonessie.org/.
[NISTGUIDELINE] National Institute of Standards and Technology.
Special Publication 80057: Recommendation for
Pairwise Key Establishment Schemes Using Discrete
Logarithm Cryptography. March 2007. Available via:
http://csrc.nist.gov/publications/index.html.
@@ 505,22 +508,22 @@
recipient decrypts the encrypted keying data using the recipient's
private key to recover the keying data.
A.1. Underlying Components
The algorithm has the following underlying components:
o KDF, a key derivation function, which derives keying data of a
specified length from a shared secret value;
 o Wrap, a symmetric keywrapping scheme, which encrypts keying Data
 using a keyencrypting key.
+ o Wrap, a symmetric keywrapping scheme, which encrypts keying
+ Data using a keyencrypting key.
In the following, kekLen denotes the length in bytes of the key
encrypting key for the underlying symmetric keywrapping scheme.
In this scheme, the length of the keying data to be transported MUST
be among the lengths supported by the underlying symmetric key
wrapping scheme. (Both the AES and Camellia Key Wraps, for instance,
require the length of the keying data to be a multiple of 8 bytes,
and at least 16 bytes.) Usage and formatting of the keying data
(e.g., parity adjustment for TripleDES keys) is outside the scope of
@@ 542,23 +545,23 @@
The sender performs the following operations:
1. Generate a random integer z between 0 and n1 (see Note), and
convert z to a byte string Z of length nLen, most significant byte
first:
z = RandomInteger (0, n1)
Z = IntegerToString (z, nLen)
 2. Encrypt the random integer z using the recipient's public key n,e)
 and convert the resulting integer c to a ciphertext C, a byte string
 of length nLen:
+ 2. Encrypt the random integer z using the recipient's public key
+ (n,e) and convert the resulting integer c to a ciphertext C, a byte
+ string of length nLen:
c = z^e mod n
C = IntegerToString (c, nLen)
3. Derive a keyencrypting key KEK of length kekLen bytes from the
byte string Z using the underlying key derivation function:
KEK = KDF (Z, kekLen)
@@ 636,22 +639,21 @@
of the implementation SHOULD be the same at these steps for all
ciphertexts C that are in range. (For example, IntegerToString
conversion should take the same amount of time regardless of the
actual value of the integer z.) The integer z, the string Z and other
intermediate results MUST be securely deleted when they are no longer
needed.
Appendix B. ASN.1 Syntax
The ASN.1 syntax for identifying the RSAKEM Key Transport Algorithm
 is an extension of the syntax for the "generic hybrid cipher" in
 ISO/IEC 180332 [ISOIEC180332], and is the same as employed in ANS
+ is an extension of the syntax for the "generic hybrid cipher" in ANS
X9.44 [ANSX9.44]. The syntax for the scheme is given in Section B.1.
The syntax for selected underlying components including those
mentioned above is given in B.2.
The following object identifier prefixes are used in the definitions
below:
is180332 OID ::= { iso(1) standard(0) is18033(18033) part2(2) }
nistAlgorithm OID ::= {
@@ 692,24 +694,24 @@
GenericHybridParameters ::= {
kem KeyEncapsulationMechanism,
dem DataEncapsulationMechanism
}
The fields of type GenericHybridParameters have the following
meanings:
o kem identifies the underlying key encapsulation mechanism, which
 in this case is also denoted as RSAKEM, per ISO/IEC 180332.
+ in this case is also denoted as RSAKEM.
The object identifier for RSAKEM (as a key encapsulation
 mechanism) is idkemrsa, which is defined in ISO/IEC 180332 as:
+ mechanism) is idkemrsa as:
idkemrsa OID ::= {
is180332 keyencapsulationmechanism(2) rsa(4)
}
The associated parameters for idkemrsa have type
RsaKemParameters:
RsaKemParameters ::= {
keyDerivationFunction KeyDerivationFunction,
@@ 752,30 +754,21 @@
X9SymmetricKeyWrappingSchemes ALGORITHM ::= {
aes128Wrap  aes192Wrap  aes256Wrap  tdesWrap,
...  allows for future expansion
}
CamelliaKeyWrappingSchemes ALGORITHM ::= {
Camellia128Wrap  Camellia192Wrap  Camellia256Wrap
}
 NOTE: The generic hybrid cipher in ISO/IEC 180332 can encrypt
 arbitrary data, hence the term "data encapsulation mechanism". The
 symmetric keywrapping schemes take the role of data encapsulation
 mechanisms in the RSAKEM Key Transport Algorithm. ISO/IEC 180332
 allows only three specific data encapsulation mechanisms, not
 including any of these symmetric keywrapping schemes. However, the
 ASN.1 syntax in that document expects that additional algorithms will
 be allowed.

B.2 Selected Underlying Components
+B.2. Selected Underlying Components
B.2.1. Key Derivation Functions
The object identifier for KDF2 (see [ANS X9.44]) is:
idkdfkdf2 OID ::= { x944components kdf2(1) }
The associated parameters identify the underlying hash function. For
alignment with ANS X9.44, the hash function MUST be an ASC X9
approved hash function. However, other hash functions MAY be used
@@ 831,21 +824,21 @@
kdf3 ALGORITHM ::= { OID idkdfkdf3 PARMS KDF3HashFunction }
KDF3HashFunction ::= AlgorithmIdentifier { KDF3HashFunctions }
KDF3HashFunctions ALGORITHM ::= {
X9HashFunctions,
...  implementations may define other methods
}
B.2.2 Symmetric KeyWrapping Schemes
+B.2.2. Symmetric KeyWrapping Schemes
The object identifiers for the AES Key Wrap depends on the size of
the key encrypting key. There are three object identifiers (see [AES
WRAP]):
idaes128Wrap OID ::= { nistAlgorithm aes(1) aes128Wrap(5) }
idaes192Wrap OID ::= { nistAlgorithm aes(1) aes192Wrap(25) }
idaes256Wrap OID ::= { nistAlgorithm aes(1) aes256Wrap(45) }
These object identifiers have no associated parameters.
@@ 888,21 +881,21 @@
{ iso(1) memberbody(2) 392 200011 61 security(1)
algorithm(1) keywrapalgorithm(3)
camellia256wrap(4) }
These object identifiers have no associated parameters.
camellia128Wrap ALGORITHM ::= { OID idcamellia128Wrap }
camellia192Wrap ALGORITHM ::= { OID idcamellia192Wrap }
camellia256Wrap ALGORITHM ::= { OID idcamellia256Wrap }
B.3 ASN.1 module
+B.3. ASN.1 module
CMSRSAKEM
{ iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) modules(0) cmsrsakem(21) }
DEFINITIONS ::=
BEGIN
 EXPORTS ALL
@@ 1099,27 +1092,28 @@
{ iso(1) memberbody(2) 392 200011 61 security(1)
algorithm(1) keywrapalgorithm(3)
camellia192wrap(3) }
idcamellia256Wrap OBJECT IDENTIFIER ::=
{ iso(1) memberbody(2) 392 200011 61 security(1)
algorithm(1) keywrapalgorithm(3)
camellia256wrap(4) }
camellia128Wrap ALGORITHM ::= { OID idcamellia128Wrap }
+
camellia192Wrap ALGORITHM ::= { OID idcamellia192Wrap }
camellia256Wrap ALGORITHM ::= { OID idcamellia256Wrap }
END
B.4 Examples
+B.4. Examples
As an example, if the key derivation function is KDF3 based on SHA
256 and the symmetric keywrapping scheme is the AES Key Wrap with a
128bit KEK, the AlgorithmIdentifier for the RSAKEM Key Transport
Algorithm will have the following value:
SEQUENCE {
idrsakem,  RSAKEM cipher
SEQUENCE {  GenericHybridParameters
SEQUENCE {  key encapsulation mechanism
@@ 1130,21 +1124,23 @@
SEQUENCE {  KDF3HashFunction
idsha256  SHA256; no parameters (preferred)
},
16  KEK length in bytes
},
SEQUENCE {  data encapsulation mechanism
idaes128Wrap  AES128 Wrap; no parameters
}
}
}
 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):
30 47
06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e  idrsakem
30 38
30 29
06 07 28 81 8c 71 02 02 04  idkemrsa
30 1e
30 19
06 0a 2b 81 05 10 86 48 09 2c 01 02  idkdfkdf3
30 0b