]>
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
with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as
specified in 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. The RSAKEM Algorithm encrypts a random integer
with the recipient's RSA public key, derives a keyencryption key from
the random integer, and wraps a symmetric contentencryption key with
the keyencryption key. In this way, the originator and the recipient
end up with the same contentencryption key. Given a
contentencryption key CEK, RSAKEM can be summarized as:
 Generate a random integer z between 0 and n1.

Encrypt the integer z with the recipient's RSA public key:

Derive a keyencryption key KEK from the integer z:

Wrap the CEK with the KEK to obtain wrapped keying material WK:
 The originator sends c and WK to the recipient.
This different approach provides higher security assurance for two
reasons. First, the input to the underlying RSA operation is effectively
a 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 bounded only by the symmetric keywrapping algorithm, not the size of
the RSA modulus.
For completeness, a specification of the RSAKEM Algorithm is given in
Appendix A of this document; ASN.1 syntax is given in Appendix B.
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. This approach resulted in a very complex parameter
definition with the idrsakem algorithm identifier. Implementation
experience with many different algorithms has shown that complex
parameter structures cause interoperability issues. Since the publication
of RFC 5990, a new KEMRecipientInfo structure
has been defined to support KEM algorithms, and this new structure avoids the
complex parameters structure that was used in RFC 5990. Likewise, when
the idrsakem algorithm identifier appears in the SubjectPublicKeyInfo
field of a certificate, this document encourages the omission of any
parameters.
RFC 5990 uses EK and the EncryptedKey, which the concatenation of
C and WK (C  WK). The use of EK is necessary to align with the
KeyTransRecipientInfo structure. In this document, C and WK are sent
in separate fields of new KEMRecipientInfo structure. In particular,
C is carried in the kemct field, and WK is carried in the encryptedKey
field.
RFC 5990 supports 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 includes 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 includes 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 recommends support for alternatives to KDF3 and AESWrap128;
this document simply states that other keyderivation functions and
keyencryption algorithms MAY be supported.
RFC 5990 includes 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 with the RSAKEM Algorithm
to securely transfer the contentencryption key from the originator to
the recipient.
Underlying Components
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
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 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
contentencryption key.

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, 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 appropriate SMIME Capabilities either in a
message or in the certificate.
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 idrsakem object identifier; see . When the
idrsakem 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 idrsakem object identifier.
When the AlgorithmIdentifier parameters are present, the
GenericHybridParameters MUST be used. As described in the next
section, 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
filed 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 idrsakem object identifier as discussed above,
then the key usage extension MUST contain the following value:
The digitalSignatrure and dataEncipherment values SHOULD NOT be
present. That is, a public key intended to be employed only with the
RSAKEM Algorithm SHOULD 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 signed
attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) 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 signed
attribute announcing that it supports the RSAKEM Algorithm.
The SMIMECapability SEQUENCE representing the RSAKEM Algorithm MUST
include the idrsakem object identifier in the capabilityID field;
see for the object identifier value, and see
for examples. When the idrsakem 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;
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. 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.

dem is an AlgorithmIdentifier; the algorithm field MUST be present, and it
identifies the keyencryption algorithm; parameters are optional. If the
GenericHybridParameters are present, then the provided dem value MUST be
used in the wrap field of KEMRecipientInfo.
Security Considerations
The RSAKEM Algorithm should be considered as a replacement for 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.
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 .
To achieve 128bit security, the RSA key size SHOULD be at least 3072 bits,
the keyderivation function SHOULD make use of SHA256, and the symmetric
keyencryption algorithm SHOULD be AES Key Wrap with a 128bit key.
Implementations MUST protect the RSA private key, the keyencryption key,
the contentencryption key, the contentauthenticatedencryption key.
Compromise of the RSA private key could result in the disclosure of all
messages protected with that key. Compromise of the keyencryption key,
the contentencryption key, or contentauthenticatedencryption key could
result in disclosure of the associated encrypted content.
Additional considerations related to key management may be found in
.
The security of the RSAKEM Algorithm also depends on the strength of the
random number generator, which SHOULD have a comparable security level. For
further discussion on random number generation, see .
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. While RSA public keys have
often been employed for multiple purposes such as key transport and
digital signature without any known bad interactions, for increased
security assurance, 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.
Parties MAY 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".
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 CMS content.
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.
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
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
Advanced Encryption Standard (AES) Key Wrap Algorithm
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.
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.
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.
Recommendation for key management:
National Institute of Standards and Technology
Public Key Cryptography for the Financial Services Industry  Key Establishment Using Integer Factorization Cryptography
American National Standards Institute
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 this type of algorithm, an originator encrypts the keying material
using the recipient's public key, and then sends the resulting encrypted
keying material to the recipient. The recipient decrypts the encrypted
keying material using the recipient's private key to recover the keying
material.
Underlying Components
The RSAKEM Algorithm has the following underlying components:
 KDF, a keyderivation function, which derives keyencryption key of a
specified length from a shared secret value;
 Wrap, a symmetric keyencryption algorithm, which encrypts keying material
using keyencryption key that was produced by the KDF.
The kekLen value denotes the length in bytes of the keyencryption key
for the underlying symmetric keyencryption algorithm.
The length of the keying material MUST be among the lengths supported by
the underlying symmetric keyencryption algorithm. For example, the
AESWrap keyencryption algorithm requires the kekLen to be 16, 24,
or 32 octets. Usage and formatting of the keying material is outside
the scope of the RSAKEM Algorithm.
Many keyderivation functions support the inclusion of other information
in addition to the shared secret value in the input to the function.
Also, with some symmetric keyencryption algorithms, it is possible to
associate a label with the keying material. Such uses are outside the scope
of this document, as they are not directly supported by CMS.
Originator's Operations
Let (n,e) be the recipient's RSA public key; see for details.
Let K be the keying material to be securely transferred from the originator
to the recipient.
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 keyencryption key KEK of length kekLen bytes
from the byte string Z using the underlying keyderivation function:

Wrap the keying material K with the symmetric keyencryption key
KEK using the keyencryption algorithm to obtain wrapped keying
material WK:
 Send the ciphertext C and the wrapped keying material WK 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
Let (n,d) be the recipient's RSA private key; see for details,
but other private key formats are allowed.
Let WK be the encrypted keying material.
Let C be the ciphertext.
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 C to an integer c, most significant byte
first. Decrypt the integer c using the recipient's private key
(n,d) to recover an integer z (see NOTE below):
If the integer c is not between 0 and n1, output "decryption
error", and stop.

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

Derive a symmetric keyencryption key KEK of length kekLen bytes from
the byte string Z using the keyderivation function (see NOTE below):

Unwrap the wrapped keying material WK with the symmetric
keyencryption key KEK using the underlying keyencryption
algorithm to recover the keying material K:
If the unwrapping operation outputs an error, output "decryption
error", and stop.
 Output the keying material K.
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 idrsakem
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 .
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;
 key derivation using KDF2 with SHA256; and
 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 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 c:
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 integer z and the
CMSORIforKEMOtherInfo structure with KDF2 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:
ContentInfo and EnvelopedData
Alice encodes the EnvelopedData (using KEMRecipientInfo) and
ContentInfo, and then sends the result to Bob. The Base64encoded:
result is:
This result decodes to:
ß## Recipient Processing
Bob's private key:
Bob decrypts the integer z with his RSA private key:
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 integer z and the
CMSORIforKEMOtherInfo structure with KDF2 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 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.