RFC 8418

Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)

📅 published August 2018, from ietf

RFC 8418: Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) 🎀

okay so bestie, this one is all about making ECDH key agreement work with X25519 and X448 inside CMS 🦋

R. Housley from Vigil Security wrote it, and it's RFC 8418. It's a Standards Track document dated August 2018, and it's published under ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Abstract ✨

Okay, the abstract is short and sweet. It explains how to use Elliptic Curve Diffie-Hellman (ECDH) key agreement with curve25519 and curve448 inside the Cryptographic Message Syntax (CMS) 🌸

Status of This Memo 🧚

This is an Internet Standards Track document, so it's a real standard, not a casual draft 😭

It comes from the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841.

You can find the current status of this document, any errata, and a way to send feedback at https://www.rfc-editor.org/info/rfc8418.

Copyright (c) 2018 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) as they were on the day this was published. Read those carefully, because they spell out what you can and can't do with this document. Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.

Table of Contents 🍓

1. Introduction ....................................................2
   1.1. Terminology ................................................3
   1.2. ASN.1 ......................................................3
2. Key Agreement ...................................................3
   2.1. ANSI-X9.63-KDF .............................................4
   2.2. HKDF .......................................................5
3. Enveloped-data Conventions ......................................5
   3.1. EnvelopedData Fields .......................................6
   3.2. KeyAgreeRecipientInfo Fields ...............................6
4. Authenticated-data Conventions ..................................7
   4.1. AuthenticatedData Fields ...................................8
   4.2. KeyAgreeRecipientInfo Fields ...............................8
5. Authenticated-enveloped-data Conventions ........................8
   5.1. AuthEnvelopedData Fields ...................................8
   5.2. KeyAgreeRecipientInfo Fields ...............................8
6. Certificate Conventions .........................................9
7. Key Agreement Algorithm Identifiers .............................9
8. SMIMECapabilities Attribute Conventions ........................10
9. Security Considerations ........................................11
10. IANA Considerations ...........................................12
11. References ....................................................13
   11.1. Normative References .....................................13
   11.2. Informative References ...................................14
Appendix A. ASN.1 Module ..........................................16
Acknowledgements ..................................................18
Author's Address ..................................................18

1. Introduction ✨

This doc is all about using Elliptic Curve Diffie-Hellman (ECDH) key agreement with curve25519 and curve448 [CURVES] inside the Cryptographic Message Syntax (CMS) [CMS]. Key agreement works with three CMS content types: the enveloped-data content type [CMS], the authenticated-data content type [CMS], and the authenticated-enveloped-data content type [AUTHENV] 💖

There's also a companion doc. [CMSECC] covers how to use some other Elliptic Curve Cryptography (ECC) algorithms in CMS, including ECDH with curves other than curve25519 and curve448 [CURVES]. Those other curves aren't deprecated, so they're still a thing 👑

Quick naming note: Diffie-Hellman key agreement with curve25519 is called "X25519", and with curve448 it's called "X448" 🦋

1.1. Terminology 📖

The BCP 14 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are read as described in BCP 14 [RFC2119] [RFC8174], but only when they're written in all capitals, like they are right here 🫶

1.2. ASN.1 🌈

CMS values get generated using ASN.1 [X680]. The encoding uses the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X690] 🧚

2. Key Agreement 💅

Okay, history time! In 1976, Diffie and Hellman came up with a way for two parties to agree on a shared secret value without eavesdroppers being able to learn it [DH1976] 😭 That secret can then be turned into pairwise symmetric keying material for other crypto algorithms. Lots of variants have shown up since then. This doc explains how to use Ephemeral-Static Elliptic Curve Diffie-Hellman (ECDH) key agreement with X25519 and X448 [CURVES] 🔥

The originator MUST use an ephemeral public/private key pair that's generated on the same elliptic curve as the recipient's public key. That ephemeral key pair MUST be used for a single CMS-protected content type, and then it MUST be discarded. The originator gets the recipient's static public key from the recipient's certificate [PROFILE] ✨

X25519 is described in Section 6.1 of [CURVES], and X448 is described in Section 6.2 of [CURVES]. Conforming implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value, and abort if it is, as described in Section 6 of [CURVES]. If you use an alternative implementation of these elliptic curves instead of the one documented in Section 6 of [CURVES], then the additional checks in Section 7 of [CURVES] SHOULD be performed 🙈

In [CURVES], the shared secret that ECDH produces is called K. (Some other specs call it Z, so don't get confused 💀) A Key Derivation Function (KDF) uses that shared secret value (K), the length of the KEK, and the DER-encoded ECC-CMS-SharedInfo structure [CMSECC] to produce a pairwise key-encryption key (KEK) 💜

Here's the ECC-CMS-SharedInfo definition from [CMSECC], repeated for convenience:

ECC-CMS-SharedInfo ::= SEQUENCE {
  keyInfo         AlgorithmIdentifier,
  entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
  suppPubInfo [2] EXPLICIT OCTET STRING  }

The keyInfo field holds the object identifier of the key-encryption algorithm, plus any associated parameters. That algorithm is what wraps the content-encryption key. For example, the AES Key Wrap algorithm [AESKW] doesn't need parameters, so its algorithm identifier parameters are absent 🎀

The entityUInfo field optionally holds additional keying material from the sending agent. Heads up: [CMS] requires implementations to accept a KeyAgreeRecipientInfo SEQUENCE that includes the ukm field. If the ukm field is present, the ukm goes into the entityUInfo field. Including the ukm means a different KEK gets generated even if the originator ephemeral private key is improperly used more than once, which is huge 😭 So if the ukm field is present, it MUST be selected in a way that gives, with very high probability, a unique value. There's no security benefit to a ukm longer than the KEK the KDF will produce, though 🙈

The suppPubInfo field holds the length of the generated KEK, in bits, as a 32-bit number in network byte order. For example, the key length for AES-256 [AES] would be 0x00000100 🍓

2.1. ANSI-X9.63-KDF 🌸

The ANSI-X9.63-KDF is a simple construct built on a one-way hash function, and it's described in American National Standard X9.63 [X963]. It's also described in Section 3.6.1 of [SEC1] 🦋

Three values get concatenated to form the input string to the KDF:

  1. The shared secret value generated by ECDH, K.
  2. The iteration counter, starting with one, as described below.
  3. The DER-encoded ECC-CMS-SharedInfo structure.

To generate a key-encryption key (KEK), the KDF produces one or more keying material (KM) blocks. The counter starts at 0x00000001 and goes up by one for each subsequent KM block until there's enough material. The 32-bit counter is in network byte order. The KM blocks get concatenated left to right, and then the leftmost portion of the result becomes the pairwise key-encryption key, KEK 🧚

KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo))

KEK = KM(counter=1) || KM(counter=2) ...

2.2. HKDF 🌈

The Extract-and-Expand HMAC-based Key Derivation Function (HKDF) is a robust construct built on a one-way hash function, described in RFC 5869 [HKDF]. HKDF has two steps: HKDF-Extract, followed by HKDF-Expand 💖

Three values feed into the HKDF:

  1. The shared secret value generated by ECDH, K.
  2. The length in octets of the keying data to be generated.
  3. The DER-encoded ECC-CMS-SharedInfo structure.

The ECC-CMS-SharedInfo structure optionally includes the ukm. If the ukm is present, it's also used as the HKDF salt. When no salt is provided, HKDF uses an appropriate number of zero octets 👑

The generated KEK length shows up in two places, once in bits and once in octets. The ECC-CMS-SharedInfo structure includes the KEK length in bits, and the HKDF-Expand function takes the KEK length in octets as an argument 💅

Here's the summary for producing the pairwise key-encryption key, KEK:

if ukm is provided, then salt = ukm, else salt is not provided
PRK = HKDF-Extract(salt, K)

KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK))

3. Enveloped-data Conventions ✨

The CMS enveloped-data content type [CMS] holds encrypted content plus wrapped content-encryption keys for one or more recipients. ECDH key agreement generates a pairwise KEK between the originator and a particular recipient, and then that KEK wraps the content-encryption key for that recipient. If there's more than one recipient, the same content-encryption key MUST be wrapped for each of them 🫶

A compliant implementation MUST meet the requirements for constructing an enveloped-data content type in Section 6 of [CMS] 🔥

A content-encryption key MUST be randomly generated for each instance of an enveloped-data content type. That content-encryption key is what encrypts the content 🌈

That's part 1 of 3! Part 2 picks up with Section 3.1 (EnvelopedData Fields) and keeps going from there 🦋

3.1. EnvelopedData Fields 💖

okay so the enveloped-data content type gets ASN.1 encoded using the EnvelopedData syntax 🎀. The fields of that syntax MUST be populated the way Section 6 of [CMS] describes. The RecipientInfo choice is in Section 6.2 of [CMS], and I'm copying it here for convenience 💅

   RecipientInfo ::= CHOICE {
     ktri KeyTransRecipientInfo,
     kari [1] KeyAgreeRecipientInfo,
     kekri [2] KEKRecipientInfo,
     pwri [3] PasswordRecipientinfo,
     ori [4] OtherRecipientInfo }

for the recipients that use X25519 or X448, the RecipientInfo kari choice MUST be used 🫶

3.2. KeyAgreeRecipientInfo Fields 🦋

these fields MUST be populated as described in this section whenever X25519 or X448 is used for one or more recipients ✨

the KeyAgreeRecipientInfo version MUST be 3 🔢

the originator gets three options for showing its public key, and the originatorKey option MUST be used. originatorKey MUST contain an ephemeral key for the originator. the algorithm field inside it MUST contain the id-X25519 or id-X448 object identifier, and the originator's ephemeral public key MUST be encoded as an OCTET STRING 🌸

the object identifiers for X25519 and X448 were assigned in [RFC8410], and I'm repeating them here so you don't have to go hunting 🧚

for X25519, the public key is exactly 32 octets and you use the id-X25519 object identifier:

   id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 }

for X448, the public key is exactly 56 octets and you use the id-X448 object identifier:

   id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 }

KeyAgreeRecipientInfo ukm is optional 🙈 the ukm gets processed with the ANSI-X9.63-KDF key derivation function as described in Section 2.1, and with the HKDF key derivation function as described in Section 2.2 💜

the keyEncryptionAlgorithm MUST contain the object identifier of the key-encryption algorithm that will wrap the content-encryption key. the conventions for AES-128, AES-192, and AES-256 in key wrap mode are specified in [CMSAES] 🎀

the recipientEncryptedKeys field holds a recipient identifier and an encrypted key for one or more recipients 🍓 the RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either the issuerAndSerialNumber that identifies the recipient's certificate, or the RecipientKeyIdentifier containing the subject key identifier from the recipient's certificate. in both cases, that certificate holds the recipient's static X25519 or X448 public key. the RecipientEncryptedKey EncryptedKey MUST contain the content-encryption key, encrypted with the pairwise key-encryption key using the algorithm named by the KeyWrapAlgorithm 🔥

4. Authenticated-data Conventions 🔐

the CMS authenticated-data content type [CMS] is made up of authenticated content, a message authentication code (MAC), and encrypted authentication keys for one or more recipients 🧁 the ECDH key agreement algorithm generates a pairwise KEK between the originator and each particular recipient, and then that KEK wraps the authentication key for that recipient. when there's more than one recipient, the same authentication key MUST be wrapped for each of them 👑

a compliant implementation MUST meet the requirements for constructing an authenticated-data content type in Section 9 of [CMS] 💅

an authentication key MUST be randomly generated for each instance of an authenticated-data content type. that key is used to compute the MAC over the content 🫧

4.1. AuthenticatedData Fields 🌈

the authenticated-data content type is ASN.1 encoded using the AuthenticatedData syntax. the fields of that syntax MUST be populated as described in [CMS]. for the recipients that use X25519 or X448, the RecipientInfo kari choice MUST be used 💖

4.2. KeyAgreeRecipientInfo Fields ✨

the fields of the KeyAgreeRecipientInfo syntax MUST be populated as described in Section 3.2 of this document 🦋

5. Authenticated-enveloped-data Conventions 🎀

the CMS authenticated-enveloped-data content type [AUTHENV] is made up of authenticated and encrypted content, plus encrypted content-authenticated-encryption keys for one or more recipients 🍓 the ECDH key agreement algorithm generates a pairwise KEK between the originator and a particular recipient, and that KEK wraps the content-authenticated-encryption key for that recipient. when there's more than one recipient, the same content-authenticated-encryption key MUST be wrapped for each of them 🧚

a compliant implementation MUST meet the requirements for constructing an authenticated-data content type in Section 2 of [AUTHENV] 💅

a content-authenticated-encryption key MUST be randomly generated for each instance of an authenticated-enveloped-data content type. that key is used to authenticate and encrypt the content 🔥

5.1. AuthEnvelopedData Fields 🌸

the authenticated-enveloped-data content type is ASN.1 encoded using the AuthEnvelopedData syntax. the fields of that syntax MUST be populated as described in [AUTHENV]. for the recipients that use X25519 or X448, the RecipientInfo kari choice MUST be used 🫶

5.2. KeyAgreeRecipientInfo Fields 💜

the fields of the KeyAgreeRecipientInfo syntax MUST be populated as described in Section 3.2 of this document ✨

6. Certificate Conventions 📜

RFC 5280 [PROFILE] is the profile for using X.509 Certificates in Internet applications 🎀 a recipient's static public key is needed for X25519 or X448, and the originator gets that public key from the recipient's certificate 🦋 the conventions for carrying X25519 and X448 public keys are specified in [RFC8410] 💖

7. Key Agreement Algorithm Identifiers 🗝️

the following object identifiers were assigned in [CMSECC] to indicate ECDH with ANSI-X9.63-KDF using various one-way hash functions. they're expected to be used as AlgorithmIdentifiers with a parameter that specifies the key-encryption algorithm, and I'm repeating them here for convenience 🍓

   secg-scheme OBJECT IDENTIFIER ::= {
     iso(1) identified-organization(3) certicom(132) schemes(1) }

   dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
     secg-scheme 11 1 }

   dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {
     secg-scheme 11 2 }

   dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {
     secg-scheme 11 3 }

the following object identifiers are assigned to indicate ECDH with HKDF using various one-way hash functions. they're expected to be used as AlgorithmIdentifiers with a parameter that specifies the key-encryption algorithm 🧁

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

   dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
      smime-alg 19 }

   dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
      smime-alg 20 }

   dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
      smime-alg 21 }

8. SMIMECapabilities Attribute Conventions 📎

a sending agent MAY announce to other agents that it supports ECDH key agreement, using the SMIMECapabilities signed attribute in a signed message [SMIME] or in a certificate [CERTCAP]. following the pattern from [CMSECC], the SMIMECapabilities associated with ECDH carries a DER-encoded object identifier that identifies support for ECDH with a particular KDF, and it includes a parameter that names the key wrap algorithm 🌈

these SMIMECapabilities values (in hexadecimal) from [CMSECC] might be of interest to implementations that support X25519 and X448 🦋

   ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-128 key wrap:
      30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04
      01 05

   ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-128 key wrap:
      30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04
      01 05

   ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-128 key wrap:
      30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04
      01 05

   ECDH with ANSI-X9.63-KDF using SHA-256; uses AES-256 key wrap:
      30 15 06 06 2B 81 04 01 0B 01 30 0B 06 09 60 86 48 01 65 03 04
      01 2D

   ECDH with ANSI-X9.63-KDF using SHA-384; uses AES-256 key wrap:
      30 15 06 06 2B 81 04 01 0B 02 30 0B 06 09 60 86 48 01 65 03 04
      01 2D

   ECDH with ANSI-X9.63-KDF using SHA-512; uses AES-256 key wrap:
      30 15 06 06 2B 81 04 01 0B 03 30 0B 06 09 60 86 48 01 65 03 04
      01 2D

these SMIMECapabilities values (in hexadecimal), based on the algorithm identifiers in Section 7 of this document, might be of interest to implementations that support X25519 and X448 🍓

   ECDH with HKDF using SHA-256; uses AES-128 key wrap:
      30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 13 30 0B 06 09 60 86
      48 01 65 03 04 01 05

   ECDH with HKDF using SHA-384; uses AES-128 key wrap:
      30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 14 30 0B 06 09 60 86
      48 01 65 03 04 01 05

   ECDH with HKDF using SHA-512; uses AES-128 key wrap:
      30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 15 30 0B 06 09 60 86
      48 01 65 03 04 01 05

   ECDH with HKDF using SHA-256; uses AES-256 key wrap:
      30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 13 30 0B 06 09 60 86
      48 01 65 03 04 01 2D

   ECDH with HKDF using SHA-384; uses AES-256 key wrap:
      30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 14 30 0B 06 09 60 86
      48 01 65 03 04 01 2D

   ECDH with HKDF using SHA-512; uses AES-256 key wrap:
      30 1A 06 0B 2A 86 48 86 F7 0D 01 09 10 03 15 30 0B 06 09 60 86
      48 01 65 03 04 01 2D

9. Security Considerations 🚨

bestie, this part is serious, so read it carefully 😭

for security considerations about the enveloped-data and authenticated-data content types, please consult the security considerations of [CMS] 🔐

for security considerations about the authenticated-enveloped-data content type, please consult the security considerations of [AUTHENV] 🔐

for security considerations about using X25519 and X448, please consult the security considerations of [CURVES] 🔐

the originator uses an ephemeral public/private key pair that's generated on the same elliptic curve as the recipient's public key. that ephemeral key pair is used for a single CMS protected content type, and then it's discarded 🗑️ if the originator wants to be able to decrypt the content (for enveloped-data and authenticated-enveloped-data) or check the authentication (for authenticated-data), then the originator needs to treat themselves as a recipient 🪞

as specified in [CMS], implementations MUST support processing of the KeyAgreeRecipientInfo ukm field. this makes sure interoperability isn't a concern whether the ukm is present or absent 🫶 the ukm is placed in the entityUInfo field of the ECC-CMS-SharedInfo structure. when it's present, the ukm makes sure a different key-encryption key gets generated, even if the originator's ephemeral private key is improperly used more than once 💀

10. IANA Considerations ✨

okay bestie, time for the IANA stuff 🦋 one object identifier for the ASN.1 module in Appendix A got assigned in the "SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0)" registry on [IANA-SMI]:

   id-mod-cms-ecdh-alg-2017 OBJECT IDENTIFIER ::= {
      iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) mod(0) 67 }

three object identifiers for the Key Agreement Algorithm Identifiers in Section 7 also got assigned, in the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)" registry on [IANA-SMI] 💜

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

   dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
      smime-alg 19 }

   dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
      smime-alg 20 }

   dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
      smime-alg 21 }

11. References 🌸

11.1. Normative References

These are the big must-reads, the ones everything else leans on 🫶

11.2. Informative References

These ones are more like extra reading for the curious 🧚

  • [AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001.
  • [AESKW] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, <https://www.rfc-editor.org/info/rfc3394>.
  • [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, <https://www.rfc-editor.org/info/rfc3565>.
  • [DH1976] Diffie, W., and M. E. Hellman, "New Directions in Cryptography", IEEE Trans. on Info. Theory, Vol. IT-22, November 1976, pp. 644-654.
  • [IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers (MIB Module Registrations)", <https://www.iana.org/assignments/smi-numbers>.
  • [X963] American National Standards Institute, "Public-Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography", American National Standard X9.63-2001, November 2001.

Appendix A. ASN.1 Module 💅

this is the whole ASN.1 module, all the way through, no edits 🔥

   CMSECDHAlgs-2017
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
       smime(16) modules(0) id-mod-cms-ecdh-alg-2017(67) }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   -- EXPORTS ALL

   IMPORTS

     KeyWrapAlgorithm
       FROM CryptographicMessageSyntaxAlgorithms-2009  -- in [CMSASN1]
         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
           pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) }

     KEY-AGREE, SMIME-CAPS
       FROM AlgorithmInformation-2009  -- in [CMSASN1]
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-algorithmInformation-02(58) }

     dhSinglePass-stdDH-sha256kdf-scheme,
     dhSinglePass-stdDH-sha384kdf-scheme,
     dhSinglePass-stdDH-sha512kdf-scheme,
     kaa-dhSinglePass-stdDH-sha256kdf-scheme,
     kaa-dhSinglePass-stdDH-sha384kdf-scheme,
     kaa-dhSinglePass-stdDH-sha512kdf-scheme,
     cap-kaa-dhSinglePass-stdDH-sha256kdf-scheme,
     cap-kaa-dhSinglePass-stdDH-sha384kdf-scheme,
     cap-kaa-dhSinglePass-stdDH-sha512kdf-scheme
       FROM CMSECCAlgs-2009-02  -- in [CMSECC]
         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
           pkcs-9(9) smime(16) modules(0)
           id-mod-cms-ecc-alg-2009-02(46) }
     ;

   --
   -- Object Identifiers
   --

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

   dhSinglePass-stdDH-hkdf-sha256-scheme OBJECT IDENTIFIER ::= {
      smime-alg 19 }

   dhSinglePass-stdDH-hkdf-sha384-scheme OBJECT IDENTIFIER ::= {
      smime-alg 20 }

   dhSinglePass-stdDH-hkdf-sha512-scheme OBJECT IDENTIFIER ::= {
      smime-alg 21 }

   --
   -- Extend the Key Agreement Algorithms in [CMSECC]
   --

   KeyAgreementAlgs KEY-AGREE ::= { ...,
     kaa-dhSinglePass-stdDH-sha256kdf-scheme   |
     kaa-dhSinglePass-stdDH-sha384kdf-scheme   |
     kaa-dhSinglePass-stdDH-sha512kdf-scheme   |
     kaa-dhSinglePass-stdDH-hkdf-sha256-scheme |
     kaa-dhSinglePass-stdDH-hkdf-sha384-scheme |
     kaa-dhSinglePass-stdDH-hkdf-sha512-scheme }

   kaa-dhSinglePass-stdDH-hkdf-sha256-scheme KEY-AGREE ::= {
     IDENTIFIER dhSinglePass-stdDH-hkdf-sha256-scheme
     PARAMS TYPE KeyWrapAlgorithm ARE required
     UKM -- TYPE unencoded data -- ARE preferredPresent
     SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme }

   kaa-dhSinglePass-stdDH-hkdf-sha384-scheme KEY-AGREE ::= {
     IDENTIFIER dhSinglePass-stdDH-hkdf-sha384-scheme
     PARAMS TYPE KeyWrapAlgorithm ARE required
     UKM -- TYPE unencoded data -- ARE preferredPresent
     SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme }

   kaa-dhSinglePass-stdDH-hkdf-sha512-scheme KEY-AGREE ::= {
     IDENTIFIER dhSinglePass-stdDH-hkdf-sha512-scheme
     PARAMS TYPE KeyWrapAlgorithm ARE required
     UKM -- TYPE unencoded data -- ARE preferredPresent
     SMIME-CAPS cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme }

   --
   -- Extend the S/MIME CAPS in [CMSECC]
   --

   SMimeCAPS SMIME-CAPS ::= { ...,
     kaa-dhSinglePass-stdDH-sha256kdf-scheme.&smimeCaps   |
     kaa-dhSinglePass-stdDH-sha384kdf-scheme.&smimeCaps   |
     kaa-dhSinglePass-stdDH-sha512kdf-scheme.&smimeCaps   |
     kaa-dhSinglePass-stdDH-hkdf-sha256-scheme.&smimeCaps |
     kaa-dhSinglePass-stdDH-hkdf-sha384-scheme.&smimeCaps |
     kaa-dhSinglePass-stdDH-hkdf-sha512-scheme.&smimeCaps }

   cap-kaa-dhSinglePass-stdDH-hkdf-sha256-scheme SMIME-CAPS ::= {
     TYPE KeyWrapAlgorithm
     IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha256-scheme }

   cap-kaa-dhSinglePass-stdDH-hkdf-sha384-scheme SMIME-CAPS ::= {
     TYPE KeyWrapAlgorithm
     IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha384-scheme}

   cap-kaa-dhSinglePass-stdDH-hkdf-sha512-scheme SMIME-CAPS ::= {
     TYPE KeyWrapAlgorithm
     IDENTIFIED BY dhSinglePass-stdDH-hkdf-sha512-scheme }

   END

Acknowledgements 🫶

huge thank you to Roni Even, Daniel Migault, Eric Rescorla, Jim Schaad, Stefan Santesson, and Sean Turner for reviewing and giving such insightful suggestions 💖

Author's Address 🎀

   Russ Housley
   918 Spring Knoll Drive
   Herndon, VA  20170
   United States of America

   Email: housley@vigilsec.com

that's the whole thing, bestie!! 🌈✨

📦 where this page comes from