draft-ietf-smime-cms-rsa-kem-09.txt   draft-ietf-smime-cms-rsa-kem-10.txt 
S/MIME WG James Randall, Randall Consulting S/MIME WG James Randall, Randall Consulting
Internet Draft Burt Kaliski, EMC Internet Draft Burt Kaliski, EMC
Intended Status: Standards Track John Brainard, RSA Intended Status: Standards Track John Brainard, RSA
Sean Turner, IECA Sean Turner, IECA
Expires: June 8, 2010 December 8, 2009 Expires: June 8, 2010 December 8, 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-09.txt> <draft-ietf-smime-cms-rsa-kem-10.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 2, line 45 skipping to change at page 2, line 45
2.1. Underlying Components.....................................4 2.1. Underlying Components.....................................4
2.2. RecipientInfo Conventions.................................5 2.2. RecipientInfo Conventions.................................5
2.3. Certificate Conventions...................................5 2.3. Certificate Conventions...................................5
2.4. SMIMECapabilities Attribute Conventions...................6 2.4. SMIMECapabilities Attribute Conventions...................6
3. Security Considerations........................................7 3. Security Considerations........................................7
4. References.....................................................9 4. References.....................................................9
4.1. Normative References......................................9 4.1. Normative References......................................9
4.2. Informative References....................................9 4.2. Informative References....................................9
Appendix A. RSA-KEM Key Transport Algorithm......................11 Appendix A. RSA-KEM Key Transport Algorithm......................11
A.1. Underlying Components....................................11 A.1. Underlying Components....................................11
A.2. Sender's Operation.......................................11 A.2. Sender's Operations......................................11
A.3. Recipient's Operations...................................12 A.3. Recipient's Operations...................................12
Appendix B. ASN.1 Syntax.........................................14 Appendix B. ASN.1 Syntax.........................................14
B.2 Selected Underlying Components............................16 B.2 Selected Underlying Components............................16
B.2.1. Key Derivation Functions............................16 B.2.1. Key Derivation Functions............................16
B.2.2 Symmetric Key-Wrapping Schemes.......................18 B.2.2 Symmetric Key-Wrapping Schemes.......................18
B.3 ASN.1 module..............................................19 B.3 ASN.1 module..............................................19
B.4 Examples..................................................24 B.4 Examples..................................................24
IANA Considerations..............................................25 IANA Considerations..............................................25
Acknowledgements.................................................25 Acknowledgements.................................................25
Authors' Addresses...............................................26 Authors' Addresses...............................................26
skipping to change at page 7, line 29 skipping to change at page 7, line 29
mechanism [SHOUP]. While in practice a random-oracle result does not mechanism [SHOUP]. While in practice a random-oracle result does not
provide an actual security proof for any particular key derivation provide an actual security proof for any particular key derivation
function, the result does provide assurance that the general function, the result does provide assurance that the general
construction is reasonable; a key derivation function would need to construction is reasonable; a key derivation function would need to
be particularly weak to lead to an attack that is not possible in the be particularly weak to lead to an attack that is not possible in the
random oracle model. random oracle model.
The RSA key size and the underlying components should be selected The RSA key size and the underlying components should be selected
consistent with the desired symmetric security level for an consistent with the desired symmetric security level for an
application. Several security levels have been identified in NIST application. Several security levels have been identified in NIST
FIPS PUB 800-57 [NIST-GUIDELINE]. For brevity, the first threelevels FIPS PUB 800-57 [NIST-GUIDELINE]. For brevity, the first three levels
are mentioned here: are mentioned here:
o 80-bit security. The RSA key size SHOULD be at least 1024 bits, o 80-bit security. The RSA key size SHOULD be at least 1024 bits,
the hash function underlying the KDF SHOULD be SHA-1 or above, and the hash function underlying the KDF SHOULD be SHA-1 or above, and
the symmetric key-wrapping scheme SHOULD be AES Key Wrap, Triple-DES the symmetric key-wrapping scheme SHOULD be AES Key Wrap, Triple-DES
Key Wrap, or Camellia Key Wrap. Key Wrap, or Camellia Key Wrap.
o 112-bit security. The RSA key size SHOULD be at least 2048 bits, o 112-bit security. The RSA key size SHOULD be at least 2048 bits,
the hash function underlying the KDF SHOULD be SHA-224 or above, and the hash function underlying the KDF SHOULD be SHA-224 or above, and
the symmetric key-wrapping scheme SHOULD be AES Key Wrap, Triple-DES the symmetric key-wrapping scheme SHOULD be AES Key Wrap, Triple-DES
skipping to change at page 11, line 42 skipping to change at page 11, line 42
require the length of the keying data to be a multiple of 8 bytes, 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 and at least 16 bytes.) Usage and formatting of the keying data
(e.g., parity adjustment for Triple-DES keys) is outside the scope of (e.g., parity adjustment for Triple-DES keys) is outside the scope of
this algorithm. With some key derivation functions, it is possible to this algorithm. With some key derivation functions, it is possible to
include other information besides the shared secret value in the include other information besides the shared secret value in the
input to the function. Also, with some symmetric key-wrapping input to the function. Also, with some symmetric key-wrapping
schemes, it is possible to associate a label with the keying data. schemes, it is possible to associate a label with the keying data.
Such uses are outside the scope of this document, as they are not Such uses are outside the scope of this document, as they are not
directly supported by CMS. directly supported by CMS.
A.2. Sender's Operation A.2. Sender's Operations
Let (n,e) be the recipient's RSA public key (see [PKCS1] for details) Let (n,e) be the recipient's RSA public key (see [PKCS1] for details)
and let K be the keying data to be transported. and let K be the keying data to be transported.
Let nLen denote the length in bytes of the modulus n, i.e., the least Let nLen denote the length in bytes of the modulus n, i.e., the least
integer such that 2^{8*nLen} > n. integer such that 2^{8*nLen} > n.
The sender performs the following operations: The sender performs the following operations:
1. Generate a random integer z between 0 and n-1 (see Note), and 1. Generate a random integer z between 0 and n-1 (see Note), and
skipping to change at page 20, line 51 skipping to change at page 20, line 51
GenericHybridParameters ::= SEQUENCE { GenericHybridParameters ::= SEQUENCE {
kem KeyEncapsulationMechanism, kem KeyEncapsulationMechanism,
dem DataEncapsulationMechanism dem DataEncapsulationMechanism
} }
KeyEncapsulationMechanism ::= AlgorithmIdentifier {{KEMAlgorithms}} KeyEncapsulationMechanism ::= AlgorithmIdentifier {{KEMAlgorithms}}
KEMAlgorithms ALGORITHM ::= { kem-rsa, ... } KEMAlgorithms ALGORITHM ::= { kem-rsa, ... }
kem-rsa ALGORITHM ::= { OID id-kem-rsa PARMS RsaKemParameters } kem-rsa ALGORITHM ::= { OID id-kem-rsa PARAMS RsaKemParameters }
id-kem-rsa OID ::= { id-kem-rsa OID ::= {
is18033-2 key-encapsulation-mechanism(2) rsa(4) is18033-2 key-encapsulation-mechanism(2) rsa(4)
} }
RsaKemParameters ::= SEQUENCE { RsaKemParameters ::= SEQUENCE {
keyDerivationFunction KeyDerivationFunction, keyDerivationFunction KeyDerivationFunction,
keyLength KeyLength keyLength KeyLength
} }
KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}} KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}}
 End of changes. 5 change blocks. 
5 lines changed or deleted 5 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/