rfc9690v1.txt   rfc9690.txt 
skipping to change at line 12 skipping to change at line 12
Internet Engineering Task Force (IETF) R. Housley Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 9690 Vigil Security Request for Comments: 9690 Vigil Security
Obsoletes: 5990 S. Turner Obsoletes: 5990 S. Turner
Category: Standards Track sn3rd Category: Standards Track sn3rd
ISSN: 2070-1721 January 2025 ISSN: 2070-1721 January 2025
Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS) Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS)
Abstract Abstract
The RSA Key Encapsulation Mechanism (RSA-KEM) Algorithm is a one-pass The RSA Key Encapsulation Mechanism (RSA-KEM) algorithm is a one-pass
(store-and-forward) cryptographic mechanism for an originator to (store-and-forward) cryptographic mechanism for an originator to
securely send keying material to a recipient using the recipient's securely send keying material to a recipient using the recipient's
RSA public key. The RSA-KEM Algorithm is specified in Clause 11.5 of RSA public key. The RSA-KEM algorithm is specified in Clause 11.5 of
ISO/IEC: 18033-2:2006. This document specifies the conventions for ISO/IEC: 18033-2:2006. This document specifies the conventions for
using the RSA-KEM Algorithm as a standalone KEM algorithm and the using the RSA-KEM algorithm as a standalone KEM algorithm and the
conventions for using the RSA-KEM Algorithm with the Cryptographic conventions for using the RSA-KEM algorithm with the Cryptographic
Message Syntax (CMS) using KEMRecipientInfo as specified in RFC 9629. Message Syntax (CMS) using KEMRecipientInfo as specified in RFC 9629.
This document obsoletes RFC 5990. This document obsoletes RFC 5990.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
skipping to change at line 87 skipping to change at line 87
Appendix D. RSA-KEM CMS Enveloped-Data Example Appendix D. RSA-KEM CMS Enveloped-Data Example
D.1. Originator RSA-KEM Encapsulate() Processing D.1. Originator RSA-KEM Encapsulate() Processing
D.2. Originator CMS Processing D.2. Originator CMS Processing
D.3. Recipient RSA-KEM Decapsulate() Processing D.3. Recipient RSA-KEM Decapsulate() Processing
D.4. Recipient CMS Processing D.4. Recipient CMS Processing
Acknowledgements Acknowledgements
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
The RSA Key Encapsulation Mechanism (RSA-KEM) Algorithm is a one-pass The RSA Key Encapsulation Mechanism (RSA-KEM) algorithm is a one-pass
(store-and-forward) cryptographic mechanism for an originator to (store-and-forward) cryptographic mechanism for an originator to
securely send keying material to a recipient using the recipient's securely send keying material to a recipient using the recipient's
RSA public key. The RSA-KEM Algorithm is specified in Clause 11.5 of RSA public key. The RSA-KEM algorithm is specified in Clause 11.5 of
[ISO18033-2]. [ISO18033-2].
The RSA-KEM Algorithm takes a different approach than other RSA key The RSA-KEM algorithm takes a different approach than other RSA key
transport mechanisms [RFC8017] with the goal of providing higher transport mechanisms [RFC8017] with the goal of providing higher
security assurance while also satisfying the KEM interface. The RSA- security assurance while also satisfying the KEM interface. The RSA-
KEM Algorithm encrypts a random integer with the recipient's RSA KEM algorithm encrypts a random integer with the recipient's RSA
public key and derives a shared secret from the random integer. The public key and derives a shared secret from the random integer. The
originator and recipient can derive a symmetric key from the shared originator and recipient can derive a symmetric key from the shared
secret. For example, a key-encryption key (KEK) can be derived from secret. For example, a key-encryption key (KEK) can be derived from
the shared secret to wrap a content-encryption key (CEK). the shared secret to wrap a content-encryption key (CEK).
In the Cryptographic Message Syntax (CMS) [RFC5652] using In the Cryptographic Message Syntax (CMS) [RFC5652] using
KEMRecipientInfo [RFC9629], the shared-secret value is input to a KEMRecipientInfo [RFC9629], the shared-secret value is input to a key
key-derivation function (KDF) to compute a key-encryption key and derivation function (KDF) to compute a key-encryption key and wrap a
wrap a symmetric content-encryption key with the key-encryption key. symmetric content-encryption key with the key-encryption key. In
In this way, the originator and the recipient end up with the same this way, the originator and the recipient end up with the same
content-encryption key. content-encryption key.
For completeness, a specification of the RSA-KEM Algorithm is given For completeness, a specification of the RSA-KEM algorithm is given
in Appendix A of this document. ASN.1 syntax is given in Appendix B. in Appendix A of this document. ASN.1 syntax is given in Appendix B.
1.1. RSA-KEM Algorithm Rationale 1.1. RSA-KEM Algorithm Rationale
The RSA-KEM Algorithm provides higher security assurance than other The RSA-KEM algorithm provides higher security assurance than other
variants of the RSA cryptosystem for two reasons. First, the input variants of the RSA cryptosystem for two reasons. First, the input
to the underlying RSA operation is a string-encoded random integer to the underlying RSA operation is a string-encoded random integer
between 0 and n-1, where n is the RSA modulus, so it does not have between 0 and n-1, where n is the RSA modulus, so it does not have
any structure that could be exploited by an adversary. Second, the any structure that could be exploited by an adversary. Second, the
input is independent of the keying material, so the result of the RSA input is independent of the keying material, so the result of the RSA
decryption operation is not directly available to an adversary. As a decryption operation is not directly available to an adversary. As a
result, the RSA-KEM Algorithm enjoys a "tight" security proof in the result, the RSA-KEM algorithm enjoys a "tight" security proof in the
random oracle model. (In other padding schemes, such as PKCS #1 v1.5 random oracle model. (In other padding schemes, such as PKCS #1 v1.5
[RFC8017], the input has structure and/or depends on the keying [RFC8017], the input has structure and depends on the keying
material, and the provable security assurances are not as strong.) material. Additionally, the provable security assurances are not as
strong.)
The approach is also architecturally convenient because the public- The approach is also architecturally convenient because the public-
key operations are separate from the symmetric operations on the key operations are separate from the symmetric operations on the
keying material. Another benefit is that the length of the keying keying material. Another benefit is that the length of the keying
material is determined by the symmetric algorithms, not the size of material is determined by the symmetric algorithms, not the size of
the RSA modulus. the RSA modulus.
1.2. RSA-KEM Algorithm Summary 1.2. RSA-KEM Algorithm Summary
All KEM algorithms provide three functions: KeyGen(), Encapsulate(), All KEM algorithms provide three functions: KeyGen(), Encapsulate(),
skipping to change at line 184 skipping to change at line 185
SS = KDF(Z, ssLen) SS = KDF(Z, ssLen)
3. The shared secret is returned by the function. 3. The shared secret is returned by the function.
1.3. CMS KEMRecipientInfo Processing Summary 1.3. CMS KEMRecipientInfo Processing Summary
To support the RSA-KEM algorithm, the CMS originator MUST implement To support the RSA-KEM algorithm, the CMS originator MUST implement
Encapsulate(). Encapsulate().
Given a content-encryption key CEK, the RSA-KEM Algorithm processing Given a content-encryption key CEK, the RSA-KEM algorithm processing
by the originator to produce the values that are carried in the CMS by the originator to produce the values that are carried in the CMS
KEMRecipientInfo can be summarized as follows: KEMRecipientInfo can be summarized as follows:
1. Obtain the shared secret using the Encapsulate() function of the 1. Obtain the shared secret using the Encapsulate() function of the
RSA-KEM algorithm and the recipient's RSA public key: RSA-KEM algorithm and the recipient's RSA public key:
(ct, SS) = Encapsulate(pk) (ct, SS) = Encapsulate(pk)
2. Derive a key-encryption key KEK from the shared secret: 2. Derive a key-encryption key KEK from the shared secret:
skipping to change at line 245 skipping to change at line 246
1.5. ASN.1 1.5. ASN.1
CMS values are generated using ASN.1 [X.680], which uses the Basic CMS values are generated using ASN.1 [X.680], which uses the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
[X.690]. [X.690].
1.6. Changes Since RFC 5990 1.6. Changes Since RFC 5990
RFC 5990 [RFC5990] specified the conventions for using the RSA-KEM RFC 5990 [RFC5990] specified the conventions for using the RSA-KEM
Algorithm in CMS as a key transport algorithm. That is, it used algorithm in CMS as a key transport algorithm. That is, it used
KeyTransRecipientInfo [RFC5652] for each recipient. Since the KeyTransRecipientInfo [RFC5652] for each recipient. Since the
publication of RFC 5990, a new KEMRecipientInfo structure [RFC9629] publication of RFC 5990, a new KEMRecipientInfo structure [RFC9629]
has been defined to support KEM algorithms. When the id-rsa-kem has been defined to support KEM algorithms. When the id-rsa-kem
algorithm identifier appears in the SubjectPublicKeyInfo field of a algorithm identifier appears in the SubjectPublicKeyInfo field of a
certificate, the complex parameter structure defined in RFC 5990 can certificate, the complex parameter structure defined in RFC 5990 can
be omitted; however, the parameters are allowed for backward be omitted; however, the parameters are allowed for backward
compatibility. Also, to avoid visual confusion with id-kem-rsa, id- compatibility. Also, to avoid visual confusion with id-kem-rsa, id-
rsa-kem-spki is introduced as an alias for id-rsa-kem. rsa-kem-spki is introduced as an alias for id-rsa-kem.
RFC 5990 used EK as the EncryptedKey, which is the concatenation of RFC 5990 used EK as the EncryptedKey, which is the concatenation of
skipping to change at line 273 skipping to change at line 274
RFC 5990 included support for Camellia and Triple-DES block ciphers; RFC 5990 included support for Camellia and Triple-DES block ciphers;
discussion of these block ciphers does not appear in this document, discussion of these block ciphers does not appear in this document,
but the algorithm identifiers remain in the ASN.1 module (see but the algorithm identifiers remain in the ASN.1 module (see
Appendix B.2). Appendix B.2).
RFC 5990 included support for SHA-1 hash function; discussion of this RFC 5990 included support for SHA-1 hash function; discussion of this
hash function does not appear this document, but the algorithm hash function does not appear this document, but the algorithm
identifier remains in the ASN.1 module (see Appendix B.2). identifier remains in the ASN.1 module (see Appendix B.2).
RFC 5990 required support for the KDF3 key-derivation function RFC 5990 required support for the KDF3 key derivation function
[ANS-X9.44]; this document continues to require support for the KDF3 [ANS-X9.44]; this document continues to require support for the KDF3
key-derivation function, but it requires support for SHA-256 [SHS] as key derivation function, but it requires support for SHA-256 [SHS] as
the hash function. the hash function.
RFC 5990 recommended support for alternatives to KDF3 and AES-Wrap- RFC 5990 recommended support for alternatives to KDF3 and AES-Wrap-
128; this document simply states that other key-derivation functions 128; this document simply states that other key derivation functions
and other key-encryption algorithms MAY be supported. and other key-encryption algorithms MAY be supported.
RFC 5990 supported the future definition of additional KEM algorithms RFC 5990 supported the future definition of additional KEM algorithms
that use RSA; this document supports only one, and it is identified that use RSA; this document supports only one, and it is identified
by the id-kem-rsa object identifier. by the id-kem-rsa object identifier.
RFC 5990 included an ASN.1 module; this document provides an RFC 5990 included an ASN.1 module; this document provides an
alternative ASN.1 module that follows the conventions established in alternative ASN.1 module that follows the conventions established in
[RFC5911], [RFC5912], and [RFC6268]. The new ASN.1 module [RFC5911], [RFC5912], and [RFC6268]. The new ASN.1 module
(Appendix B.2) produces the same bits-on-the-wire as the one in RFC (Appendix B.2) produces the same bits-on-the-wire as the one in RFC
5990. 5990.
2. Use of the RSA-KEM Algorithm in CMS 2. Use of the RSA-KEM Algorithm in CMS
The RSA-KEM Algorithm MAY be employed for one or more recipients in The RSA-KEM algorithm MAY be employed for one or more recipients in
the CMS enveloped-data content type [RFC5652], the CMS authenticated- the CMS enveloped-data content type [RFC5652], the CMS authenticated-
data content type [RFC5652], or the CMS authenticated-enveloped-data data content type [RFC5652], or the CMS authenticated-enveloped-data
content type [RFC5083]. In each case, the KEMRecipientInfo [RFC9629] content type [RFC5083]. In each case, the KEMRecipientInfo [RFC9629]
is used with the RSA-KEM Algorithm to securely transfer the content- is used with the RSA-KEM algorithm to securely transfer the content-
encryption key from the originator to the recipient. encryption key from the originator to the recipient.
2.1. Mandatory To Implement 2.1. Mandatory To Implement
A CMS implementation that supports the RSA-KEM Algorithm MUST support A CMS implementation that supports the RSA-KEM algorithm MUST support
at least the following underlying components: at least the following underlying components:
* For the key-derivation function, an implementation MUST support * For the key derivation function, an implementation MUST support
KDF3 [ANS-X9.44] with SHA-256 [SHS]. KDF3 [ANS-X9.44] with SHA-256 [SHS].
* For key-wrapping, an implementation MUST support the AES-Wrap-128 * For key-wrapping, an implementation MUST support the AES-Wrap-128
[RFC3394] key-encryption algorithm. [RFC3394] key-encryption algorithm.
An implementation MAY also support other key-derivation functions and An implementation MAY also support other key derivation functions and
other key-encryption algorithms. other key-encryption algorithms.
2.2. RecipientInfo Conventions 2.2. RecipientInfo Conventions
When the RSA-KEM Algorithm is employed for a recipient, the When the RSA-KEM algorithm is employed for a recipient, the
RecipientInfo alternative for that recipient MUST be RecipientInfo alternative for that recipient MUST be
OtherRecipientInfo using the KEMRecipientInfo structure [RFC9629]. OtherRecipientInfo using the KEMRecipientInfo structure [RFC9629].
The fields of the KEMRecipientInfo MUST have the following values: The fields of the KEMRecipientInfo MUST have the following values:
* version is the syntax version number; it MUST be 0. * version is the syntax version number; it MUST be 0.
* rid identifies the recipient's certificate or public key. * rid identifies the recipient's certificate or public key.
* kem identifies the KEM algorithm; it MUST contain id-kem-rsa. * kem identifies the KEM algorithm; it MUST contain id-kem-rsa.
* kemct is the ciphertext produced for this recipient; it contains C * kemct is the ciphertext produced for this recipient; it contains C
from steps 1 and 2 of Originator's Operations in Appendix A. from steps 1 and 2 of Originator's Operations in Appendix A.
* kdf identifies the key-derivation function (KDF). Note that the * kdf identifies the key derivation function (KDF). Note that the
KDF used for CMS RecipientInfo process MAY be different than the KDF used for CMS RecipientInfo process MAY be different than the
KDF used within the RSA-KEM Algorithm. KDF used within the RSA-KEM algorithm.
* kekLength is the size of the key-encryption key in octets. * kekLength is the size of the key-encryption key in octets.
* ukm is an optional random input to the key-derivation function. * ukm is an optional random input to the key derivation function.
* wrap identifies a key-encryption algorithm used to encrypt the * wrap identifies a key-encryption algorithm used to encrypt the
keying material. keying material.
* encryptedKey is the result of encrypting the keying material with * encryptedKey is the result of encrypting the keying material with
the key-encryption key. When used with the CMS enveloped-data the key-encryption key. When used with the CMS enveloped-data
content type [RFC5652], the keying material is a content- content type [RFC5652], the keying material is a content-
encryption key. When used with the CMS authenticated-data content encryption key. When used with the CMS authenticated-data content
type [RFC5652], the keying material is a message-authentication type [RFC5652], the keying material is a message-authentication
key. When used with the CMS authenticated-enveloped-data content key. When used with the CMS authenticated-enveloped-data content
type [RFC5083], the keying material is a content-authenticated- type [RFC5083], the keying material is a content-authenticated-
encryption key (CAEK). encryption key (CAEK).
NOTE: For backward compatibility, implementations MAY also support NOTE: For backward compatibility, implementations MAY also support
the RSA-KEM Key Transport Algorithm, identified by id-rsa-kem-spki, the RSA-KEM Key Transport algorithm, identified by id-rsa-kem-spki,
which uses KeyTransRecipientInfo as specified in [RFC5990]. which uses KeyTransRecipientInfo as specified in [RFC5990].
2.3. Certificate Conventions 2.3. Certificate Conventions
The conventions specified in this section augment RFC 5280 [RFC5280]. The conventions specified in this section augment RFC 5280 [RFC5280].
A recipient who employs the RSA-KEM Algorithm MAY identify the public A recipient who employs the RSA-KEM algorithm MAY identify the public
key in a certificate by the same AlgorithmIdentifier as for the PKCS key in a certificate by the same AlgorithmIdentifier as for the PKCS
#1 v1.5 algorithm, that is, using the rsaEncryption object identifier #1 v1.5 algorithm, that is, using the rsaEncryption object identifier
[RFC8017]. The fact that the recipient will accept RSA-KEM with this [RFC8017]. The fact that the recipient will accept RSA-KEM with this
public key is not indicated by the use of this object identifier. public key is not indicated by the use of this object identifier.
The willingness to accept the RSA-KEM Algorithm MAY be signaled by The willingness to accept the RSA-KEM algorithm MAY be signaled by
the use of the SMIMECapabilities Attribute as specified in the use of the SMIMECapabilities Attribute as specified in
Section 2.5.2 of [RFC8551] or the SMIMECapabilities certificate Section 2.5.2 of [RFC8551] or the SMIMECapabilities certificate
extension as specified in [RFC4262]. extension as specified in [RFC4262].
If the recipient wishes only to employ the RSA-KEM Algorithm with a If the recipient wishes only to employ the RSA-KEM algorithm with a
given public key, the recipient MUST identify the public key in the given public key, the recipient MUST identify the public key in the
certificate using the id-rsa-kem-spki object identifier; see certificate using the id-rsa-kem-spki object identifier; see
Appendix B. The use of the id-rsa-kem-spki object identifier allows Appendix B. The use of the id-rsa-kem-spki object identifier allows
certificates that were issued to be compatible with RSA-KEM Key certificates that were issued to be compatible with RSA-KEM Key
Transport to also be used with this specification. When the id-rsa- Transport to also be used with this specification. When the id-rsa-
kem-spki object identifier appears in the SubjectPublicKeyInfo kem-spki object identifier appears in the SubjectPublicKeyInfo
algorithm field of the certificate, the parameters field from algorithm field of the certificate, the parameters field from
AlgorithmIdentifier SHOULD be absent. That is, the AlgorithmIdentifier SHOULD be absent. That is, the
AlgorithmIdentifier SHOULD be a SEQUENCE of one component, the id- AlgorithmIdentifier SHOULD be a SEQUENCE of one component, the id-
rsa-kem-spki object identifier. With absent parameters, the KDF3 rsa-kem-spki object identifier. With absent parameters, the KDF3 key
key-derivation function [ANS-X9.44] with SHA-256 [SHS] are used to derivation function [ANS-X9.44] with SHA-256 [SHS] are used to derive
derive the shared secret. the shared secret.
When the AlgorithmIdentifier parameters are present, the When the AlgorithmIdentifier parameters are present, the
GenericHybridParameters MUST be used. Within the kem element, the GenericHybridParameters MUST be used. Within the kem element, the
algorithm identifier MUST be set to id-kem-rsa, and RsaKemParameters algorithm identifier MUST be set to id-kem-rsa, and RsaKemParameters
MUST be included. As described in Section 2.4, the MUST be included. As described in Section 2.4, the
GenericHybridParameters constrain the values that can be used with GenericHybridParameters constrain the values that can be used with
the RSA public key for the kdf, kekLength, and wrap fields of the the RSA public key for the kdf, kekLength, and wrap fields of the
KEMRecipientInfo structure. KEMRecipientInfo structure.
Regardless of the AlgorithmIdentifier used, the RSA public key MUST Regardless of the AlgorithmIdentifier used, the RSA public key MUST
skipping to change at line 406 skipping to change at line 407
The intended application for the public key MAY be indicated in the The intended application for the public key MAY be indicated in the
key usage certificate extension as specified in Section 4.2.1.3 of key usage certificate extension as specified in Section 4.2.1.3 of
[RFC5280]. If the keyUsage extension is present in a certificate [RFC5280]. If the keyUsage extension is present in a certificate
that conveys an RSA public key with the id-rsa-kem-spki object that conveys an RSA public key with the id-rsa-kem-spki object
identifier as discussed above, then the key usage extension MUST identifier as discussed above, then the key usage extension MUST
contain only the following value: contain only the following value:
keyEncipherment keyEncipherment
Other keyUsage extension values MUST NOT be present. That is, a Other keyUsage extension values MUST NOT be present. That is, a
public key intended to be employed only with the RSA-KEM Algorithm public key intended to be employed only with the RSA-KEM algorithm
MUST NOT also be employed for data encryption or for digital MUST NOT also be employed for data encryption or for digital
signatures. Good cryptographic practice employs a given RSA key pair signatures. Good cryptographic practice employs a given RSA key pair
in only one scheme. This practice avoids the risk that vulnerability in only one scheme. This practice avoids the risk that vulnerability
in one scheme may compromise the security of the other and may be in one scheme may compromise the security of the other and may be
essential to maintain provable security. essential to maintain provable security.
2.4. SMIMECapabilities Attribute Conventions 2.4. SMIMECapabilities Attribute Conventions
Section 2.5.2 of [RFC8551] defines the SMIMECapabilities attribute to Section 2.5.2 of [RFC8551] defines the SMIMECapabilities attribute to
announce a partial list of algorithms that an S/MIME implementation announce a partial list of algorithms that an S/MIME implementation
can support. When constructing a CMS signed-data content type can support. When constructing a CMS signed-data content type
[RFC5652], a compliant implementation MAY include the [RFC5652], a compliant implementation MAY include the
SMIMECapabilities attribute that announces support for the RSA-KEM SMIMECapabilities attribute that announces support for the RSA-KEM
Algorithm. algorithm.
The SMIMECapability SEQUENCE representing the RSA-KEM Algorithm MUST The SMIMECapability SEQUENCE representing the RSA-KEM algorithm MUST
include the id-rsa-kem-spki object identifier in the capabilityID include the id-rsa-kem-spki object identifier in the capabilityID
field; see Appendix B for the object identifier value and Appendix C field; see Appendix B for the object identifier value and Appendix C
for examples. When the id-rsa-kem-spki object identifier appears in for examples. When the id-rsa-kem-spki object identifier appears in
the capabilityID field and the parameters are present, then the the capabilityID field and the parameters are present, then the
parameters field MUST use the GenericHybridParameters type. parameters field MUST use the GenericHybridParameters type.
GenericHybridParameters ::= SEQUENCE { GenericHybridParameters ::= SEQUENCE {
kem KeyEncapsulationMechanism, kem KeyEncapsulationMechanism,
dem DataEncapsulationMechanism } dem DataEncapsulationMechanism }
The fields of the GenericHybridParameters type have the following The fields of the GenericHybridParameters type have the following
meanings: meanings:
* kem is an AlgorithmIdentifer. The algorithm field MUST be set to * kem is an AlgorithmIdentifer. The algorithm field MUST be set to
id-kem-rsa, and the parameters field MUST be RsaKemParameters, id-kem-rsa, and the parameters field MUST be RsaKemParameters,
which is a SEQUENCE of an AlgorithmIdentifier that identifies the which is a SEQUENCE of an AlgorithmIdentifier that identifies the
supported key-derivation function and a positive INTEGER that supported key derivation function and a positive INTEGER that
identifies the length of the key-encryption key in octets. identifies the length of the key-encryption key in octets.
* dem is an AlgorithmIdentifier. The algorithm field MUST be * dem is an AlgorithmIdentifier. The algorithm field MUST be
present, and it identifies the key-encryption algorithm. The present, and it identifies the key-encryption algorithm. The
parameters are optional. If the GenericHybridParameters are parameters are optional. If the GenericHybridParameters are
present, then the provided dem value MUST be used in the wrap present, then the provided dem value MUST be used in the wrap
field of KEMRecipientInfo. field of KEMRecipientInfo.
If the GenericHybridParameters are present, then the provided kem If the GenericHybridParameters are present, then the provided kem
value MUST be used as the key-derivation function in the kdf field of value MUST be used as the key derivation function in the kdf field of
KEMRecipientInfo and the provided key length MUST be used in the KEMRecipientInfo and the provided key length MUST be used in the
kekLength of KEMRecipientInfo. kekLength of KEMRecipientInfo.
3. Security Considerations 3. Security Considerations
The RSA-KEM Algorithm should be considered as a replacement for the The RSA-KEM algorithm should be considered as a replacement for the
key transport portion of the widely implemented PKCS #1 v1.5 key transport portion of the widely implemented PKCS #1 v1.5
[RFC8017] for new applications that use CMS to avoid potential [RFC8017] for new applications that use CMS to avoid potential
vulnerabilities to chosen-ciphertext attacks and gain a tighter vulnerabilities to chosen-ciphertext attacks and gain a tighter
security proof. However, the RSA-KEM Algorithm has the disadvantage security proof. However, the RSA-KEM algorithm has the disadvantage
of slightly longer encrypted keying material. With PKCS #1 v1.5, the of slightly longer encrypted keying material. With PKCS #1 v1.5, the
originator encrypts the key-encryption key directly with the originator encrypts the key-encryption key directly with the
recipient's RSA public key. With the RSA-KEM, the key-encryption key recipient's RSA public key. With the RSA-KEM, the key-encryption key
is encrypted separately. is encrypted separately.
The security of the RSA-KEM Algorithm can be shown to be tightly The security of the RSA-KEM algorithm can be shown to be tightly
related to the difficulty of either solving the RSA problem or related to the difficulty of either solving the RSA problem or
breaking the underlying symmetric key-encryption algorithm if the breaking the underlying symmetric key-encryption algorithm if the
underlying key-derivation function is modeled as a random oracle, underlying key derivation function is modeled as a random oracle,
assuming that the symmetric key-encryption algorithm satisfies the assuming that the symmetric key-encryption algorithm satisfies the
properties of a data encapsulation mechanism [SHOUP]. While in properties of a data encapsulation mechanism [SHOUP]. While in
practice a random-oracle result does not provide an actual security practice a random-oracle result does not provide an actual security
proof for any particular key-derivation function, the result does proof for any particular key derivation function, the result does
provide assurance that the general construction is reasonable; a key- provide assurance that the general construction is reasonable; a key
derivation function would need to be particularly weak to lead to an derivation function would need to be particularly weak to lead to an
attack that is not possible in the random-oracle model. attack that is not possible in the random-oracle model.
The RSA key size and the underlying components need to be selected The RSA key size and the underlying components need to be selected
consistent with the desired security level. Several security levels consistent with the desired security level. Several security levels
have been identified in the NIST SP 800-57 Part 1 have been identified in the NIST SP 800-57 Part 1
[NISTSP800-57pt1r5]. For example, one way to achieve 128-bit [NISTSP800-57pt1r5]. For example, one way to achieve 128-bit
security, the RSA key size would be at least 3072 bits, the key- security, the RSA key size would be at least 3072 bits, the key
derivation function would be SHA-256, and the symmetric key- derivation function would be SHA-256, and the symmetric key-
encryption algorithm would be AES Key Wrap with a 128-bit key. encryption algorithm would be AES Key Wrap with a 128-bit key.
Implementations MUST protect the RSA private key, the key-encryption Implementations MUST protect the RSA private key, the key-encryption
key, the content-encryption key, message-authentication key, and the key, the content-encryption key, message-authentication key, and the
content-authenticated-encryption key. Disclosure of the RSA private content-authenticated-encryption key. Disclosure of the RSA private
key could result in the compromise of all messages protected with key could result in the compromise of all messages protected with
that key. Disclosure of the key-encryption key, the content- that key. Disclosure of the key-encryption key, the content-
encryption key, or the content-authenticated-encryption key could encryption key, or the content-authenticated-encryption key could
result in compromise of the associated encrypted content. Disclosure result in compromise of the associated encrypted content. Disclosure
of the key-encryption key, the message-authentication key, or the of the key-encryption key, the message-authentication key, or the
content-authenticated-encryption key could allow modification of the content-authenticated-encryption key could allow modification of the
associated authenticated content. associated authenticated content.
Additional considerations related to key management may be found in Additional considerations related to key management may be found in
[NISTSP800-57pt1r5]. [NISTSP800-57pt1r5].
The security of the RSA-KEM Algorithm depends on a quality random The security of the RSA-KEM algorithm depends on a quality random
number generator. For further discussion on random number number generator. For further discussion on random number
generation, see [RFC4086]. generation, see [RFC4086].
The RSA-KEM Algorithm does not use an explicit padding scheme. The RSA-KEM algorithm does not use an explicit padding scheme.
Instead, an encoded random value (z) between zero and the RSA modulus Instead, an encoded random value (z) between zero and the RSA modulus
minus one (n-1) is directly encrypted with the recipient's RSA public minus one (n-1) is directly encrypted with the recipient's RSA public
key. The IntegerToString(z, nLen) encoding produces a string that is key. The IntegerToString(z, nLen) encoding produces a string that is
the full length of the RSA modulus. In addition, the random value is the full length of the RSA modulus. In addition, the random value is
passed through a KDF to reduce possible harm from a poorly passed through a KDF to reduce possible harm from a poorly
implemented random number source or a maliciously chosen random value implemented random number source or a maliciously chosen random value
(z). Implementations MUST NOT use z directly for any purpose. (z). Implementations MUST NOT use z directly for any purpose.
As long as a fresh random integer z is chosen as part of each As long as a fresh random integer z is chosen as part of each
invocation of the Encapsulate() function, RSA-KEM does not degrade as invocation of the Encapsulate() function, RSA-KEM does not degrade as
the number of ciphertexts increases. Since RSA encryption provides a the number of ciphertexts increases. Since RSA encryption provides a
bijective map, a collision in the KDF is the only way that RSA-KEM bijective map, a collision in the KDF is the only way that RSA-KEM
can produce more than one ciphertext that encapsulates the same can produce more than one ciphertext that encapsulates the same
shared secret. shared secret.
The RSA-KEM Algorithm provides a fixed-length ciphertext. The The RSA-KEM algorithm provides a fixed-length ciphertext. The
recipient MUST check that the received byte string is the expected recipient MUST check that the received byte string is the expected
length and the length corresponds to an integer in the expected range length and the length corresponds to an integer in the expected range
prior to attempting decryption with their RSA private key as prior to attempting decryption with their RSA private key as
described in Steps 1 and 2 of Appendix A.2. described in Steps 1 and 2 of Appendix A.2.
Implementations SHOULD NOT reveal information about intermediate Implementations SHOULD NOT reveal information about intermediate
values or calculations, whether by timing or other "side channels"; values or calculations, whether by timing or other "side channels";
otherwise, an opponent may be able to determine information about the otherwise, an opponent may be able to determine information about the
keying data and/or the recipient's private key. Although not all keying data and/or the recipient's private key. Although not all
intermediate information may be useful to an opponent, it is intermediate information may be useful to an opponent, it is
skipping to change at line 543 skipping to change at line 544
Generally, good cryptographic practice employs a given RSA key pair Generally, good cryptographic practice employs a given RSA key pair
in only one scheme. This practice avoids the risk that vulnerability in only one scheme. This practice avoids the risk that vulnerability
in one scheme may compromise the security of the other, and may be in one scheme may compromise the security of the other, and may be
essential to maintain provable security. RSA public keys have often essential to maintain provable security. RSA public keys have often
been employed for multiple purposes such as key transport and digital been employed for multiple purposes such as key transport and digital
signature without any known bad interactions; however, such combined signature without any known bad interactions; however, such combined
use of an RSA key pair is NOT RECOMMENDED in the future (unless the use of an RSA key pair is NOT RECOMMENDED in the future (unless the
different schemes are specifically designed to be used together). different schemes are specifically designed to be used together).
Accordingly, an RSA key pair used for the RSA-KEM Algorithm SHOULD Accordingly, an RSA key pair used for the RSA-KEM algorithm SHOULD
NOT also be used for digital signatures. Indeed, the Accredited NOT also be used for digital signatures. Indeed, the Accredited
Standards Committee X9 (ASC X9) requires such a separation between Standards Committee X9 (ASC X9) requires such a separation between
key pairs used for key establishment and key pairs used for digital key pairs used for key establishment and key pairs used for digital
signature [ANS-X9.44]. Continuing this principle of key separation, signature [ANS-X9.44]. Continuing this principle of key separation,
a key pair used for the RSA-KEM Algorithm SHOULD NOT be used with a key pair used for the RSA-KEM algorithm SHOULD NOT be used with
other key establishment schemes, or for data encryption, or with more other key establishment schemes, or for data encryption, or with more
than one set of underlying algorithm components. than one set of underlying algorithm components.
It is acceptable to use the same RSA key pair for RSA-KEM Key It is acceptable to use the same RSA key pair for RSA-KEM Key
Transport as specified in [RFC5990] and this specification. This is Transport as specified in [RFC5990] and this specification. This is
acceptable because the operations involving the RSA public key and acceptable because the operations involving the RSA public key and
the RSA private key are identical in the two specifications. the RSA private key are identical in the two specifications.
Parties can gain assurance that implementations are correct through Parties can gain assurance that implementations are correct through
formal implementation validation, such as the NIST Cryptographic formal implementation validation, such as the NIST Cryptographic
skipping to change at line 710 skipping to change at line 711
Considerations for the SHA-0 and SHA-1 Message-Digest Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>. <https://www.rfc-editor.org/info/rfc6194>.
[SHOUP] Shoup, V., "A Proposal for an ISO Standard for Public Key [SHOUP] Shoup, V., "A Proposal for an ISO Standard for Public Key
Encryption", Cryptology ePrint Archive Paper 2001/112, Encryption", Cryptology ePrint Archive Paper 2001/112,
2001, <https://eprint.iacr.org/2001/112>. 2001, <https://eprint.iacr.org/2001/112>.
Appendix A. RSA-KEM Algorithm Appendix A. RSA-KEM Algorithm
The RSA-KEM Algorithm is a one-pass (store-and-forward) cryptographic The RSA-KEM algorithm is a one-pass (store-and-forward) cryptographic
mechanism for an originator to securely send keying material to a mechanism for an originator to securely send keying material to a
recipient using the recipient's RSA public key. recipient using the recipient's RSA public key.
With the RSA-KEM Algorithm, an originator encrypts a random integer With the RSA-KEM algorithm, an originator encrypts a random integer
(z) with the recipient's RSA public key to produce a ciphertext (ct), (z) with the recipient's RSA public key to produce a ciphertext (ct),
and the originator derives a shared secret (SS) from the random and the originator derives a shared secret (SS) from the random
integer (z). The originator then sends the ciphertext (ct) to the integer (z). The originator then sends the ciphertext (ct) to the
recipient. The recipient decrypts the ciphertext (ct) using their recipient. The recipient decrypts the ciphertext (ct) using their
private key to recover the random integer (z), and the recipient private key to recover the random integer (z), and the recipient
derives a shared secret (SS) from the random integer (z). In this derives a shared secret (SS) from the random integer (z). In this
way, the originator and recipient obtain the same shared secret (SS). way, the originator and recipient obtain the same shared secret (SS).
The RSA-KEM Algorithm depends on a key-derivation function (KDF), The RSA-KEM algorithm depends on a key derivation function (KDF),
which is used to derive the shared secret (SS). Many key-derivation which is used to derive the shared secret (SS). Many key derivation
functions support the inclusion of other information in addition to functions support the inclusion of other information in addition to
the shared secret (SS) in the input to the function; however, no the shared secret (SS) in the input to the function; however, no
other information is included as an input to the KDF by the RSA-KEM other information is included as an input to the KDF by the RSA-KEM
Algorithm. algorithm.
A.1. Originator's Operations: RSA-KEM Encapsulate() A.1. Originator's Operations: RSA-KEM Encapsulate()
Let (n,e) be the recipient's RSA public key; see [RFC8017] for Let (n,e) be the recipient's RSA public key; see [RFC8017] for
details. details.
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 originator performs the following operations: The originator performs the following operations:
skipping to change at line 758 skipping to change at line 759
2. Encrypt the random integer z using the recipient's RSA public key 2. 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 (n,e) and convert the resulting integer c to a ciphertext C, a
byte string of length nLen: byte string of length nLen:
c = z^e mod n c = z^e mod n
ct = IntegerToString (c, nLen) ct = IntegerToString (c, nLen)
3. Derive a symmetric shared secret SS of length ssLen bytes (which 3. Derive a symmetric shared secret SS of length ssLen bytes (which
MUST be the length of the key-encryption key) from the byte MUST be the length of the key-encryption key) from the byte
string Z using the underlying key-derivation function: string Z using the underlying key derivation function:
SS = KDF (Z, ssLen) SS = KDF (Z, ssLen)
4. Output the shared secret SS and the ciphertext ct. Send the 4. Output the shared secret SS and the ciphertext ct. Send the
ciphertext ct to the recipient. ciphertext ct to the recipient.
NOTE: The random integer z MUST be generated independently at random NOTE: The random integer z MUST be generated independently at random
for different encryption operations, whether for the same or for different encryption operations, whether for the same or
different recipients. different recipients.
skipping to change at line 802 skipping to change at line 803
recover an integer z (see NOTE below): recover an integer z (see NOTE below):
z = c^d mod n z = c^d mod n
4. Convert the integer z to a byte string Z of length nLen, most 4. Convert the integer z to a byte string Z of length nLen, most
significant byte first (see NOTE below): significant byte first (see NOTE below):
Z = IntegerToString (z, nLen) Z = IntegerToString (z, nLen)
5. Derive a shared secret SS of length ssLen bytes from the byte 5. Derive a shared secret SS of length ssLen bytes from the byte
string Z using the key-derivation function (see NOTE below): string Z using the key derivation function (see NOTE below):
SS = KDF (Z, ssLen) SS = KDF (Z, ssLen)
6. Output the shared secret SS. 6. Output the shared secret SS.
NOTE: Implementations SHOULD NOT reveal information about the integer NOTE: Implementations SHOULD NOT reveal information about the integer
z, the string Z, or about the calculation of the exponentiation in 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, Step 2, the conversion in Step 3, or the key derivation in Step 4,
whether by timing or other "side channels". The observable behavior whether by timing or other "side channels". The observable behavior
of the implementation SHOULD be the same at these steps for all of the implementation SHOULD be the same at these steps for all
ciphertexts C that are in range. For example, IntegerToString ciphertexts C that are in range. For example, IntegerToString
conversion should take the same amount of time regardless of the conversion should take the same amount of time regardless of the
actual value of the integer z. The integer z, the string Z, and actual value of the integer z. The integer z, the string Z, and
other intermediate results MUST be securely deleted when they are no other intermediate results MUST be securely deleted when they are no
longer needed. longer needed.
Appendix B. ASN.1 Syntax Appendix B. ASN.1 Syntax
The ASN.1 syntax for identifying the RSA-KEM Algorithm is an The ASN.1 syntax for identifying the RSA-KEM algorithm is an
extension of the syntax for the "generic hybrid cipher" in ANS X9.44 extension of the syntax for the "generic hybrid cipher" in ANS X9.44
[ANS-X9.44]. [ANS-X9.44].
The ASN.1 Module is unchanged from RFC 5990. The id-rsa-kem-spki The ASN.1 Module is unchanged from RFC 5990. The id-rsa-kem-spki
object identifier is used in a backward compatible manner in object identifier is used in a backward compatible manner in
certificates [RFC5280] and SMIMECapabilities [RFC8551]. Of course, certificates [RFC5280] and SMIMECapabilities [RFC8551]. Of course,
the use of the id-kem-rsa object identifier in the new the use of the id-kem-rsa object identifier in the new
KEMRecipientInfo structure [RFC9629] was not yet defined at the time KEMRecipientInfo structure [RFC9629] was not yet defined at the time
that RFC 5990 was written. that RFC 5990 was written.
B.1. Underlying Components B.1. Underlying Components
Implementations that conform to this specification MUST support the Implementations that conform to this specification MUST support the
KDF3 [ANS-X9.44] key-derivation function using SHA-256 [SHS]. KDF3 [ANS-X9.44] key derivation function using SHA-256 [SHS].
KDF2 [ANS-X9.44] and KDF3 are both key-derivation functions based on KDF2 [ANS-X9.44] and KDF3 are both key derivation functions based on
a hash function. The only difference between KDF2 and KDF3 is the a hash function. The only difference between KDF2 and KDF3 is the
order of the components to be hashed. order of the components to be hashed.
KDF2 calculates T as: T = T || Hash (Z || D || otherInfo) KDF2 calculates T as: T = T || Hash (Z || D || otherInfo)
KDF3 calculates T as: T = T || Hash (D || Z || otherInfo) KDF3 calculates T as: T = T || Hash (D || Z || otherInfo)
The object identifier for KDF3 is: The object identifier for KDF3 is:
id-kdf-kdf3 OBJECT IDENTIFIER ::= { x9-44-components kdf3(2) } id-kdf-kdf3 OBJECT IDENTIFIER ::= { x9-44-components kdf3(2) }
skipping to change at line 1115 skipping to change at line 1116
kwa-camellia192-wrap.&smimeCaps | kwa-camellia192-wrap.&smimeCaps |
kwa-camellia256-wrap.&smimeCaps, kwa-camellia256-wrap.&smimeCaps,
... } ... }
END END
<CODE ENDS> <CODE ENDS>
Appendix C. SMIMECapabilities Examples Appendix C. SMIMECapabilities Examples
To indicate support for the RSA-KEM algorithm coupled with the KDF3 To indicate support for the RSA-KEM algorithm coupled with the KDF3
key-derivation function with SHA-256 and the AES Key Wrap symmetric key derivation function with SHA-256 and the AES Key Wrap symmetric
key-encryption algorithm 128-bit key-encryption key, the key-encryption algorithm 128-bit key-encryption key, the
SMIMECapabilities will include the following entry: SMIMECapabilities will include the following entry:
SEQUENCE { SEQUENCE {
id-rsa-kem-spki, -- RSA-KEM Algorithm id-rsa-kem-spki, -- RSA-KEM Algorithm
SEQUENCE { -- GenericHybridParameters SEQUENCE { -- GenericHybridParameters
SEQUENCE { -- key encapsulation mechanism SEQUENCE { -- key encapsulation mechanism
id-kem-rsa, -- RSA-KEM id-kem-rsa, -- RSA-KEM
SEQUENCE { -- RsaKemParameters SEQUENCE { -- RsaKemParameters
SEQUENCE { -- key derivation function SEQUENCE { -- key derivation function
skipping to change at line 1156 skipping to change at line 1157
30 1e 30 1e
30 19 30 19
06 0a 2b 81 05 10 86 48 09 2c 01 02 -- id-kdf-kdf3 06 0a 2b 81 05 10 86 48 09 2c 01 02 -- id-kdf-kdf3
30 0b 30 0b
06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 06 09 60 86 48 01 65 03 04 02 01 -- id-sha256
02 01 10 -- 16 bytes 02 01 10 -- 16 bytes
30 0b 30 0b
06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap 06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap
To indicate support for the RSA-KEM algorithm coupled with the KDF3 To indicate support for the RSA-KEM algorithm coupled with the KDF3
key-derivation function with SHA-384 and the AES Key Wrap symmetric key derivation function with SHA-384 and the AES Key Wrap symmetric
key-encryption algorithm 192-bit key-encryption key, the key-encryption algorithm 192-bit key-encryption key, the
SMIMECapabilities will include the following SMIMECapability value SMIMECapabilities will include the following SMIMECapability value
(in hexadecimal): (in hexadecimal):
30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30
38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19
06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09
60 86 48 01 65 03 04 02 02 02 01 18 30 0b 06 09 60 86 48 01 65 03 04 02 02 02 01 18 30 0b 06 09
60 86 48 01 65 03 04 01 19 60 86 48 01 65 03 04 01 19
To indicate support for the RSA-KEM algorithm coupled with the KDF3 To indicate support for the RSA-KEM algorithm coupled with the KDF3
key-derivation function with SHA-512 and the AES Key Wrap symmetric key derivation function with SHA-512 and the AES Key Wrap symmetric
key-encryption algorithm 256-bit key-encryption key, the key-encryption algorithm 256-bit key-encryption key, the
SMIMECapabilities will include the following SMIMECapability value SMIMECapabilities will include the following SMIMECapability value
(in hexadecimal): (in hexadecimal):
30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30
38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19
06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09
60 86 48 01 65 03 04 02 03 02 01 20 30 0b 06 09 60 86 48 01 65 03 04 02 03 02 01 20 30 0b 06 09
60 86 48 01 65 03 04 01 2d 60 86 48 01 65 03 04 01 2d
 End of changes. 59 change blocks. 
68 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.48.