RFC 9629

Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)

πŸ“… published August 2024, from ietf

RFC 9629: Using KEM Algorithms in CMS πŸŽ€

okay so RFC 9629 is giving key encapsulation realness πŸ’… It's an Internet Standards Track doc, dated August 2024, and it lives in the IETF stream. It updates RFC 5652 (that's the big CMS spec), and the header doesn't list anything it obsoletes. The authors are R. Housley (Vigil Security), J. Gray (Entrust), and 倧久保　智史 (T. Okubo) from Penguin Securities Pte. Ltd. 🧚 The ISSN is 2070-1721, and the title is "Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" ✨

Abstract ✨

bestie, CMS already has key transport and key agreement algorithms πŸ’– Lately cryptographers have been cooking up KEM algorithms, including quantum-secure ones πŸ”₯ This doc sets the conventions for how originators and recipients use KEM algorithms to encrypt and decrypt CMS content. It updates RFC 5652 πŸ¦‹

Status of This Memo 🌸

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841 πŸ“š

You can find the current status of this document, any errata, and how to give feedback at https://www.rfc-editor.org/info/rfc9629 πŸ’œ

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Revised BSD License 🫢

Table of Contents 🧚

1.  Introduction
  1.1.  Terminology
  1.2.  ASN.1
  1.3.  CMS Version Numbers
2.  KEM Processing Overview
3.  KEM Recipient Information
4.  KEM Algorithm Identifier
5.  Key Derivation
6.  ASN.1 Modules
  6.1.  KEMAlgorithmInformation-2023 ASN.1 Module
  6.2.  CMS-KEMRecipientInfo-2023 ASN.1 Module
7.  Security Considerations
8.  IANA Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction πŸ’–

okay so this doc updates "Cryptographic Message Syntax (CMS)" [RFC5652] ✨

The CMS enveloped-data content type [RFC5652] and the CMS authenticated-enveloped-data content type [RFC5083] both support key transport and key agreement algorithms to set up the key that encrypts and decrypts the content. Cryptographers have been specifying KEM algorithms lately, including quantum-secure ones, and this doc defines how KEM algorithms get used for those two content types πŸ”₯

A KEM algorithm is a one-pass (store-and-forward) way to send random keying material to a recipient, using the recipient's public key πŸ¦‹ The originator and recipients don't have to be online at the same time, which is lowkey the best part πŸŒ™ Only the recipient's private key can recover that random keying material. Once it's recovered, it counts as a pairwise shared secret (ss) between the originator and that recipient πŸ’œ

Here's the flow: the KEMRecipientInfo structure in this doc feeds the pairwise shared secret into a key derivation function (KDF) to get a pairwise key-encryption key (KEK) πŸ“ That pairwise KEK then encrypts a content-encryption key (CEK) or a content-authenticated-encryption key (CAEK) for that recipient. Every recipient gets the same CEK or CAEK ✨

Security in this setup depends on three things, and they're all important 😭 First, the KEM algorithm has to be secure against adaptive chosen ciphertext attacks. Second, the key-encryption algorithm has to provide confidentiality and integrity protection. Third, the choices of KDF and key-encryption algorithm need to give the same level of security as the KEM algorithm πŸ’…

A KEM algorithm gives you three functions πŸ‘‘

KeyGen() -> (pk, sk)
Encapsulate(pk) -> (ct, ss)
Decapsulate(sk, ct) -> ss
  • KeyGen() generates the public key (pk) and a private key (sk).
  • Encapsulate(pk) takes the recipient's public key (pk) and produces a ciphertext (ct) to pass to the recipient, plus a shared secret (ss) for the originator.
  • Decapsulate(sk, ct) takes the private key (sk) and the ciphertext (ct) and produces the shared secret (ss) for the recipient.

To support a particular KEM algorithm, the CMS originator MUST implement the KEM Encapsulate() function. That's non-negotiable, bestie πŸ™ˆ

To support a particular KEM algorithm, the CMS recipient MUST implement the KEM KeyGen() function and the KEM Decapsulate() function. The recipient's public key is usually carried in a certificate [RFC5280] πŸŽ€

1.1. Terminology πŸ“–

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here πŸ’œ So if they're not in all caps, they're just regular words, no cap 🧒

1.2. ASN.1 🌸

CMS values are generated using ASN.1 [X.680], which uses the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X.690] ✨

1.3. CMS Version Numbers πŸ¦‹

As described in Section 1.3 of [RFC5652], the major data structures include a version number as the first item in the data structure. The version number is meant to avoid ASN.1 decode errors. Some implementations don't check the version number before attempting a decode. If a decode error happens, then the version number gets checked as part of the error-handling routine. This is a reasonable approach, since it keeps error processing outside of the fast path πŸƒβ€β™€οΈ It's also forgiving when the originator uses an incorrect version number πŸ₯Ή

Whenever the structure is updated, a higher version number gets assigned. However, for maximum interoperability, the higher version number is only used when the new syntax feature is actually employed. In other words, the lowest version number that supports the generated syntax is used πŸ“

2. KEM Processing Overview 🧚

KEM algorithms can be used with three CMS content types: the enveloped-data content type [RFC5652], the authenticated-data content type [RFC5652], or the authenticated-enveloped-data content type [RFC5083]. For simplicity, this overview uses the enveloped-data terminology πŸ’–

The originator randomly generates the CEK (or the CAEK). Then every recipient gets that key as an encrypted object inside the KEMRecipientInfo encryptedKey field, which Section 3 explains. Every recipient uses the originator-generated symmetric key to decrypt the CMS message ✨

A KEM algorithm and a key derivation function work together to securely establish a pairwise symmetric KEK. That KEK is what encrypts the originator-generated CEK (or the CAEK) πŸ”₯

Ahead of time, each recipient uses the KEM KeyGen() function to make a key pair. Recipients often get a certificate [RFC5280] that includes the newly generated public key πŸŽ€ Whether or not the public key is certified, it's made available to potential originators πŸ¦‹

The originator sets up the CEK (or the CAEK) in these steps:

  1. The CEK (or the CAEK) is generated at random.
  2. For each recipient:
    • The recipient's public key is used with the KEM Encapsulate() function to get a pairwise shared secret (ss) and the ciphertext for that recipient.
    • The key derivation function derives a pairwise symmetric KEK from the pairwise ss and other data that is optionally sent in the ukm field.
    • The KEK encrypts the CEK for this recipient.
  3. The CEK (or the CAEK) encrypts the content for all recipients πŸ’…

The recipient gets the CEK (or the CAEK) in these steps:

  1. The recipient's private key and the ciphertext go into the KEM Decapsulate() function to get a pairwise ss.
  2. The key derivation function derives a pairwise symmetric KEK from the pairwise ss and other data that is optionally sent in the ukm field.
  3. The KEK decrypts the CEK (or the CAEK).
  4. The CEK (or the CAEK) decrypts the content 🌈

3. KEM Recipient Information ✨

okay so this section is where we define KEMRecipientInfo for use with KEM algorithms πŸ’… CMS has a whole system for extra key management techniques, and per Section 6.2.5 of [RFC5652] they all get stuffed into OtherRecipientInfo. Every technique gets its own unique ASN.1 object identifier, kind of like a name tag 🏷️

The object identifier for KEMRecipientInfo is:

id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
  rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 }

id-ori-kem OBJECT IDENTIFIER ::= { id-ori 3 }

And the KEMRecipientInfo type itself looks like this πŸ¦‹

KEMRecipientInfo ::= SEQUENCE {
  version CMSVersion,  -- always set to 0
  rid RecipientIdentifier,
  kem KEMAlgorithmIdentifier,
  kemct OCTET STRING,
  kdf KeyDerivationAlgorithmIdentifier,
  kekLength INTEGER (1..65535),
  ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL,
  wrap KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey }

Now let's break down each field, because every single one matters πŸŽ€

version is the syntax version number, and it MUST be 0. The CMSVersion type is described in Section 10.2.5 of [RFC5652]. Literally always 0, no exceptions πŸ™ˆ

rid tells you which recipient certificate or key the originator used with the KEM Encapsulate() function. RecipientIdentifier gives two options for pointing at the recipient's certificate [RFC5280], and through that, their public key. The recipient's certificate MUST contain a KEM public key. So a recipient X.509 version 3 certificate that contains a key usage extension MUST assert the keyEncipherment bit. The issuerAndSerialNumber option finds the certificate by the issuer's distinguished name and the certificate serial number. The subjectKeyIdentifier option finds it by a key identifier. When an X.509 certificate is referenced, the key identifier matches the X.509 subjectKeyIdentifier extension value. When other certificate formats are referenced, the documents that specify the certificate format and their use with the CMS must include details on matching the key identifier to the appropriate certificate field. For recipient processing, implementations MUST support both of these alternatives for specifying the recipient's certificate. For originator processing, implementations MUST support at least one of these alternatives. πŸ”₯

kem identifies the KEM algorithm, plus any associated parameters, that the originator used. The KEMAlgorithmIdentifier is described in Section 4.

kemct is the ciphertext produced by the KEM Encapsulate() function for this recipient. 🧚

kdf identifies the key derivation function, plus any associated parameters, that the originator used to generate the KEK. The KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of [RFC5652].

kekLength is the size of the KEK in octets. This value is one of the inputs to the key derivation function. The upper bound on the integer is there to make it super clear to implementers that support for very large integer values is not needed. Implementations MUST confirm that the value provided is consistent with the key-encryption algorithm identified in the wrap field below. Double-checking, very important πŸ’–

ukm is optional user keying material. When the ukm value is provided, it is used as part of the info structure described in Section 5 to give the key derivation function some context input. For example, the ukm value could include a nonce, application-specific context information, or an identifier for the originator. A KEM algorithm may place requirements on the ukm value. Implementations that do not support the ukm field SHOULD gracefully discontinue processing when the ukm field is present. Note that this requirement expands the original purpose of the ukm described in Section 10.2.6 of [RFC5652]. It is not limited to being used with key agreement algorithms. That's a big glow-up for ukm 🌈

wrap identifies the key-encryption algorithm used to encrypt the CEK. The KeyEncryptionAlgorithmIdentifier is described in Section 10.1.3 of [RFC5652].

encryptedKey is the result of encrypting the CEK, or the CAEK (the content-authenticated-encryption key, as discussed in [RFC5083]), with the KEK. EncryptedKey is an OCTET STRING. ✨

4. KEM Algorithm Identifier

The KEMAlgorithmIdentifier type identifies a KEM algorithm used to establish a pairwise ss. The details of establishment depend on the KEM algorithm used. A key derivation function is then used to transform the pairwise ss value into a KEK πŸ“

KEMAlgorithmIdentifier ::= AlgorithmIdentifier{ KEM-ALGORITHM, {...} }

5. Key Derivation

This section describes how to use the KDF to compute the KEK for KEMRecipientInfo. For simplicity, we're borrowing the terminology from the HKDF specification [RFC5869] πŸ¦‹

Lots of KDFs internally use a one-way hash function. When that's the case, the hash function is indirectly indicated by the KeyDerivationAlgorithmIdentifier. Other KDFs internally use an encryption algorithm. When that's the case, the encryption algorithm is indirectly indicated by the KeyDerivationAlgorithmIdentifier too.

The KDF inputs are as follows:

  • IKM is the input keying material. It's a symmetric secret input to the KDF. The KDF may use a hash function or an encryption algorithm to generate a pseudorandom key. Which algorithm gets used to derive the IKM depends on the algorithm identified in the KeyDerivationAlgorithmIdentifier. πŸ”
  • L is the length of the output keying material in octets. L is identified in the kekLength of the KEMRecipientInfo. The value depends on the key-encryption algorithm used, and that algorithm is identified in the KeyEncryptionAlgorithmIdentifier.
  • info is contextual input to the KDF. The DER-encoded CMSORIforKEMOtherInfo structure gets created from elements of the KEMRecipientInfo structure. CMSORIforKEMOtherInfo is defined as:
CMSORIforKEMOtherInfo ::= SEQUENCE {
  wrap KeyEncryptionAlgorithmIdentifier,
  kekLength INTEGER (1..65535),
  ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }

The CMSORIforKEMOtherInfo structure contains the following:

  • wrap identifies a key-encryption algorithm. The output of the key derivation function will be used as a key for this algorithm.
  • kekLength is the length of the KEK in octets. The output of the key derivation function will be exactly this size.
  • ukm is optional user keying material. See Section 3.

The KDF output is as follows:

  • OKM is the output keying material, with the exact length of L octets. The OKM is the KEK that gets used to encrypt the CEK or the CAEK. πŸŽ€

An acceptable KDF MUST accept an IKM, L, and info as inputs. An acceptable KDF MAY also accept a salt input value, which is carried as a parameter to the KeyDerivationAlgorithmIdentifier if present. All of these inputs MUST influence the output of the KDF. Every single input has to matter, no ghosting πŸ‘»

6. ASN.1 Modules

This section provides two ASN.1 modules [X.680]. The first ASN.1 module is an extension to the AlgorithmInformation-2009 module discussed in [RFC5912], and it defines the KEM-ALGORITHM CLASS. The second ASN.1 module defines the structures needed to use KEM algorithms with CMS [RFC5652] 🌸

The first ASN.1 module uses EXPLICIT tagging, and the second ASN.1 module uses IMPLICIT tagging. Both ASN.1 modules follow the conventions established in [RFC5911], [RFC5912], and [RFC6268].

6.1. KEMAlgorithmInformation-2023 ASN.1 Module

<CODE BEGINS>
KEMAlgorithmInformation-2023
  { iso(1) identified-organization(3) dod(6) internet(1)
    security(5) mechanisms(5) pkix(7) id-mod(0)
        id-mod-kemAlgorithmInformation-2023(109) }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL;
IMPORTS
  ParamOptions, PUBLIC-KEY, SMIME-CAPS
  FROM AlgorithmInformation-2009
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-algorithmInformation-02(58) } ;

-- KEM-ALGORITHM
--
-- Describes the basic properties of a KEM algorithm
--
-- Suggested prefix for KEM algorithm objects is: kema-
--
--  &id - contains the OID identifying the KEM algorithm
--  &Value - if present, contains a type definition for the kemct;
--               if absent, implies that no ASN.1 encoding is
--               performed on the kemct value
--  &Params - if present, contains the type for the algorithm
--               parameters; if absent, implies no parameters
--  &paramPresence - parameter presence requirement
--  &PublicKeySet - specifies which public keys are used with
--               this algorithm
--  &Ukm - if absent, type for user keying material
--  &ukmPresence - specifies the requirements to define the UKM
--               field
--  &smimeCaps - contains the object describing how the S/MIME
--               capabilities are presented.
--
-- Example:
-- kema-kem-rsa KEM-ALGORITHM ::= {
--    IDENTIFIER id-kem-rsa
--    PARAMS TYPE RsaKemParameters ARE optional
--    PUBLIC-KEYS { pk-rsa | pk-rsa-kem }
--    UKM ARE optional
--    SMIME-CAPS { TYPE GenericHybridParameters
--        IDENTIFIED BY id-rsa-kem }
-- }

KEM-ALGORITHM ::= CLASS {
  &id             OBJECT IDENTIFIER UNIQUE,
  &Value          OPTIONAL,
  &Params         OPTIONAL,
  &paramPresence  ParamOptions DEFAULT absent,
  &PublicKeySet   PUBLIC-KEY OPTIONAL,
  &Ukm            OPTIONAL,
  &ukmPresence    ParamOptions DEFAULT absent,
  &smimeCaps      SMIME-CAPS OPTIONAL
} WITH SYNTAX {
  IDENTIFIER &id
  [VALUE &Value]
  [PARAMS [TYPE &Params] ARE &paramPresence]
  [PUBLIC-KEYS &PublicKeySet]
  [UKM [TYPE &Ukm] ARE &ukmPresence]
  [SMIME-CAPS &smimeCaps]
}

END
<CODE ENDS>

6.2. CMS-KEMRecipientInfo-2023 ASN.1 Module πŸŽ€

Okay, bestie, here's the second ASN.1 module, the one that actually defines the KEMRecipientInfo structure that CMS uses πŸ’–

<CODE BEGINS>
  CMS-KEMRecipientInfo-2023
    { iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs-9(9) smime(16) modules(0)
      id-mod-cms-kemri-2023(77) }

  DEFINITIONS IMPLICIT TAGS ::=
  BEGIN
  -- EXPORTS ALL;
  IMPORTS
    OTHER-RECIPIENT, CMSVersion, RecipientIdentifier,
    EncryptedKey, KeyDerivationAlgorithmIdentifier,
    KeyEncryptionAlgorithmIdentifier, UserKeyingMaterial
      FROM CryptographicMessageSyntax-2010  -- RFC 6268
        { iso(1) member-body(2) us(840) rsadsi(113549)
          pkcs(1) pkcs-9(9) smime(16) modules(0)
          id-mod-cms-2009(58) }
    KEM-ALGORITHM
      FROM KEMAlgorithmInformation-2023  -- RFC 9629
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-mod(0)
          id-mod-kemAlgorithmInformation-2023(109) }
    AlgorithmIdentifier{}
      FROM AlgorithmInformation-2009  -- RFC 5912
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-mod(0)
          id-mod-algorithmInformation-02(58) } ;

  --
  -- OtherRecipientInfo Types (ori-)
  --

  SupportedOtherRecipInfo OTHER-RECIPIENT ::= { ori-KEM, ... }

  ori-KEM OTHER-RECIPIENT ::= {
    KEMRecipientInfo IDENTIFIED BY id-ori-kem }

  id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
    rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 }

  id-ori-kem OBJECT IDENTIFIER ::= { id-ori 3 }

  --
  -- KEMRecipientInfo
  --

  KEMRecipientInfo ::= SEQUENCE {
    version CMSVersion,  -- always set to 0
    rid RecipientIdentifier,
    kem KEMAlgorithmIdentifier,
    kemct OCTET STRING,
    kdf KeyDerivationAlgorithmIdentifier,
    kekLength INTEGER (1..65535),
    ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL,
    wrap KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }

  KEMAlgSet KEM-ALGORITHM ::= { ... }

  KEMAlgorithmIdentifier ::=
    AlgorithmIdentifier{ KEM-ALGORITHM, {KEMAlgSet} }

  --
  -- CMSORIforKEMOtherInfo
  --

  CMSORIforKEMOtherInfo ::= SEQUENCE {
    wrap KeyEncryptionAlgorithmIdentifier,
    kekLength INTEGER (1..65535),
    ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }

  END
<CODE ENDS>

7. Security Considerations πŸ”₯

Okay, security time, and this part is SERIOUS, so pay attention πŸ™ˆ The security considerations from [RFC5652] apply to this document too, so go read those as well.

To be appropriate for use with this specification, the KEM algorithm MUST explicitly be designed to be secure when the public key is used many times. Like, a KEM algorithm with a single-use public key is a no-go, because the public key is expected to live in a long-lived certificate [RFC5280] and get used over and over and over. So KEM algorithms that offer indistinguishability under adaptive chosen ciphertext attack (IND-CCA2) security are the ones that are giving appropriate energy. A common design pattern for getting IND-CCA2 security while reusing public keys is to apply the Fujisaki-Okamoto (FO) transform [FO] or a variant of the FO transform [HHK]. Iconic πŸ‘‘

The KDF SHOULD offer at least the security level of the KEM. πŸ’…

The choice of the key-encryption algorithm and the size of the KEK SHOULD be made based on the security level provided by the KEM. The key-encryption algorithm and the KEK SHOULD offer at least the security level of the KEM. Keep those levels matching, periodt ✨

KEM algorithms do not provide data origin authentication. So when a KEM algorithm is used with the authenticated-data content type, the contents arrive with integrity from an unknown source. Not me being nervous about that πŸ’€

Implementations MUST protect the KEM private key, the KEK, and the CEK (or the CAEK). Compromising the KEM private key may result in the disclosure of all contents protected with that KEM private key 😭 Compromising the KEK, the CEK, or the CAEK may result in disclosure of the encrypted content of a single message. Still bad, but way less of a disaster.

The KEM produces the IKM input value for the KDF. This IKM value MUST NOT be reused for any other purpose. The same goes for any random value used by the KEM algorithm to produce the shared secret or its encapsulation: it MUST NOT be reused for any other purpose either. So, the originator MUST generate a fresh KEM shared secret for each recipient in the KEMRecipientInfo structure, including any random value the KEM algorithm uses to produce the KEM shared secret. Also, the originator MUST discard the KEM shared secret, including any random value used by the KEM algorithm to produce the KEM shared secret, after building the entry in the KEMRecipientInfo structure for the corresponding recipient. And the recipient MUST discard the KEM shared secret, including any random value used by the KEM algorithm to produce the KEM shared secret, after constructing the KEK from the KEMRecipientInfo structure. Throw it away, every time πŸ—‘οΈβœ¨

Implementations MUST randomly generate content-encryption keys, content-authenticated-encryption keys, and message-authentication keys. The generation of KEM key pairs also relies on random numbers. Using inadequate pseudorandom number generators (PRNGs) to generate these keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys and search the resulting small set of possibilities, rather than brute-forcing the whole key space. Generating quality random numbers is genuinely difficult. [RFC4086] offers important guidance in this area, so read it, bestie 🧚

If the cipher and key sizes used for the key-encryption algorithm and the content-encryption algorithm are different, the effective security is determined by the weaker of the two algorithms. For example, if the content is encrypted with AES-CBC using a 128-bit CEK and the CEK is wrapped with AES-KEYWRAP using a 256-bit KEK, then at most 128 bits of protection is provided. The weakest link is the whole chain πŸ’”

If the cipher and key sizes used for the key-encryption algorithm and the content-authenticated-encryption algorithm are different, the effective security is determined by the weaker of the two algorithms. For example, if the content is encrypted with AES-GCM using a 128-bit CAEK and the CAEK is wrapped with AES-KEYWRAP using a 192-bit KEK, then at most 128 bits of protection is provided. Same energy, different cipher πŸŽ€

If the cipher and key sizes used for the key-encryption algorithm and the message-authentication algorithm are different, the effective security is determined by the weaker of the two algorithms. For example, if the content is authenticated with HMAC-SHA256 using a 512-bit message-authentication key and that key is wrapped with AES-KEYWRAP using a 256-bit KEK, then at most 256 bits of protection is provided. Mismatched sizes are a whole vibe-killer πŸ™ƒ

Implementers should be aware that cryptographic algorithms, including KEM algorithms, become weaker with time. As new cryptanalysis techniques are developed and computing capabilities advance, the work factor to break a particular cryptographic algorithm will go down. So cryptographic algorithm implementations should be modular, allowing new algorithms to be readily inserted. In other words, implementers should be prepared for the set of supported algorithms to change over time. Nothing lasts forever, not even crypto πŸ¦‹

8. IANA Considerations 🌸

For KEMRecipientInfo as defined in Section 3, IANA has assigned the following OID in the "SMI Security for S/MIME Other Recipient Info Identifiers (1.2.840.113549.1.9.16.13)" registry:

+=========+=============+============+
| Decimal | Description | References |
+=========+=============+============+
| 3       | id-ori-kem  | RFC 9629   |
+---------+-------------+------------+

Table 1

For the ASN.1 module defined in Section 6.1, IANA has assigned the following OID in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0):

+=========+=====================================+============+
| Decimal | Description                         | References |
+=========+=====================================+============+
| 109     | id-mod-kemAlgorithmInformation-2023 | RFC 9629   |
+---------+-------------------------------------+------------+

Table 2

For the ASN.1 module defined in Section 6.2, IANA has assigned the following OID in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:

+=========+=======================+============+
| Decimal | Description           | References |
+=========+=======================+============+
| 77      | id-mod-cms-kemri-2023 | RFC 9629   |
+---------+-----------------------+------------+

Table 3

9. References πŸ“š

9.1. Normative References

Okay bestie, this is the final stretch of the references and back matter πŸŽ€βœ¨ Let's go!

9. References ✨

9.2. Informative References πŸ“š

  • [FO]: Fujisaki, E. and T. Okamoto, "Secure Integration of Asymmetric and Symmetric Encryption Schemes", Springer Science and Business Media LLC, Journal of Cryptology, vol. 26, no. 1, pp. 80-101, DOI 10.1007/s00145-011-9114-1, December 2011, <https://doi.org/10.1007/s00145-011-9114-1>. πŸ”
  • [HHK]: Hofheinz, D., HΓΆvelmanns, K., and E. Kiltz, "A Modular Analysis of the Fujisaki-Okamoto Transformation", Springer International Publishing, Theory of Cryptography, TCC 2017, Lecture Notes in Computer Science, vol. 10677, pp. 341-371, Print ISBN 9783319704999, Online ISBN 9783319705002, DOI 10.1007/978-3-319-70500-2_12, November 2017, <https://doi.org/10.1007/978-3-319-70500-2_12>. 🧠
  • [RFC4086]: Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>. 🎲
  • [RFC5869]: Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>. πŸ”‘
  • [RFC6268]: Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>. 🧩

Acknowledgements 🫢

Huge thank-yous to Burt Kaliski for the guidance and design review πŸ’œ

Big shoutout to Carl Wallace for his careful review of the ASN.1 modules πŸ™Œ

Massive love to Hendrik Brockhaus, Jonathan Hammell, Mike Jenkins, David von Oheimb, Francois Rousseau, and Linda Dunbar for their careful reviews and thoughtful comments 🌸

Authors' Addresses πŸ’Œ

Russ Housley Vigil Security, LLC Herndon, VA United States of America Email: housley@vigilsec.com

John Gray Entrust Minneapolis, MN United States of America Email: john.gray@entrust.com

Tomofumi Okubo Penguin Securities Pte. Ltd. Singapore Email: tomofumi.okubo+ietf@gmail.com

Additional contact information:

倧久保　智史 Penguin Securities Pte. Ltd. Singapore

That's the whole thing, bestie! RFC 9629 wrapped up πŸ¦‹πŸ’–πŸ‘‘

πŸ“¦ where this page comes from