]>
Use of the RSAKEM Algorithm in the Cryptographic Message Syntax (CMS)
Vigil Security, LLC
516 Dranesville Road
Herndon, VA
20170
US
housley@vigilsec.com
sn3rd
sean@sn3rd.com
Security
Limited Additional Mechanisms for PKIX and SMIME
Key Encapsulation Mechanism (KEM)
KEMRecipientInfo
The RSA Key Encapsulation Mechanism (RSAKEM) Algorithm is a onepass
(storeandforward) cryptographic mechanism for an originator to securely
send keying material to a recipient using the recipient's RSA public key.
The RSAKEM Algorithm is specified in Clause 11.5 of ISO/IEC: 180332:2006.
This document specifies the conventions for using the RSAKEM Algorithm as a
standalone KEM algorithm and the conventions for using the RSAKEM Algorithm
with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as
specified in RFC XXXX. This document obsoletes RFC 5990.
RFC EDITOR: Please replace XXXX with the RFC number assigned to draftietflampscmskemri.
About This Document
Status information for this document may be found at .
Discussion of this document takes place on the
Limited Additional Mechanisms for PKIX and SMIME Working Group mailing list (),
which is archived at .
Subscribe at .
Introduction
The RSA Key Encapsulation Mechanism (RSAKEM) Algorithm is a onepass
(storeandforward) cryptographic mechanism for an originator to securely
send keying material to a recipient using the recipient's RSA public key.
The RSAKEM Algorithm is specified in Clause 11.5 of .
The RSAKEM Algorithm takes a different approach than other RSA key
transport mechanisms , with the goal of providing higher
security assurance while also satisfying the KEM interface. The
RSAKEM Algorithm encrypts a random integer with the recipient's
RSA public key, and derives a shared secret from the random integer. The
originator and recipient can derive a symmetric key from the shared
secret. For example, a keyencryption key can be derived from the shared
secret to wrap a contentencryption key.
In the Cryptographic Message Syntax (CMS) using
KEMRecipientInfo , the shared secret value
is input to a keyderivation function to compute a keyencryption key, and
wrap a symmetric contentencryption key with the keyencryption key. In
this way, the originator and the recipient end up with the same
contentencryption key.
For completeness, a specification of the RSAKEM Algorithm is given in
Appendix A of this document; ASN.1 syntax is given in Appendix B.
RSAKEM Algorithm Rationale
The RSAKEM Algorithm provides higher security assurance than other
variants of the RSA cryptosystem for two reasons. First, the input to the
underlying RSA operation is a stringencoded random integer between 0 and n1,
where n is the RSA modulus, so it does not have any structure that could be
exploited by an adversary. Second, the input is independent of the keying
material so the result of the RSA decryption operation is not directly
available to an adversary. As a result, the RSAKEM 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 material, 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 material. Another benefit is that the length of the keying material
is determined by the symmetric algorithms, not the size of the RSA modulus.
RSAKEM Algorithm Summary
All KEM algorithms provide three functions: KeyGen(), Encapsulate(),
and Decapsulate().
The following summarizes these three functions for RSAKEM:
KeyGen() > (pk, sk):

Generate the public key (pk) and a private key (sk) as described
in .
Encapsulate(pk) > (ct, SS):

Given the recipient's public key (pk), produce a ciphertext (ct) to be
passed to the recipient and a shared secret (SS) for use by the originator,
as follows:

1. Generate a random integer z between 0 and n1.

2. Encrypt the integer z with the recipient's RSA public key to obtain the ciphertext:

3. Derive a shared secret from the integer z using a Key Derivation Function (KDF):

4. The ciphertext and the shared secret are returned by the function. The
originator sends the ciphertext to the recipient.
Decapsulate(sk, ct) > SS:

Given the private key (sk) and the ciphertext (ct), produce the
shared secret (SS) for the recipient as follows:

1. Decrypt the ciphertext with the recipient's RSA private key
to obtain the random integer z:

2. Derive a shared secret from the integer z:
3. The shared secret is returned by the function.
CMS KEMRecipientInfo Processing Summary
To support the RSAKEM algorithm, the CMS originator MUST implement
Encapsulate().
Given a contentencryption key CEK, the RSAKEM Algorithm processing by the
originator to produce the values that are carried in the CMS KEMRecipientInfo
can be summarized as:

1. Obtain the shared secret using the Encapsulate() function of the
RSAKEM algorithm and the recipient's RSA public key:

2. Derive a keyencryption key KEK from the shared secret:

3. Wrap the CEK with the KEK to obtain wrapped keying material WK:

4. The originator sends the ciphertext and WK to the recipient in the CMS
KEMRecipientInfo structure.
To support the RSAKEM algorithm, the CMS recipient MUST implement
Decapsulate().
The RSAKEM algorithm recipient processing of the values obtained from the
KEMRecipientInfo structure can be summarized as:

1. Obtain the shared secret using the Decapsulate() function of the
RSAKEM algorithm and the recipient's RSA private key:

2. Derive a keyencryption key KEK from the shared secret:

3. Unwrap the WK with the KEK to obtain contentencryption key CEK:
Note that the KDF used to process the KEMRecipientInfo structure MAY be
different from the KDF used to derive the shared secret in the RSAKEM
algorithm.
Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.
ASN.1
CMS values are generated using ASN.1 , which uses the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) .
Changes Since RFC 5990
RFC 5990 specified the conventions for using the RSAKEM Algorithm
in CMS as a key transport algorithm. That is, it used KeyTransRecipientInfo
for each recipient. Since the publication of RFC 5990, a new KEMRecipientInfo
structure has been defined to support KEM
algorithms. When the idrsakem algorithm identifier appears in the
SubjectPublicKeyInfo field of a certificate, the complex parameter structure
defined in RFC 5990 can be omitted; however, the parameters are allowed for
backward compatibility. Also, to avoid visual confusion with idkemrsa,
idrsakemspki is introduced as an alias for idrsakem.
RFC 5990 used EK as the EncryptedKey, which is the concatenation of
the ciphertext C and the wrapped key WK, EK = (C  WK). The use of EK was
necessary to align with the KeyTransRecipientInfo structure. In this
document, the ciphertext and the wrapped key are sent in separate fields of
the KEMRecipientInfo structure. In particular, the ciphertext is carried in
the kemct field, and wrapped key is carried in the encryptedKey
field. See for details about the computation of the ciphertext.
RFC 5990 included support for Camellia and TripleDES block ciphers;
discussion of these block ciphers is removed from this document, but
the algorithm identifiers remain in the ASN.1 Module .
RFC 5990 included support for SHA1 hash function; discussion of this
hash function is removed from this document, but the algorithm identifier
remains in the ASN.1 module .
RFC 5990 required support for the KDF3 keyderivation function ;
this document continues to require support for the KDF3 keyderivation function,
but it requires support for SHA256 as the hash function.
RFC 5990 recommended support for alternatives to KDF3 and AESWrap128;
this document simply states that other keyderivation functions and other
keyencryption algorithms MAY be supported.
RFC 5990 supported the future definition of additional KEM algorithms that
use RSA; this document supports only one, and it is identified by the
idkemrsa object identifier.
RFC 5990 included an ASN.1 module; this document provides an alternative
ASN.1 module that follows the conventions established in ,
, and . The new ASN.1 module
produces the same bitsonthewire as the one in RFC 5990.
Use of the RSAKEM Algorithm in CMS
The RSAKEM Algorithm MAY be employed for one or more recipients in the
CMS envelopeddata content type , the CMS authenticateddata
content type , or the CMS authenticatedenvelopeddata
content type . In each case, the KEMRecipientInfo
is used with the RSAKEM Algorithm
to securely transfer the contentencryption key from the originator to
the recipient.
Mandatory To Implement
A CMS implementation that supports the RSAKEM Algorithm MUST support at
least the following underlying components:

For the keyderivation function, an implementation MUST support
KDF3 with SHA256 .

For keywrapping, an implementation MUST support the
AESWrap128 keyencryption algorithm.
An implementation MAY also support other keyderivation functions and
other keyencryption algorithms as well.
RecipientInfo Conventions
When the RSAKEM Algorithm is employed for a recipient, the
RecipientInfo alternative for that recipient MUST be
OtherRecipientInfo using the KEMRecipientInfo structure
. The fields of the
KEMRecipientInfo MUST have the following values:

version is the syntax version number; it MUST be 0.

rid identifies the recipient's certificate or public key.

kem identifies the KEM algorithm; it MUST contain idkemrsa.

kemct is the ciphertext produced for this recipient; it contains
C from steps 1 and 2 of Originator's Operations in .

kdf identifies the keyderivation function (KDF). Note that the
KDF used for CMS RecipientInfo process MAY be different than the KDF
used within the RSAKEM Algorithm.

kekLength is the size of the keyencryption key in octets.

ukm is an optional random input to the keyderivation function.

wrap identifies a keyencryption algorithm used to encrypt the
keying material.

encryptedKey is the result of encrypting the keying material with the
keyencryption key. When used with the CMS envelopeddata content
type , the keying material is a contentencryption key. When
used with the CMS authenticateddata content type , the
keying material is a messageauthentication key. When used with the
CMS authenticatedenvelopeddata content type , the
keying material is a contentauthenticatedencryption key.
NOTE: For backward compatibility, implementations MAY also support
RSAKEM Key Transport Algorithm, identified by idrsakemspki, which uses
KeyTransRecipientInfo as specified in .
Certificate Conventions
The conventions specified in this section augment RFC 5280 .
A recipient who employs the RSAKEM Algorithm MAY identify the public key
in a certificate by the same AlgorithmIdentifier as for the
PKCS #1 v1.5 algorithm, that is, using the rsaEncryption object
identifier . The fact that the recipient will accept RSAKEM
with this public key is not indicated by the use of this object
identifier. The willingness to accept the RSAKEM Algorithm MAY be
signaled by the use of the SMIMECapabilities Attribute as specified in
or the SMIMECapabilities certificate
extension as specified in .
If the recipient wishes only to employ the RSAKEM Algorithm with a given
public key, the recipient MUST identify the public key in the certificate
using the idrsakemspki object identifier; see . The use
of the idrsakemspki object identifier allows certificates that were
issued to be compatible with RSAKEM Key Transport to also be used with
this specification. When the idrsakemspki object identifier appears
in the SubjectPublicKeyInfo algorithm field of the certificate, the
parameters field from AlgorithmIdentifier SHOULD be absent. That is, the
AlgorithmIdentifier SHOULD be a SEQUENCE of one component, the
idrsakemspki object identifier. With absent parameters, the KDF3
keyderivation function with SHA256 are used to
derive the shared secret.
When the AlgorithmIdentifier parameters are present, the
GenericHybridParameters MUST be used. Within the kem element, the algorithm
identifier MUST be set to idkemrsa, and RsaKemParameters MUST be included.
As described in , the GenericHybridParameters constrain the values
that can be used with the RSA public key for the kdf, kekLength, and wrap
fields of the KEMRecipientInfo structure.
Regardless of the AlgorithmIdentifier used, the RSA public key MUST be
carried in the subjectPublicKey BIT STRING within the SubjectPublicKeyInfo
field of the certificate using the RSAPublicKey type defined in .
The intended application for the public key MAY be indicated in the key usage
certificate extension as specified in . If the
keyUsage extension is present in a certificate that conveys an RSA public key
with the idrsakemspki object identifier as discussed above, then the key
usage extension MUST contain only the following value:
Other keyUsage extension values MUST NOT be
present. That is, a public key intended to be employed only with the
RSAKEM Algorithm MUST NOT also be employed for data encryption or
for digital signatures. 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.
SMIMECapabilities Attribute Conventions
defines the SMIMECapabilities attribute to
announce a partial list of algorithms that an S/MIME implementation can
support. When constructing a CMS signeddata content type ,
a compliant implementation MAY include the SMIMECapabilities attribute
that announces support for the RSAKEM Algorithm.
The SMIMECapability SEQUENCE representing the RSAKEM Algorithm MUST
include the idrsakemspki object identifier in the capabilityID field;
see for the object identifier value, and see
for examples. When the idrsakemspki object identifier appears in the
capabilityID field and the parameters are present, then the parameters
field MUST use the GenericHybridParameters type.
The fields of the GenericHybridParameters type have the following meanings:

kem is an AlgorithmIdentifer. The algorithm field MUST be set to idkemrsa,
and the parameters field MUST be RsaKemParameters, which is a SEQUENCE of an
AlgorithmIdentifier that identifies the supported keyderivation function
and a positive INTEGER that identifies the length of the keyencryption
key in octets.

dem is an AlgorithmIdentifier. The algorithm field MUST be present, and it
identifies the keyencryption algorithm. The parameters are optional. If the
GenericHybridParameters are present, then the provided dem value MUST be
used in the wrap field of KEMRecipientInfo.
If the GenericHybridParameters are present, then the provided kem value MUST
be used as the keyderivation function in the kdf field of KEMRecipientInfo,
and the provided key length MUST be used in the kekLength of KEMRecipientInfo.
Security Considerations
The RSAKEM Algorithm should be considered as a replacement for the key transport portion of the
widely implemented PKCS #1 v1.5 for new applications
that use CMS to avoid potential vulnerabilities to chosenciphertext
attacks and gain a tighter security proof; however, the RSAKEM Algorithm
has the disadvantage of slightly longer encrypted keying material. With
PKCS #1 v1.5, the originator encrypts the keyencryption key directly with
the recipient's RSA public key. With the RSAKEM, the keyencryption key
is encrypted separately.
The security of the RSAKEM Algorithm can be shown to be tightly related
to the difficulty of either solving the RSA problem, or breaking the
underlying symmetric keyencryption algorithm, if the underlying
keyderivation function is modeled as a random oracle, and assuming that
the symmetric keyencryption algorithm satisfies the properties of a
data encapsulation mechanism . While in practice a randomoracle
result does not provide an actual security proof for any particular
keyderivation function, the result does provide assurance that the general
construction is reasonable; a keyderivation function would need to be
particularly weak to lead to an attack that is not possible in the
randomoracle model.
The RSA key size and the underlying components need to be selected
consistent with the desired security level. Several security levels
have been identified in the NIST SP 80057 Part 1 . For example, one way
to achieve 128bit security, the RSA key size would be at least 3072 bits,
the keyderivation function would be SHA256, and the symmetric
keyencryption algorithm would be AES Key Wrap with a 128bit key.
Implementations MUST protect the RSA private key, the keyencryption key,
the contentencryption key, messageauthentication key, and the
contentauthenticatedencryption key. Disclosure of the RSA private key
could result in the compromise of all messages protected with that key.
Disclosure of the keyencryption key, the contentencryption key, or the
contentauthenticatedencryption key could result in compromise of the
associated encrypted content. Disclosure of the keyencryption key, the
messageauthentication key, or the contentauthenticatedencryption key
could allow modification of the associated authenticated content.
Additional considerations related to key management may be found in
.
The security of the RSAKEM Algorithm depends on a quality random number
generator. For further discussion on random number generation,
see .
The RSAKEM Algorithm does not use an explicit padding scheme; instead,
an encoded random value (z) between zero and the RSA modulus minus one (n1)
is directly encrypted with the recipient's RSA public key. The
IntegerToString(z, nLen) encoding produces a string that is the full length of
the RSA modulus. In addition, the random value is passed through a keyderivation
function (KDF) to reduce possible harm from a poorly implemented random number
source or a maliciously chosen random value (z). Implementations MUST NOT
use z directly for any purpose.
As long as a fresh random integer z is chosen as part of each invocation
of the Encapsulate() function, RSAKEM does not degrade as the number of
ciphertexts increases. Since RSA encryption provides a bijective map,
a collision in the KDF is the only way that RSAKEM can produce more than
one ciphertext that encapsulates the same shared secret.
The RSAKEM Algorithm provides a fixedlength ciphertext. The recipient MUST
check that the received byte string is the expected length and the length
corresponds to an integer in the expected range prior to attempting decryption
with their RSA private key as described in Steps 1 and 2 of .
Implementations SHOULD NOT reveal information about intermediate
values or calculations, whether by timing or other "side channels",
otherwise an opponent may be able to determine information about
the keying data and/or the recipient's private key. Although not all
intermediate information may be useful to an opponent, it is
preferable to conceal as much information as is practical, unless
analysis specifically indicates that the information would not be
useful to an opponent.
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. RSA public keys have often
been employed for multiple purposes such as key transport and digital
signature without any known bad interactions; however, such combined use
of an RSA key pair is NOT RECOMMENDED in the future (unless the different
schemes are specifically designed to be used together).
Accordingly, an RSA key pair used for the RSAKEM Algorithm SHOULD NOT
also be used for digital signatures. Indeed, the Accredited Standards
Committee X9 (ASC X9) requires such a separation between key pairs used
for key establishment and key pairs used for digital signature
. Continuing this principle of key separation, a key pair
used for the RSAKEM Algorithm SHOULD NOT be used with other key
establishment schemes, or for data encryption, or with more
than one set of underlying algorithm components.
It is acceptable to use the same RSA key pair for RSAKEM Key Transport
as specified in and this specification. This is acceptable
because the operations involving the RSA public key and the RSA private
key are identical in the two specifications.
Parties can gain assurance that implementations are correct through
formal implementation validation, such as the NIST Cryptographic
Module Validation Program (CMVP) .
IANA Considerations
For the ASN.1 Module in , IANA is requested to assign an
object identifier (OID) for the module identifier. The OID for the module
should be allocated in the "SMI Security for S/MIME Module Identifier"
registry (1.2.840.113549.1.9.16.0), and the Description for the new OID
should be set to "idmodcmsrsakem2023".
IANA is requested to update the idalgrsakem entry in the SMI Security
for S/MIME Algorithms (1.2.840.113549.1.9.16.3) repository to refer to this
document. In addition, IANA is requested to add the following note to the
registry:
Value 14, "idalgrsakem," is also referred to as "idrsakemspki."
References
Normative References
Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)
Vigil Security, LLC
Entrust
DigiCert, Inc.
The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantumsecure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. This document updates RFC 5652.
Advanced Encryption Standard (AES) Key Wrap Algorithm
Cryptographic Message Syntax (CMS) AuthenticatedEnvelopedData Content Type
This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticatedenvelopeddata content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS envelopeddata content type are also supported by the CMS authenticatedenvelopeddata content type. [STANDARDSTRACK]
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internetspecific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internetspecific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDSTRACK]
Cryptographic Message Syntax (CMS)
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDSTRACK]
New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME
The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bitsonthewire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.
New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bitsonthewire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.
Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)
The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits onthewire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.
PKCS #1: RSA Cryptography Specifications Version 2.2
This document provides recommendations for the implementation of publickey cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.
This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' PublicKey Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.
This document also obsoletes RFC 3447.
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and nonrepudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751.
Secure Hash Standard
National Institute of Standards and Technology
Information technology  Abstract Syntax Notation One (ASN.1): Specification of basic notation
ITUT
Information technology  ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
ITUT
Public Key Cryptography for the Financial Services Industry  Key Establishment Using Integer Factorization Cryptography
American National Standards Institute
Information technology  Security techniques  Encryption algorithms  Part 2: Asymmetric ciphers
ISO/IEC JTC 1/SC 27
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Informative References
Randomness Requirements for Security
Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudorandom processes to generate secret quantities can result in pseudosecurity. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.
Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudorandom number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities
This document defines a certificate extension for inclusion of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities in X.509 public key certificates, as defined by RFC 3280. This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIME Capabilities signed attribute in S/MIME messages according to RFC 3851. [STANDARDSTRACK]
Use of the RSAKEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)
The RSAKEM Key Transport Algorithm is a onepass (storeandforward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) 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 an expected forthcoming change to American National Standard (ANS) X9.44.
Security Considerations for the SHA0 and SHA1 MessageDigest Algorithms
This document includes security considerations for the SHA0 and SHA1 message digest algorithm. This document is not an Internet Standards Track specification; it is published for informational purposes.
Recommendation for Key Management:Part 1  General
National Institute of Standards and Technology
Cryptographic Module Validation Program
National Institute of Standards and Technology
A Proposal for an ISO Standard for Public Key Encryption
RSAKEM Algorithm
The RSAKEM Algorithm is a onepass (storeandforward) cryptographic
mechanism for an originator to securely send keying material to a recipient
using the recipient's RSA public key.
With the RSAKEM Algorithm, an originator encrypts a random integer (z) with
the recipient's RSA public key to produce a ciphertext (ct), and the originator
derives a shared secret (SS) from the random integer (z). The originator then
sends the ciphertext (ct) to the recipient. The recipient decrypts the
ciphertext (ct) using their private key to recover the random integer (z),
and the recipient derives a shared secret (SS) from the random integer(z). In
this way, originator and recipient obtain the same shared secret (SS).
The RSAKEM Algorithm depends on a keyderivation function (KDF), which is
used to derive the shared secret (SS). Many keyderivation functions support
the inclusion of other information in addition to the shared secret (SS) in
the input to the function; however, no other information is included as an
input to the KDF by the RSAKEM Algorithm.
Originator's Operations: RSAKEM Encapsulate()
Let (n,e) be the recipient's RSA public key; see for details.
Let nLen denote the length in bytes of the modulus n, i.e., the least
integer such that 2^(8*nLen) > n.
The originator performs the following operations:

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:

Encrypt the random integer z using the recipient's RSA public key
(n,e), and convert the resulting integer c to a ciphertext C, a
byte string of length nLen:

Derive a symmetric shared secret SS of length ssLen bytes (which
MUST be the length of the keyencryption key) from the
byte string Z using the underlying keyderivation function:

Output the shared secret SS and the ciphertext ct. Send the
ciphertext ct to the recipient.
NOTE: The random integer z MUST be generated independently at random
for different encryption operations, whether for the same or different
recipients.
Recipient's Operations: RSAKEM Decapsulate()
Let (n,d) be the recipient's RSA private key; see for details,
but other private key formats are allowed.
Let ct be the ciphertext received from the originator.
Let nLen denote the length in bytes of the modulus n.
The recipient performs the following operations:

If the length of the encrypted keying material is less than nLen
bytes, output "decryption error", and stop.

Convert the ciphertext ct to an integer c, most significant byte
first (see NOTE below):
If the integer c is not between 0 and n1, output "decryption
error", and stop.

Decrypt the integer c using the recipient's private key
(n,d) to recover an integer z (see NOTE below):

Convert the integer z to a byte string Z of length nLen, most
significant byte first (see NOTE below):

Derive a shared secret SS of length ssLen bytes from the byte
string Z using the keyderivation function (see NOTE below):

Output the shared secret SS.
NOTE: Implementations SHOULD NOT reveal information about the
integer z, the string Z, or about the calculation of the
exponentiation in Step 2, the conversion in Step 3, or the key
derivation in Step 4, whether by timing or other "side channels".
The observable behavior 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.
ASN.1 Syntax
The ASN.1 syntax for identifying the RSAKEM Algorithm
is an extension of the syntax for the "generic hybrid cipher" in
ANS X9.44 .
The ASN.1 Module is unchanged from RFC 5990. The idrsakemspki
object identifier is used in a backward compatible manner
in certificates and SMIMECapabilities .
Of course, the use of the idkemrsa object identifier in the
new KEMRecipientInfo structure
was not yet defined at the time that RFC 5990 was written.
Underlying Components
Implementations that conform to this specification MUST support
the KDF3 keyderivation function using SHA256 .
KDF2 and KDF3 are both keyderivation functions based on
a hash function. The only difference between KDF2 and KDF3 is the order
of the components to be hashed.
The object identifier for KDF3 is:
The KDF3 parameters identify the underlying hash function. For
alignment with the ANS X9.44, the hash function MUST be an ASC X9approved
hash function. While the SHA1 hash algorithm is included in the
ASN.1 definitions, SHA1 MUST NOT be used. SHA1 is considered
to be obsolete; see . SHA1 remains in the ASN.1 module for
compatibility with RFC 5990. In addition, other hash functions MAY be
used with CMS.
Implementations that conform to this specification MUST support
the AES Key Wrap keyencryption algorithm with a 128bit
key. There are three object identifiers for the AES Key Wrap, one for
each permitted size of the keyencryption key. There are three object
identifiers imported from , and none of these algorithm
identifiers have associated parameters:
ASN.1 Module
RFC EDITOR: Please replace TBD2 with the value assigned by IANA
during the publication of .
SMIMECapabilities Examples
To indicate support for the RSAKEM algorithm coupled with the KDF3
keyderivation function with SHA256 and the AES Key Wrap symmetric
keyencryption algorithm 128bit keyencryption key, the
SMIMECapabilities will include the following entry:
This SMIMECapability value has the following DER encoding (in hexadecimal):
To indicate support for the RSAKEM algorithm coupled with the KDF3
keyderivation function with SHA384 and the AES Key Wrap symmetric
keyencryption algorithm 192bit keyencryption key, the
SMIMECapabilities will include the following SMIMECapability value
(in hexadecimal):
To indicate support for the RSAKEM algorithm coupled with the KDF3
keyderivation function with SHA512 and the AES Key Wrap symmetric
keyencryption algorithm 256bit keyencryption key, the
SMIMECapabilities will include the following SMIMECapability value
(in hexadecimal):
RSAKEM CMS EnvelopedData Example
This example shows the establishment of an AES128 contentencryption
key using:

RSAKEM with a 3072bit key and KDF3 with SHA256;

KEMRecipientInfo key derivation using KDF3 with SHA256; and

KEMRecipientInfo key wrap using AES128KEYWRAP.
In realworld use, the originator would encrypt the contentencryption
key in a manner that would allow decryption with their own private key
as well as the recipient's private key. This is omitted in an attempt
to simplify the example.
Originator RSAKEM Encapsulate() Processing
Alice obtains Bob's public key:
Bob's RSA public key has the following key identifier:
Alice randomly generates integer z between 0 and n1:
Alice encrypts integer z using the Bob's RSA public key, the result is
called ct:
Alice derives the shared secret (SS) using KDF3 with SHA256:
Originator CMS Processing
Alice encodes the CMSORIforKEMOtherInfo structure with the algorithm
identifier for AES128KEYWRAP and a key length of 16 octets.
The DER encoding of CMSORIforKEMOtherInfo produces 18 octets:
The CMSORIforKEMOtherInfo structure contains:
Alice derives the keyencryption key from shared secret produced
by RSAKEM Encapsulate() and the CMSORIforKEMOtherInfo structure
with KDF3 and SHA256, the KEK is:
Alice randomly generates a 128bit contentencryption key:
Alice uses AES128KEYWRAP to encrypt the 128bit contentencryption
key with the derived keyencryption key:
Alice encrypts the padded content using AES128CBC with the
contentencryption key. The 16octet IV used is:
The padded content plaintext is:
The resulting ciphertext is:
Alice encodes the EnvelopedData (using KEMRecipientInfo) and
ContentInfo, and then sends the result to Bob. The Base64encoded
result is:
This result decodes to:
Recipient RSAKEM Decapsulate() Processing
Bob's private key:
Bob checks that the length of the ciphertext is less than nLen bytes.
Bob checks that the ciphertext is greater than zero and is less
than his RSA modulus.
Bob decrypts the ciphertext with his RSA private key to obtain
the integer z:
Bob checks that the integer z is greater than zero and is less
than his RSA modulus.
Bob derives the shared secret (SS) using KDF3 with SHA256:
Recipient CMS Processing
Bob encodes the CMSORIforKEMOtherInfo structure with the algorithm
identifier for AES128KEYWRAP and a key length of 16 octets.
The DER encoding of CMSORIforKEMOtherInfo is not repeated here.
Bob derives the keyencryption key from shared secret and the
CMSORIforKEMOtherInfo structure with KDF3 and SHA256, the KEK is:
Bob uses AESKEYWRAP to decrypt the contentencryption key
with the keyencryption key; the contentencryption key is:
Bob decrypts the content using AES128CBC with the content
encryption key. The 16octet IV used is:
The received ciphertext content is:
The resulting padded plaintext content is:
After stripping the AESCBC padding, the plaintext content is:
Acknowledgements
We thank James Randall, Burt Kaliski, and John Brainard as the
original authors of ; this document is based on their work.
We thank the members of the ASC X9F1 working group for their
contributions to drafts of ANS X9.44, which led to .
We thank Blake Ramsdell, Jim Schaad, Magnus Nystrom, Bob Griffin,
and John Linn for helping bring to fruition.
We thank
Burt Kaliski,
Alex Railean,
Joe Mandel,
Mike Ounsworth,
Peter Campbell,
Daniel Van Geest, and
David Ireland
for careful review and thoughtful comments that greatly improved this document.