# drafts

name: draft-ietf-hpke-hpke
rev: 03
title: Hybrid Public Key Encryption
time: 2026-03-02T23:41:46Z
group_uri: /api/v1/group/group/2448/
expires: 2026-09-03T23:41:46Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.880433+00:00
source: ietf
abstract:
  This document describes a scheme for hybrid public key encryption
     (HPKE).  This scheme provides a variant of public key encryption of
     arbitrary-sized plaintexts for a recipient public key.  It also
     includes a variant that authenticates possession of a pre-shared key.
     HPKE works for any combination of an asymmetric Key Encapsulation
     Mechanism (KEM), key derivation function (KDF), and authenticated
     encryption with additional data (AEAD) encryption function.  We
     provide instantiations of the scheme using widely used and efficient
     primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key
     agreement, HMAC-based key derivation function (HKDF), and SHA2.

full_text:
  HPKE                                                           R. Barnes
  Internet-Draft                                                     Cisco
  Obsoletes: 9180 (if approved)                               K. Bhargavan
  Intended status: Standards Track                                 B. Lipp
  Expires: 8 May 2026                                                Inria
                                                                   C. Wood
                                                           4 November 2025


                        Hybrid Public Key Encryption
                          draft-ietf-hpke-hpke-02

  Abstract

     This document describes a scheme for hybrid public key encryption
     (HPKE).  This scheme provides a variant of public key encryption of
     arbitrary-sized plaintexts for a recipient public key.  It also
     includes a variant that authenticates possession of a pre-shared key.
     HPKE works for any combination of an asymmetric KEM, key derivation
     function (KDF), and authenticated encryption with additional data
     (AEAD) encryption function.  We provide instantiations of the scheme
     using widely used and efficient primitives, such as Elliptic Curve
     Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation
     function (HKDF), and SHA2.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Source for this draft and an issue tracker can be found at
     https://github.com/hpkewg/hpke.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 8 May 2026.



  Barnes, et al.             Expires 8 May 2026                   [Page 1]


  Internet-Draft                    HPKE                     November 2025


  Copyright Notice

     Copyright (c) 2025 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, as 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 are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   4
     3.  Notation  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Cryptographic Dependencies  . . . . . . . . . . . . . . . . .   5
       4.1.  DH-Based KEM (DHKEM)  . . . . . . . . . . . . . . . . . .   9
     5.  Hybrid Public Key Encryption  . . . . . . . . . . . . . . . .  11
       5.1.  Creating the Encryption Context . . . . . . . . . . . . .  12
         5.1.1.  Encryption to a Public Key  . . . . . . . . . . . . .  15
         5.1.2.  Authentication Using a Pre-Shared Key . . . . . . . .  16
       5.2.  Encryption and Decryption . . . . . . . . . . . . . . . .  16
       5.3.  Secret Export . . . . . . . . . . . . . . . . . . . . . .  18
     6.  Single-Shot APIs  . . . . . . . . . . . . . . . . . . . . . .  19
       6.1.  Encryption and Decryption . . . . . . . . . . . . . . . .  19
       6.2.  Secret Export . . . . . . . . . . . . . . . . . . . . . .  20
     7.  Algorithm Identifiers . . . . . . . . . . . . . . . . . . . .  20
       7.1.  Key Encapsulation Mechanisms (KEMs) . . . . . . . . . . .  20
         7.1.1.  SerializePublicKey and DeserializePublicKey . . . . .  21
         7.1.2.  SerializePrivateKey and DeserializePrivateKey . . . .  21
         7.1.3.  DeriveKeyPair . . . . . . . . . . . . . . . . . . . .  22
         7.1.4.  Validation of Inputs and Outputs  . . . . . . . . . .  24
         7.1.5.  Future KEMs . . . . . . . . . . . . . . . . . . . . .  24
       7.2.  Key Derivation Functions (KDFs) . . . . . . . . . . . . .  25
         7.2.1.  Input Length Restrictions . . . . . . . . . . . . . .  25
       7.3.  Authenticated Encryption with Associated Data (AEAD)
             Functions . . . . . . . . . . . . . . . . . . . . . . . .  27
     8.  API Considerations  . . . . . . . . . . . . . . . . . . . . .  27
       8.1.  Auxiliary Authenticated Application Information . . . . .  27
       8.2.  Errors  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  29
       9.1.  Security Properties . . . . . . . . . . . . . . . . . . .  29
         9.1.1.  Computational Analysis  . . . . . . . . . . . . . . .  30
         9.1.2.  Post-Quantum Security . . . . . . . . . . . . . . . .  31



  Barnes, et al.             Expires 8 May 2026                   [Page 2]


  Internet-Draft                    HPKE                     November 2025


       9.2.  Security Requirements on a KEM Used within HPKE . . . . .  31
         9.2.1.  Encap/Decap Interface . . . . . . . . . . . . . . . .  32
         9.2.2.  KEM Key Reuse . . . . . . . . . . . . . . . . . . . .  32
       9.3.  Security Requirements on a KDF  . . . . . . . . . . . . .  32
       9.4.  Security Requirements on an AEAD  . . . . . . . . . . . .  32
       9.5.  Pre-Shared Key Recommendations  . . . . . . . . . . . . .  32
       9.6.  Domain Separation . . . . . . . . . . . . . . . . . . . .  33
       9.7.  Application Embedding and Non-Goals . . . . . . . . . . .  34
         9.7.1.  Message Order and Message Loss  . . . . . . . . . . .  34
         9.7.2.  Downgrade Prevention  . . . . . . . . . . . . . . . .  35
         9.7.3.  Replay Protection . . . . . . . . . . . . . . . . . .  35
         9.7.4.  Forward Secrecy . . . . . . . . . . . . . . . . . . .  36
         9.7.5.  Bad Ephemeral Randomness  . . . . . . . . . . . . . .  37
         9.7.6.  Hiding Plaintext Length . . . . . . . . . . . . . . .  37
       9.8.  Bidirectional Encryption  . . . . . . . . . . . . . . . .  37
       9.9.  Metadata Protection . . . . . . . . . . . . . . . . . . .  38
     10. Message Encoding  . . . . . . . . . . . . . . . . . . . . . .  38
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  39
       11.1.  KEM Identifiers  . . . . . . . . . . . . . . . . . . . .  39
       11.2.  KDF Identifiers  . . . . . . . . . . . . . . . . . . . .  40
       11.3.  AEAD Identifiers . . . . . . . . . . . . . . . . . . . .  40
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  41
       12.1.  Normative References . . . . . . . . . . . . . . . . . .  41
       12.2.  Informative References . . . . . . . . . . . . . . . . .  41
     Appendix A.  Differences from RFC 9180  . . . . . . . . . . . . .  45
     Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .  45
     Appendix C.  Test Vectors . . . . . . . . . . . . . . . . . . . .  46
       C.1.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM  . .  46
         C.1.1.  Base Setup Information  . . . . . . . . . . . . . . .  46
         C.1.2.  PSK Setup Information . . . . . . . . . . . . . . . .  49
       C.2.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256,
             ChaCha20Poly1305  . . . . . . . . . . . . . . . . . . . .  52
         C.2.1.  Base Setup Information  . . . . . . . . . . . . . . .  52
         C.2.2.  PSK Setup Information . . . . . . . . . . . . . . . .  55
       C.3.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, AES-128-GCM . . .  58
         C.3.1.  Base Setup Information  . . . . . . . . . . . . . . .  58
         C.3.2.  PSK Setup Information . . . . . . . . . . . . . . . .  61
       C.4.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA512, AES-128-GCM . . .  64
         C.4.1.  Base Setup Information  . . . . . . . . . . . . . . .  64
         C.4.2.  PSK Setup Information . . . . . . . . . . . . . . . .  67
       C.5.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA256,
             ChaCha20Poly1305  . . . . . . . . . . . . . . . . . . . .  70
         C.5.1.  Base Setup Information  . . . . . . . . . . . . . . .  70
         C.5.2.  PSK Setup Information . . . . . . . . . . . . . . . .  73
       C.6.  DHKEM(P-521, HKDF-SHA512), HKDF-SHA512, AES-256-GCM . . .  76
         C.6.1.  Base Setup Information  . . . . . . . . . . . . . . .  76
         C.6.2.  PSK Setup Information . . . . . . . . . . . . . . . .  79




  Barnes, et al.             Expires 8 May 2026                   [Page 3]


  Internet-Draft                    HPKE                     November 2025


       C.7.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, Export-Only
             AEAD  . . . . . . . . . . . . . . . . . . . . . . . . . .  82
         C.7.1.  Base Setup Information  . . . . . . . . . . . . . . .  82
         C.7.2.  PSK Setup Information . . . . . . . . . . . . . . . .  84
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  85

  1.  Introduction

     Encryption schemes that combine asymmetric and symmetric algorithms
     have been specified and practiced since the early days of public key
     cryptography, e.g., [RFC1421].  Combining the two yields the key
     management advantages of asymmetric cryptography and the performance
     benefits of symmetric cryptography.  The traditional combination has
     been "encrypt the symmetric key with the public key."  "Hybrid"
     public key encryption (HPKE) schemes, specified here, take a
     different approach: "generate the symmetric key and its encapsulation
     with the public key."  Specifically, encrypted messages convey a
     shared secret encapsulated with a public key scheme, along with one
     or more arbitrary-sized ciphertexts encrypted using that key.  This
     type of public key encryption has many applications in practice,
     including Messaging Layer Security [RFC9420], TLS Encrypted
     ClientHello [I-D.ietf-tls-esni], and Oblivious HTTP [RFC9458].

     Currently, there are numerous competing and non-interoperable
     standards and variants for hybrid encryption, mostly variants on the
     Elliptic Curve Integrated Encryption Scheme (ECIES), including ANSI
     X9.63 (ECIES) [ANSI], IEEE 1363a [IEEE1363], ISO/IEC 18033-2 [ISO],
     and SECG SEC 1 [SECG].  See [MAEA10] for a thorough comparison.  All
     these existing schemes have problems, e.g., because they rely on
     outdated primitives, lack proofs of indistinguishable (adaptive)
     chosen-ciphertext attack (IND-CCA2) security, or fail to provide test
     vectors.

     This document defines an HPKE scheme that provides a subset of the
     functions provided by the collection of schemes above but specified
     with sufficient clarity that they can be interoperably implemented.
     The HPKE construction defined herein is secure against (adaptive)
     chosen ciphertext attacks (IND-CCA2-secure) under classical
     assumptions about the underlying primitives [HPKEAnalysis]
     [ABHKLR20].  A summary of these analyses is in Section 9.1.

  2.  Requirements Notation

     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.



  Barnes, et al.             Expires 8 May 2026                   [Page 4]


  Internet-Draft                    HPKE                     November 2025


  3.  Notation

     The following terms are used throughout this document to describe the
     operations, roles, and behaviors of HPKE:

     *  (skX, pkX): A key encapsulation mechanism (KEM) key pair used in
        role X, where X is one of S, R, or E as sender, recipient, and
        ephemeral, respectively; skX is the private key and pkX is the
        public key.

     *  pk(skX): The KEM public key corresponding to the KEM private key
        skX.

     *  Sender (S): Role of entity that sends an encrypted message.

     *  Recipient (R): Role of entity that receives an encrypted message.

     *  Ephemeral (E): Role of a fresh random value meant for one-time
        use.

     *  I2OSP(n, w): Convert non-negative integer n to a w-length, big-
        endian byte string, as described in [RFC8017].

     *  OS2IP(x): Convert byte string x to a non-negative integer, as
        described in [RFC8017], assuming big-endian byte order.

     *  concat(x0, ..., xN): Concatenation of byte strings. concat(0x01,
        0x0203, 0x040506) = 0x010203040506.

     *  lengthPrefixed(x): The two-byte length of the byte string x,
        concatenated with x itself.  (lengthPrefixed(x) =
        concat(I2OSP(len(x), 2), x)) It is an error to call this function
        with an x value that is more than 65535 bytes long.

     *  random(n): A pseudorandom byte string of length n bytes

     *  xor(a,b): XOR of byte strings; xor(0xF0F0, 0x1234) = 0xE2C4.  It
        is an error to call this function with two arguments of unequal
        length.

  4.  Cryptographic Dependencies

     HPKE variants rely on the following primitives:

     *  A key encapsulation mechanism (KEM):

        -  GenerateKeyPair(): Randomized algorithm to generate a key pair
           (skX, pkX).



  Barnes, et al.             Expires 8 May 2026                   [Page 5]


  Internet-Draft                    HPKE                     November 2025


        -  DeriveKeyPair(ikm): Deterministic algorithm to derive a key
           pair (skX, pkX) from the byte string ikm, where ikm is an
           arbitrary-length byte string (within the bounds in Table 4).
           The ikm input SHOULD have at least Nsk bytes of entropy.

        -  SerializePublicKey(pkX): Produce a byte string of length Npk
           encoding the public key pkX.

        -  DeserializePublicKey(pkXm): Parse a byte string of length Npk
           to recover a public key.  This function can raise a
           DeserializeError error upon pkXm deserialization failure.

        -  Encap(pkR): Randomized algorithm to generate an ephemeral,
           fixed-length shared secret and a fixed-length encapsulation of
           that secret (also known as the KEM ciphertext) that can be
           decapsulated by the holder of the private key corresponding to
           pkR.  This function can raise an EncapError on encapsulation
           failure.

        -  Decap(enc, skR): Deterministic algorithm using the private key
           skR to recover the shared secret) from the encapsulated secret
           enc.  This function can raise a DecapError on decapsulation
           failure.

        -  Nsecret: The length in bytes of a KEM shared secret produced by
           this KEM.

        -  Nenc: The length in bytes of an encapsulated secret produced by
           this KEM.

        -  Npk: The length in bytes of an encoded public key for this KEM.

        -  Nsk: The length in bytes of an encoded private key for this
           KEM.

     *  A key derivation function (KDF) of one of the two following forms:

        -  A one-stage KDF:

           o  Derive(ikm, L): Derive an L-byte value from the input keying
              material ikm.

           o  Nh The security strength of the KDF, in bytes.

        -  A two-stage KDF:






  Barnes, et al.             Expires 8 May 2026                   [Page 6]


  Internet-Draft                    HPKE                     November 2025


           o  Extract(salt, ikm): Extract a pseudorandom key of fixed
              length Nh bytes from input keying material ikm and an
              optional byte string salt.

           o  Expand(prk, info, L): Expand a pseudorandom key prk using
              optional string info into L bytes of output keying material.

           o  Nh: The output size of the Extract() function in bytes.

     *  An AEAD encryption algorithm [RFC5116]:

        -  Seal(key, nonce, aad, pt): Encrypt and authenticate plaintext
           pt with associated data aad using symmetric key key and nonce
           nonce, yielding ciphertext and tag ct.  This function can raise
           a MessageLimitReachedError upon failure.

        -  Open(key, nonce, aad, ct): Decrypt ciphertext and tag ct using
           associated data aad with symmetric key key and nonce nonce,
           returning plaintext message pt.  This function can raise an
           OpenError or MessageLimitReachedError upon failure.

        -  Nk: The length in bytes of a key for this algorithm.

        -  Nn: The length in bytes of a nonce for this algorithm.

        -  Nt: The length in bytes of the authentication tag for this
           algorithm.

     Beyond the above, a KEM MAY also expose the following functions,
     whose behavior is detailed in Section 7.1.2:

     *  SerializePrivateKey(skX): Produce a byte string of length Nsk
        encoding the private key skX.

     *  DeserializePrivateKey(skXm): Parse a byte string of length Nsk to
        recover a private key.  This function can raise a DeserializeError
        error upon skXm deserialization failure.

     A _ciphersuite_ is a triple (KEM, KDF, AEAD) containing a choice of
     algorithm for each primitive.

     A set of algorithm identifiers for concrete instantiations of these
     primitives is provided in Section 7.  Algorithm identifier values are
     two bytes long.







  Barnes, et al.             Expires 8 May 2026                   [Page 7]


  Internet-Draft                    HPKE                     November 2025


     The notation pk(skX), depending on its use and the KEM and its
     implementation, is either the computation of the public key using the
     private key, or just syntax expressing the retrieval of the public
     key, assuming it is stored along with the private key object.

     The following functions are defined to facilitate domain separation
     of KDF calls as well as context binding:

     # For use with one-stage KDFs
     def LabeledDerive(ikm, label, context, L):
       labeled_ikm = concat(
         ikm,
         "HPKE-v1",
         suite_id,
         lengthPrefixed(label),
         I2OSP(L, 2)
         context,
       )
       return Derive(labeled_ikm, L)

     # For use with two-stage KDFs
     def LabeledExtract(salt, label, ikm):
       labeled_ikm = concat("HPKE-v1", suite_id, label, ikm)
       return Extract(salt, labeled_ikm)

     def LabeledExpand(prk, label, info, L):
       labeled_info = concat(I2OSP(L, 2), "HPKE-v1", suite_id,
                             label, info)
       return Expand(prk, labeled_info, L)

     The value of suite_id depends on where the KDF is used; it is assumed
     implicit from the implementation and not passed as a parameter.  If
     used inside a KEM algorithm, suite_id MUST start with "KEM" and
     identify this KEM algorithm; if used in the remainder of HPKE, it
     MUST start with "HPKE" and identify the entire ciphersuite in use.
     See sections Section 4.1 and Section 5.1 for details.

     Certain functions have a different structure depending on whether a
     one-stage or two-stage KDF is being used.  For clarity, such
     functions will be described twice in this document, once with the
     suffix _OneStage and once with the suffix _TwoStage, representing the
     versions of the function to be used with a one-stage or two-stage
     KDF, respectively.  For example, the Foo function would be invoked by
     calling Foo_OneStage when using a one-stage KDF, and by calling
     Foo_TwoStage when using a two-stage KDF.






  Barnes, et al.             Expires 8 May 2026                   [Page 8]


  Internet-Draft                    HPKE                     November 2025


  4.1.  DH-Based KEM (DHKEM)

     Suppose we are given a KDF, and a Diffie-Hellman (DH) group providing
     the following operations:

     *  DH(skX, pkY): Perform a non-interactive Diffie-Hellman exchange
        using the private key skX and public key pkY to produce a Diffie-
        Hellman shared secret of length Ndh. This function can raise a
        ValidationError as described in Section 7.1.4.

     *  Ndh: The length in bytes of a Diffie-Hellman shared secret
        produced by DH().

     *  Nsk: The length in bytes of a Diffie-Hellman private key.

     Then we can construct a KEM that implements the interface defined in
     Section 4 called DHKEM(Group, KDF) in the following way, where Group
     denotes the Diffie-Hellman group and KDF denotes the KDF.  The
     function parameters pkR and pkS are deserialized public keys, and enc
     is a serialized public key.  Since encapsulated shared secrets are
     Diffie-Hellman public keys in this KEM algorithm, we use
     SerializePublicKey() and DeserializePublicKey() to encode and decode
     them, respectively.  Npk equals Nenc.  GenerateKeyPair() produces a
     key pair for the Diffie-Hellman group in use.  Section 7.1.3 contains
     the DeriveKeyPair() function specification for DHKEMs defined in this
     document.

























  Barnes, et al.             Expires 8 May 2026                   [Page 9]


  Internet-Draft                    HPKE                     November 2025


     # For use with one-stage KDFs
     def ExtractAndExpand_OneStage(dh, kem_context):
       return LabeledDerive(dh, "shared_secret", kem_context, Nsecret)

     # For use with two-stage KDFs
     def ExtractAndExpand_TwoStage(dh, kem_context):
       eae_prk = LabeledExtract("", "eae_prk", dh)
       shared_secret = LabeledExpand(eae_prk, "shared_secret",
                                     kem_context, Nsecret)
       return shared_secret

     def Encap(pkR):
       skE, pkE = GenerateKeyPair()
       dh = DH(skE, pkR)
       enc = SerializePublicKey(pkE)

       pkRm = SerializePublicKey(pkR)
       kem_context = concat(enc, pkRm)

       shared_secret = ExtractAndExpand(dh, kem_context)
       return shared_secret, enc

     def Decap(enc, skR):
       pkE = DeserializePublicKey(enc)
       dh = DH(skR, pkE)

       pkRm = SerializePublicKey(pk(skR))
       kem_context = concat(enc, pkRm)

       shared_secret = ExtractAndExpand(dh, kem_context)
       return shared_secret

     The implicit suite_id value used within LabeledExtract,
     LabeledExpand, and LabeledDerive is defined as follows, where kem_id
     is defined in Section 7.1:

     suite_id = concat("KEM", I2OSP(kem_id, 2))

     The KDF used in DHKEM can be equal to or different from the KDF used
     in the remainder of HPKE, depending on the chosen variant.
     Implementations MUST make sure to use the constants (Nh) and function
     calls (LabeledExtract, LabeledExpand, and LabeledDerive) of the
     appropriate KDF when implementing DHKEM.  See Section 9.3 for a
     comment on the choice of a KDF for the remainder of HPKE, and
     Section 9.6 for the rationale of the labels.






  Barnes, et al.             Expires 8 May 2026                  [Page 10]


  Internet-Draft                    HPKE                     November 2025


     For the variants of DHKEM defined in this document, the size Nsecret
     of the KEM shared secret is equal to the output length of the hash
     function underlying the KDF.  For P-256, P-384, and P-521, the size
     Ndh of the Diffie-Hellman shared secret is equal to 32, 48, and 66,
     respectively, corresponding to the x-coordinate of the resulting
     elliptic curve point [IEEE1363].  For X25519 and X448, the size Ndh
     is equal to 32 and 56, respectively (see [RFC7748], Section 5).

     Senders and recipients MUST validate KEM inputs and outputs as
     described in Section 7.1.

  5.  Hybrid Public Key Encryption

     In this section, we define a few HPKE variants.  All variants take a
     recipient public key and a sequence of plaintexts pt and produce an
     encapsulated secret enc and a sequence of ciphertexts ct.  These
     outputs are constructed so that only the holder of skR can
     decapsulate the key from enc and decrypt the ciphertexts.  All the
     algorithms also take an info parameter that can be used to influence
     the generation of keys (e.g., to fold in identity information) and an
     aad parameter that provides additional authenticated data to the AEAD
     algorithm in use.

     In addition to the base case of encrypting to a public key, we
     include a variant that authenticates possession of a pre-shared key.
     The authenticated variant contributes additional keying material to
     the encryption operation.  The following one-byte values will be used
     to distinguish between modes:

                             +===========+=======+
                             | Mode      | Value |
                             +===========+=======+
                             | mode_base | 0x00  |
                             +-----------+-------+
                             | mode_psk  | 0x01  |
                             +-----------+-------+
                             | RESERVED  | 0x02  |
                             +-----------+-------+
                             | RESERVED  | 0x03  |
                             +-----------+-------+

                              Table 1: HPKE Modes

     (The values 0x02 and 0x03 were used in [RFC9180] to reflect
     additional variants which have been removed from this specification.)

     Both variants follow the same basic two-step pattern:




  Barnes, et al.             Expires 8 May 2026                  [Page 11]


  Internet-Draft                    HPKE                     November 2025


     1.  Set up an encryption context that is shared between the sender
         and the recipient.

     2.  Use that context to encrypt or decrypt content.

     A _context_ is an implementation-specific structure that encodes the
     AEAD algorithm and key in use, and manages the nonces used so that
     the same nonce is not used with multiple plaintexts.  It also has an
     interface for exporting secret values, as described in Section 5.3.
     See Section 5.2 for a description of this structure and its
     interfaces.  HPKE decryption fails when the underlying AEAD
     decryption fails.

     The constructions described here presume that the relevant non-
     private parameters (enc, psk_id, etc.) are transported between the
     sender and the recipient by some application making use of HPKE.
     Moreover, a recipient with more than one public key needs some way of
     determining which of its public keys was used for the encapsulation
     operation.  As an example, applications may send this information
     alongside a ciphertext from the sender to the recipient.
     Specification of such a mechanism is left to the application.  See
     Section 10 for more details.

     The procedures described in this section are laid out in a Python-
     like pseudocode.  The algorithms in use are left implicit.

  5.1.  Creating the Encryption Context

     The variants of HPKE defined in this document share a common key
     schedule that translates the protocol inputs into an encryption
     context.  The key schedule inputs are as follows:

     *  mode - A one-byte value indicating the HPKE mode, defined in
        Table 1.

     *  shared_secret - A KEM shared secret generated for this
        transaction.

     *  info - Application-supplied information (optional; default value
        "").

     *  psk - A pre-shared key (PSK) held by both the sender and the
        recipient (optional; default value "").

     *  psk_id - An identifier for the PSK (optional; default value "").

     Senders and recipients MUST validate KEM inputs and outputs as
     described in Section 7.1.



  Barnes, et al.             Expires 8 May 2026                  [Page 12]


  Internet-Draft                    HPKE                     November 2025


     The info parameter used by HPKE is not related to the optional string
     info used by the LabeledExpand() or Expand() functions detailed in
     Section 4.

     The psk and psk_id parameters MUST appear together or not at all.
     That is, if a non-default value is provided for one of them, then the
     other MUST be set to a non-default value.  This requirement is
     encoded in VerifyPSKInputs() below.

     The psk, psk_id, and info parameters have maximum lengths that depend
     on the KDF itself, on the definition of LabeledExtract(), and on the
     constant labels used together with them.  See Section 7.2.1 for
     precise limits on these lengths.

     The key, base_nonce, and exporter_secret computed by the key schedule
     have the property that they are only known to the holder of the
     recipient private key, and the entity that used the KEM to generate
     shared_secret and enc.

     The HPKE algorithm identifiers, i.e., the KEM kem_id, KDF kdf_id, and
     AEAD aead_id 2-byte code points, as defined in Table 2, Table 3, and
     Table 5, respectively, are assumed implicit from the implementation
     and not passed as parameters.  The implicit suite_id value used
     within LabeledExtract, LabeledExpand, and LabeledDerive is defined
     based on them as follows:

     suite_id = concat(
       "HPKE",
       I2OSP(kem_id, 2),
       I2OSP(kdf_id, 2),
       I2OSP(aead_id, 2)
     )

     default_psk = ""
     default_psk_id = ""

     def VerifyPSKInputs(mode, psk, psk_id):
       got_psk = (psk != default_psk)
       got_psk_id = (psk_id != default_psk_id)
       if got_psk != got_psk_id:
         raise Exception("Inconsistent PSK inputs")

       if got_psk and mode == mode_base:
         raise Exception("PSK input provided when not needed")
       if (not got_psk) and mode == mode_psk:
         raise Exception("Missing required PSK input")

     # For use with a one-stage KDF



  Barnes, et al.             Expires 8 May 2026                  [Page 13]


  Internet-Draft                    HPKE                     November 2025


     def CombineSecrets_OneStage(mode, shared_secret, info, psk, psk_id):
       secrets = concat(
         lengthPrefixed(psk),
         lengthPrefixed(shared_secret),
       )
       context = concat(
         mode,
         lengthPrefixed(psk_id),
         lengthPrefixed(info),
       )

       secret = LabeledDerive(secrets, "secret", context, Nk + Nn + Nh)

       key = secret[:Nk]
       base_nonce = secret[Nk:(Nk + Nn)]
       exporter_secret = secret[(Nk + Nn):]

       return (key, base_nonce, exporter_secret)

     # For use with a two-stage KDF
     def CombineSecrets_TwoStage(mode, shared_secret, info, psk, psk_id):
       psk_id_hash = LabeledExtract("", "psk_id_hash", psk_id)
       info_hash = LabeledExtract("", "info_hash", info)
       key_schedule_context = concat(mode, psk_id_hash, info_hash)

       secret = LabeledExtract(shared_secret, "secret", psk)

       key = LabeledExpand(secret, "key", key_schedule_context, Nk)
       base_nonce = LabeledExpand(secret, "base_nonce",
                                  key_schedule_context, Nn)
       exporter_secret = LabeledExpand(secret, "exp",
                                       key_schedule_context, Nh)

       return (key, base_nonce, exporter_secret)

     def KeySchedule<ROLE>(mode, shared_secret, info, psk, psk_id):
       VerifyPSKInputs(mode, psk, psk_id)

       key, base_nonce, exporter_secret =
         CombineSecrets(mode, shared_secret, info, psk, psk_id)

       return Context<ROLE>(key, base_nonce, 0, exporter_secret)









  Barnes, et al.             Expires 8 May 2026                  [Page 14]


  Internet-Draft                    HPKE                     November 2025


     The ROLE template parameter is either S or R, depending on the role
     of sender or recipient, respectively.  The third parameter in the
     Context<ROLE> refers to the sequence number, that is initialised with
     a 0 value.  See Section 5.2 for a discussion of the key schedule
     output, including the role-specific Context structure and its API,
     and the usage of the sequence number.

     Note that the key_schedule_context construction in KeySchedule() is
     equivalent to serializing a structure of the following form in the
     TLS presentation syntax:

     struct {
         uint8 mode;
         opaque psk_id_hash[Nh];
         opaque info_hash[Nh];
     } KeyScheduleContext;

  5.1.1.  Encryption to a Public Key

     The most basic function of an HPKE scheme is to enable encryption to
     the holder of a given KEM private key.  The SetupBaseS() and
     SetupBaseR() procedures establish contexts that can be used to
     encrypt and decrypt, respectively, for a given private key.

     The KEM shared secret is combined via the KDF with information
     describing the key exchange, as well as the explicit info parameter
     provided by the caller.

     The parameter pkR is a public key, and enc is an encapsulated KEM
     shared secret.

     def SetupBaseS(pkR, info):
       shared_secret, enc = Encap(pkR)
       return enc, KeyScheduleS(mode_base, shared_secret, info,
                                default_psk, default_psk_id)

     def SetupBaseR(enc, skR, info):
       shared_secret = Decap(enc, skR)
       return KeyScheduleR(mode_base, shared_secret, info,
                           default_psk, default_psk_id)











  Barnes, et al.             Expires 8 May 2026                  [Page 15]


  Internet-Draft                    HPKE                     November 2025


  5.1.2.  Authentication Using a Pre-Shared Key

     This variant extends the base mechanism by allowing the recipient to
     authenticate that the sender possessed a given PSK.  The PSK also
     improves confidentiality guarantees in certain adversary models, as
     described in more detail in Section 9.1.  We assume that both parties
     have been provisioned with both the PSK value psk and another byte
     string psk_id that is used to identify which PSK should be used.

     The primary difference from the base case is that the psk and psk_id
     values are used as ikm inputs to the KDF (instead of using the empty
     string).

     The PSK MUST have at least 32 bytes of entropy and SHOULD be of
     length Nh bytes or longer.  See Section 9.5 for a more detailed
     discussion.

    def SetupPSKS(pkR, info, psk, psk_id):
      shared_secret, enc = Encap(pkR)
      return enc, KeyScheduleS(mode_psk, shared_secret, info, psk, psk_id)

    def SetupPSKR(enc, skR, info, psk, psk_id):
      shared_secret = Decap(enc, skR)
      return KeyScheduleR(mode_psk, shared_secret, info, psk, psk_id)

  5.2.  Encryption and Decryption

     HPKE allows multiple encryption operations to be done based on a
     given setup transaction.  Since the public key operations involved in
     setup are typically more expensive than symmetric encryption or
     decryption, this allows applications to amortize the cost of the
     public key operations, reducing the overall overhead.

     In order to avoid nonce reuse, however, this encryption must be
     stateful.  Each of the setup procedures above produces a role-
     specific context object that stores the AEAD and secret export
     parameters.  The AEAD parameters consist of:

     *  The AEAD algorithm in use

     *  A secret key

     *  A base nonce base_nonce

     *  A sequence number (initially 0)

     The secret export parameters consist of:




  Barnes, et al.             Expires 8 May 2026                  [Page 16]


  Internet-Draft                    HPKE                     November 2025


     *  The HPKE ciphersuite in use and

     *  An exporter_secret used for the secret export interface (see
        Section 5.3)

     All these parameters except the AEAD sequence number are constant.
     The sequence number provides nonce uniqueness: The nonce used for
     each encryption or decryption operation is the result of XORing
     base_nonce with the current sequence number, encoded as a big-endian
     integer of the same length as base_nonce.  Implementations MAY use a
     sequence number that is shorter than the nonce length (padding on the
     left with zero), but MUST raise an error if the sequence number
     overflows.  The AEAD algorithm produces ciphertext that is Nt bytes
     longer than the plaintext.  Nt = 16 for AEAD algorithms defined in
     this document.

     Encryption is unidirectional from sender to recipient.  The sender's
     context can encrypt a plaintext pt with associated data aad as
     follows:

     def ContextS.Seal(aad, pt):
       ct = Seal(self.key, self.ComputeNonce(self.seq), aad, pt)
       self.IncrementSeq()
       return ct

     The recipient's context can decrypt a ciphertext ct with associated
     data aad as follows:

     def ContextR.Open(aad, ct):
       pt = Open(self.key, self.ComputeNonce(self.seq), aad, ct)
       if pt == OpenError:
         raise OpenError
       self.IncrementSeq()
       return pt

     Each encryption or decryption operation increments the sequence
     number for the context in use.  The per-message nonce and sequence
     number increment details are as follows:

     def Context<ROLE>.ComputeNonce(seq):
       seq_bytes = I2OSP(seq, Nn)
       return xor(self.base_nonce, seq_bytes)

     def Context<ROLE>.IncrementSeq():
       if self.seq >= (1 << (8*Nn)) - 1:
         raise MessageLimitReachedError
       self.seq += 1




  Barnes, et al.             Expires 8 May 2026                  [Page 17]


  Internet-Draft                    HPKE                     November 2025


     The sender's context MUST NOT be used for decryption.  Similarly, the
     recipient's context MUST NOT be used for encryption.  Higher-level
     protocols reusing the HPKE key exchange for more general purposes can
     derive separate keying material as needed using use the secret export
     interface; see Section 5.3 and Section 9.8 for more details.

     It is up to the application to ensure that encryptions and
     decryptions are done in the proper sequence, so that encryption and
     decryption nonces align.  If ContextS.Seal() or ContextR.Open() would
     cause the seq parameter to overflow, then the implementation MUST
     fail with an error.  (In the pseudocode above,
     Context<ROLE>.IncrementSeq() fails with an error when seq overflows,
     which causes ContextS.Seal() and ContextR.Open() to fail
     accordingly.)  Note that the internal Seal() and Open() calls inside
     correspond to the context's AEAD algorithm.

  5.3.  Secret Export

     HPKE provides an interface for exporting secrets from the encryption
     context using a variable-length pseudorandom function (PRF).  This
     interface takes as input a context string exporter_context and a
     desired length L in bytes, and produces a secret derived from the
     internal exporter secret using the corresponding KDF Expand function.
     For the KDFs defined in this specification, L has a maximum value of
     255*Nh.  Future specifications that define new KDFs MUST specify a
     bound for L.

     The exporter_context parameter has a maximum length that depends on
     the KDF itself, on the definition of LabeledExpand(), and on the
     constant labels used together with them.  See Section 7.2.1 for
     precise limits on this length.

     # For use with a one-stage KDF
     def Context.Export_OneStage(exporter_context, L):
       return LabeledDerive(self.exporter_secret, "sec",
                            exporter_context, L)

     # For use with a two-stage KDF
     def Context.Export_TwoStage(exporter_context, L):
       return LabeledExpand(self.exporter_secret, "sec",
                            exporter_context, L)

     Applications that do not use the encryption API in Section 5.2 can
     use the export-only AEAD ID 0xFFFF when computing the key schedule.
     Such applications can avoid computing the key and base_nonce values
     in the key schedule, as they are not used by the Export interface
     described above.




  Barnes, et al.             Expires 8 May 2026                  [Page 18]


  Internet-Draft                    HPKE                     November 2025


     Unlike the similar TLS 1.3 exporter interface (see Section 7.5 of
     [RFC8446]), the HPKE export interface does not provide replay
     protection.  While the resulting secret will only be known to the
     sender and recipient, a replayed encapsulated secret enc will produce
     an identical context, and thus the same exported secrets.  In
     particular, applications MUST NOT use exported secrets unless it is
     safe for the same exported values to be used multiple times.  For
     example, applications MUST NOT use an exported secret to derive a
     (key, nonce) pair for AEAD encryption (as suggested in Section 9.8 of
     [RFC9180]), since reuse of a (key, nonce) pair harms security in most
     AEAD algorithms.  In such cases, applications SHOULD incorporate a
     fresh recipient-provided nonce when deriving values from an export
     context, as discussed in Section 4.4 of [RFC9458] and Section 9.8.

  6.  Single-Shot APIs

  6.1.  Encryption and Decryption

     In many cases, applications encrypt only a single message to a
     recipient's public key.  This section provides templates for HPKE
     APIs that implement stateless "single-shot" encryption and decryption
     using APIs specified in Section 5.1 and Section 5.2:

     def Seal<MODE>(pkR, info, aad, pt, ...):
       enc, ctx = Setup<MODE>S(pkR, info, ...)
       ct = ctx.Seal(aad, pt)
       return enc, ct

     def Open<MODE>(enc, skR, info, aad, ct, ...):
       ctx = Setup<MODE>R(enc, skR, info, ...)
       return ctx.Open(aad, ct)

     The MODE template parameter is either Base or PSK.  The optional
     parameters indicated by "..." depend on MODE and may be empty.  For
     example, SetupBase() has no additional parameters.  SealPSK() and
     OpenPSK() would be implemented as follows:

     def SealPSK(pkR, info, aad, pt, psk, psk_id):
       enc, ctx = SetupPSKS(pkR, info, psk, psk_id)
       ct = ctx.Seal(aad, pt)
       return enc, ct

     def OpenPSK(enc, skR, info, aad, ct, psk, psk_id):
       ctx = SetupPSKR(enc, skR, info, psk, psk_id)
       return ctx.Open(aad, ct)






  Barnes, et al.             Expires 8 May 2026                  [Page 19]


  Internet-Draft                    HPKE                     November 2025


  6.2.  Secret Export

     Applications may also want to derive a secret known only to a given
     recipient.  This section provides templates for HPKE APIs that
     implement stateless "single-shot" secret export using APIs specified
     in Section 5.3:

     def SendExport<MODE>(pkR, info, exporter_context, L, ...):
       enc, ctx = Setup<MODE>S(pkR, info, ...)
       exported = ctx.Export(exporter_context, L)
       return enc, exported

     def ReceiveExport<MODE>(enc, skR, info, exporter_context, L, ...):
       ctx = Setup<MODE>R(enc, skR, info, ...)
       return ctx.Export(exporter_context, L)

     As in Section 6.1, the MODE template parameter is either Base or PSK.
     The optional parameters indicated by "..." depend on MODE and may be
     empty.

     Secrets exported using this single-shot API face the same replay
     risks discussed in Section 5.3.  Usage of exported secrets needs to
     be limited as described in that section.

  7.  Algorithm Identifiers

     This section lists algorithm identifiers suitable for different HPKE
     configurations.  Future specifications may introduce new KEM, KDF,
     and AEAD algorithm identifiers and retain the security guarantees
     presented in this document provided they adhere to the security
     requirements in Section 9.2, Section 9.3, and Section 9.4,
     respectively.

  7.1.  Key Encapsulation Mechanisms (KEMs)

     +======+===============+=========+====+===+===+====+===============+
     |Value | KEM           | Nsecret |Nenc|Npk|Nsk|Auth| Reference     |
     +======+===============+=========+====+===+===+====+===============+
     |0x0000| Reserved      | N/A     |N/A |N/A|N/A|yes | RFC 9180      |
     +------+---------------+---------+----+---+---+----+---------------+
     |0x0010| DHKEM(P-256,  | 32      |65  |65 |32 |yes | [NISTCurves], |
     |      | HKDF-SHA256)  |         |    |   |   |    | [RFC5869]     |
     +------+---------------+---------+----+---+---+----+---------------+
     |0x0011| DHKEM(P-384,  | 48      |97  |97 |48 |yes | [NISTCurves], |
     |      | HKDF-SHA384)  |         |    |   |   |    | [RFC5869]     |
     +------+---------------+---------+----+---+---+----+---------------+
     |0x0012| DHKEM(P-521,  | 64      |133 |133|66 |yes | [NISTCurves], |
     |      | HKDF-SHA512)  |         |    |   |   |    | [RFC5869]     |



  Barnes, et al.             Expires 8 May 2026                  [Page 20]


  Internet-Draft                    HPKE                     November 2025


     +------+---------------+---------+----+---+---+----+---------------+
     |0x0020| DHKEM(X25519, | 32      |32  |32 |32 |yes | [RFC7748],    |
     |      | HKDF-SHA256)  |         |    |   |   |    | [RFC5869]     |
     +------+---------------+---------+----+---+---+----+---------------+
     |0x0021| DHKEM(X448,   | 64      |56  |56 |56 |yes | [RFC7748],    |
     |      | HKDF-SHA512)  |         |    |   |   |    | [RFC5869]     |
     +------+---------------+---------+----+---+---+----+---------------+

                               Table 2: KEM IDs

     The Auth column indicates if the KEM algorithm provides the
     AuthEncap()/AuthDecap() interface defined in [RFC9180].

  7.1.1.  SerializePublicKey and DeserializePublicKey

     For P-256, P-384, and P-521, the SerializePublicKey() function of the
     KEM performs the uncompressed Elliptic-Curve-Point-to-Octet-String
     conversion according to [SECG].  DeserializePublicKey() performs the
     uncompressed Octet-String-to-Elliptic-Curve-Point conversion.

     For X25519 and X448, the SerializePublicKey() and
     DeserializePublicKey() functions are the identity function, since
     these curves already use fixed-length byte strings for public keys.

     Some deserialized public keys MUST be validated before they can be
     used.  See Section 7.1.4 for specifics.

  7.1.2.  SerializePrivateKey and DeserializePrivateKey

     As per [SECG], P-256, P-384, and P-521 private keys are field
     elements in the scalar field of the curve being used.  For this
     section, and for Section 7.1.3, it is assumed that implementors of
     ECDH over these curves use an integer representation of private keys
     that is compatible with the OS2IP() function.

     For P-256, P-384, and P-521, the SerializePrivateKey() function of
     the KEM performs the Field-Element-to-Octet-String conversion
     according to [SECG].  If the private key is an integer outside the
     range [0, order-1], where order is the order of the curve being used,
     the private key MUST be reduced to its representative in [0, order-1]
     before being serialized.  DeserializePrivateKey() performs the Octet-
     String-to-Field-Element conversion according to [SECG].









  Barnes, et al.             Expires 8 May 2026                  [Page 21]


  Internet-Draft                    HPKE                     November 2025


     For X25519 and X448, private keys are identical to their byte string
     representation, so little processing has to be done.  The
     SerializePrivateKey() function MUST clamp its output and the
     DeserializePrivateKey() function MUST clamp its input, where
     _clamping_ refers to the bitwise operations performed on k in the
     decodeScalar25519() and decodeScalar448() functions defined in
     Section 5 of [RFC7748].

     To catch invalid keys early on, implementors of DHKEMs SHOULD check
     that deserialized private keys are not equivalent to 0 (mod order),
     where order is the order of the DH group.  Note that this property is
     trivially true for X25519 and X448 groups, since clamped values can
     never be 0 (mod order).

  7.1.3.  DeriveKeyPair

     The keys that DeriveKeyPair() produces have only as much entropy as
     the provided input keying material.  For a given KEM, the ikm
     parameter given to DeriveKeyPair() SHOULD have length at least Nsk,
     and SHOULD have at least Nsk bytes of entropy.

     All invocations of KDF functions (such as LabeledExtract or
     LabeledExpand) in any DHKEM's DeriveKeyPair() function use the
     DHKEM's associated KDF (as opposed to the ciphersuite's KDF).

     For P-256, P-384, and P-521, the DeriveKeyPair() function of the KEM
     performs rejection sampling over field elements:
























  Barnes, et al.             Expires 8 May 2026                  [Page 22]


  Internet-Draft                    HPKE                     November 2025


     # For use with a one-stage KDF
     def DeriveCandidate_OneStage(ikm, counter):
       return LabeledDerive(ikm, "candidate", I2OSP(counter, 1), Nsk)

     # For use with a two-stage KDF
     def DeriveCandidate_TwoStage(ikm, counter):
       # Note: dkp_prk may be derived once and cached
       dkp_prk = LabeledExtract("", "dkp_prk", ikm)
       return LabeledExpand(dkp_prk, "candidate",
                               I2OSP(counter, 1), Nsk)

     def DeriveKeyPair(ikm):
       sk = 0
       counter = 0
       while sk == 0 or sk >= order:
         if counter > 255:
           raise DeriveKeyPairError
         bytes = DeriveCandidate(ikm, counter)
         bytes[0] = bytes[0] & bitmask
         sk = OS2IP(bytes)
         counter = counter + 1
       return (sk, pk(sk))

     order is the order of the curve being used (see Section D.1.2 of
     [NISTCurves]), and is listed below for completeness.

     P-256:
     0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551

     P-384:
     0xffffffffffffffffffffffffffffffffffffffffffffffffc7634d81f4372ddf
       581a0db248b0a77aecec196accc52973

     P-521:
     0x01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
       fa51868783bf2f966b7fcc0148f709a5d03bb5c9b8899c47aebb6fb71e91386409

     bitmask is defined to be 0xFF for P-256 and P-384, and 0x01 for
     P-521.  The precise likelihood of DeriveKeyPair() failing with
     DeriveKeyPairError depends on the group being used, but it is
     negligibly small in all cases.  See Section 8.2 for information about
     dealing with such failures.

     For X25519 and X448, the DeriveKeyPair() function applies a KDF to
     the input:






  Barnes, et al.             Expires 8 May 2026                  [Page 23]


  Internet-Draft                    HPKE                     November 2025


     # For use with a one-stage KDF
     def DeriveKeyPair_OneStage(ikm):
       sk = LabeledDerive(ikm, "sk", "", Nsk)
       return (sk, pk(sk))

     # For use with a two-stage KDF
     def DeriveKeyPair_TwoStage(ikm):
       dkp_prk = LabeledExtract("", "dkp_prk", ikm)
       sk = LabeledExpand(dkp_prk, "sk", "", Nsk)
       return (sk, pk(sk))

     The suite_id used implicitly in LabeledExtract() and LabeledExpand()
     for DeriveKeyPair(ikm) is derived from the KEM identifier of the
     DHKEM in use (see Section 7.1), that is, based on the type of key
     pair been generated for that DHKEM type.

     For all of the above instances of DHKEM, the GenerateKeyPair can be
     implemented as DeriveKeyPair(random(Nsk)).

  7.1.4.  Validation of Inputs and Outputs

     The following public keys are subject to validation if the group
     requires public key validation: the sender MUST validate the
     recipient's public key pkR; the recipient MUST validate the ephemeral
     public key pkE.  Validation failure yields a ValidationError.

     For P-256, P-384 and P-521, senders and recipients MUST perform
     partial public key validation on all public key inputs, as defined in
     Section 5.6.2.3.4 of [keyagreement].  This includes checking that the
     coordinates are in the correct range, that the point is on the curve,
     and that the point is not the point at infinity.  Additionally,
     senders and recipients MUST ensure the Diffie-Hellman shared secret
     is not the point at infinity.

     For X25519 and X448, public keys and Diffie-Hellman outputs MUST be
     validated as described in [RFC7748].  In particular, recipients MUST
     check whether the Diffie-Hellman shared secret is the all-zero value
     and abort if so.

  7.1.5.  Future KEMs

     Section 9.2 lists security requirements on a KEM used within HPKE.

     A KEM algorithm may support different encoding algorithms, with
     different output lengths, for KEM public keys.  Such KEM algorithms
     MUST specify only one encoding algorithm whose output length is Npk.





  Barnes, et al.             Expires 8 May 2026                  [Page 24]


  Internet-Draft                    HPKE                     November 2025


  7.2.  Key Derivation Functions (KDFs)

            +========+=============+=====+===========+===========+
            | Value  | KDF         | Nh  | Two-Stage | Reference |
            +========+=============+=====+===========+===========+
            | 0x0000 | Reserved    | N/A | N/A       | RFC 9180  |
            +--------+-------------+-----+-----------+-----------+
            | 0x0001 | HKDF-SHA256 | 32  | Y         | [RFC5869] |
            +--------+-------------+-----+-----------+-----------+
            | 0x0002 | HKDF-SHA384 | 48  | Y         | [RFC5869] |
            +--------+-------------+-----+-----------+-----------+
            | 0x0003 | HKDF-SHA512 | 64  | Y         | [RFC5869] |
            +--------+-------------+-----+-----------+-----------+

                               Table 3: KDF IDs

  7.2.1.  Input Length Restrictions

     For one-stage KDFs, there is length limit of 65,535 bytes for the
     psk, psk_id, info fields.  This limitation arises because these
     fields are all prefixed with a two-byte length when being used as KDF
     inputs.  There is no inherent length limitation on exporter_context.
     If a one-stage KDF has an input length limit, then implementations
     MUST limit the length of exporter_context accordingly, so that the
     LabeledDerive call in Context.Export does not overflow the input
     length limit.

     For two-stage KDFs, this document defines LabeledExtract() and
     LabeledExpand() based on the KDFs listed above.  These functions add
     prefixes to their respective inputs ikm and info before calling the
     KDF's Extract() and Expand() functions.  This leads to a reduction of
     the maximum input length that is available for the inputs psk,
     psk_id, info, exporter_context, ikm, i.e., the variable-length
     parameters provided by HPKE applications.  The following table lists
     the maximum allowed lengths of these parameters for the KDFs defined
     in this document, as inclusive bounds in bytes:















  Barnes, et al.             Expires 8 May 2026                  [Page 25]


  Internet-Draft                    HPKE                     November 2025


      +==================+==============+===============+===============+
      | Input            | HKDF-SHA256  | HKDF-SHA384   | HKDF-SHA512   |
      +==================+==============+===============+===============+
      | psk              | 2^{61} - 88  | 2^{125} - 152 | 2^{125} - 152 |
      +------------------+--------------+---------------+---------------+
      | psk_id           | 2^{61} - 93  | 2^{125} - 157 | 2^{125} - 157 |
      +------------------+--------------+---------------+---------------+
      | info             | 2^{61} - 91  | 2^{125} - 155 | 2^{125} - 155 |
      +------------------+--------------+---------------+---------------+
      | exporter_context | 2^{61} - 120 | 2^{125} - 200 | 2^{125} - 216 |
      +------------------+--------------+---------------+---------------+
      | ikm              | 2^{61} - 84  | 2^{125} - 148 | 2^{125} - 148 |
      | (DeriveKeyPair)  |              |               |               |
      +------------------+--------------+---------------+---------------+

                       Table 4: Application Input Limits

     This shows that the limits are only marginally smaller than the
     maximum input length of the underlying hash function; these limits
     are large and unlikely to be reached in practical applications.
     Future specifications that define new KDFs MUST specify bounds for
     these variable-length parameters.

     Since the above bounds are larger than any values used in practice,
     it may be useful for implementations to impose a lower limit on the
     values they will accept (for example, to avoid dynamic allocations).
     Implementations SHOULD set such a limit to be no less than maximum
     Nsk size for a KEM supported by the implementation.  For an
     implementation that supports all of the KEMs in this document, the
     limit would be 66 bytes, which is the Nsk value for DHKEM(P-521,
     HKDF-SHA512).

     The values for psk, psk_id, info, and ikm, which are inputs to
     LabeledExtract(), were computed with the following expression:

     max_size_hash_input - Nb - size_version_label -
         size_suite_id - size_input_label

     The value for exporter_context, which is an input to LabeledExpand(),
     was computed with the following expression:

     max_size_hash_input - Nb - Nh - size_version_label -
         size_suite_id - size_input_label - 2 - 1

     In these equations, max_size_hash_input is the maximum input length
     of the underlying hash function in bytes, Nb is the block size of the
     underlying hash function in bytes, size_version_label is the size of
     "HPKE-v1" in bytes and equals 7, size_suite_id is the size of the



  Barnes, et al.             Expires 8 May 2026                  [Page 26]


  Internet-Draft                    HPKE                     November 2025


     suite_id in bytes and equals 5 for DHKEM (relevant for ikm) and 10
     for the remainder of HPKE (relevant for psk, psk_id, info, and
     exporter_context), and size_input_label is the size in bytes of the
     label used as parameter to LabeledExtract() or LabeledExpand(), the
     maximum of which is 13 across all labels in this document.

  7.3.  Authenticated Encryption with Associated Data (AEAD) Functions

          +========+==================+=====+=====+=====+===========+
          | Value  | AEAD             | Nk  | Nn  | Nt  | Reference |
          +========+==================+=====+=====+=====+===========+
          | 0x0000 | Reserved         | N/A | N/A | N/A | RFC 9180  |
          +--------+------------------+-----+-----+-----+-----------+
          | 0x0001 | AES-128-GCM      | 16  | 12  | 16  | [GCM]     |
          +--------+------------------+-----+-----+-----+-----------+
          | 0x0002 | AES-256-GCM      | 32  | 12  | 16  | [GCM]     |
          +--------+------------------+-----+-----+-----+-----------+
          | 0x0003 | ChaCha20Poly1305 | 32  | 12  | 16  | [RFC8439] |
          +--------+------------------+-----+-----+-----+-----------+
          | 0xFFFF | Export-only      | N/A | N/A | N/A | RFC 9180  |
          +--------+------------------+-----+-----+-----+-----------+

                               Table 5: AEAD IDs

     The 0xFFFF AEAD ID is reserved for applications that only use the
     Export interface; see Section 5.3 for more details.

  8.  API Considerations

     This section documents considerations for interfaces to
     implementations of HPKE.  This includes error handling considerations
     and recommendations that improve interoperability when HPKE is used
     in applications.

  8.1.  Auxiliary Authenticated Application Information

     HPKE has two places at which applications can specify auxiliary
     authenticated information: (1) during context construction via the
     Setup info parameter, and (2) during Context operations, i.e., with
     the aad parameter for Open() and Seal(), and the exporter_context
     parameter for Export().  Application information applicable to
     multiple operations on a single Context should use the Setup info
     parameter.  This avoids redundantly processing this information for
     each Context operation.  In contrast, application information that
     varies on a per-message basis should be specified via the Context
     APIs (Seal(), Open(), or Export()).





  Barnes, et al.             Expires 8 May 2026                  [Page 27]


  Internet-Draft                    HPKE                     November 2025


     Applications that only use the single-shot APIs described in
     Section 6 should use the Setup info parameter for specifying
     auxiliary authenticated information.  Implementations which only
     expose single-shot APIs should not allow applications to use both
     Setup info and Context aad or exporter_context auxiliary information
     parameters.

  8.2.  Errors

     The high-level, public HPKE APIs specified in this document are all
     fallible.  These include the Setup functions and all encryption
     context functions.  For example, Decap() can fail if the encapsulated
     secret enc is invalid, and Open() may fail if ciphertext decryption
     fails.  The explicit errors generated throughout this specification,
     along with the conditions that lead to each error, are as follows:

     *  ValidationError: KEM input or output validation failure;
        Section 4.1.

     *  DeserializeError: Public or private key deserialization failure;
        Section 4.

     *  EncapError: Encap() failure; Section 4.

     *  DecapError: Decap() failure; Section 4.

     *  OpenError: Context AEAD Open() failure; Section 4 and Section 5.2.

     *  MessageLimitReachedError: Context AEAD sequence number overflow;
        Section 4 and Section 5.2.

     *  DeriveKeyPairError: Key pair derivation failure; Section 7.1.3.

     Implicit errors may also occur.  As an example, certain classes of
     failures, e.g., malformed recipient public keys, may not yield
     explicit errors.  For example, for the DHKEM variant described in
     this specification, the Encap() algorithm fails when given an invalid
     recipient public key.  However, other KEM algorithms may not have an
     efficient algorithm for verifying the validity of public keys.  As a
     result, an equivalent error may not manifest until AEAD decryption at
     the recipient.

     The errors in this document are meant as a guide for implementors.
     They are not an exhaustive list of all the errors an implementation
     might emit.  For example, future KEMs might have internal failure
     cases, or an implementation might run out of memory.





  Barnes, et al.             Expires 8 May 2026                  [Page 28]


  Internet-Draft                    HPKE                     November 2025


     How these errors are expressed in an API or handled by applications
     is an implementation-specific detail.  For example, some
     implementations may abort or panic upon a DeriveKeyPairError failure
     given that it only occurs with negligible probability, whereas other
     implementations may retry the failed DeriveKeyPair operation.  See
     Section 7.1.3 for more information.  As another example, some
     implementations of the DHKEM specified in this document may choose to
     transform ValidationError from DH() into an EncapError or DecapError
     from Encap() or Decap(), respectively, whereas others may choose to
     raise ValidationError unmodified.

     Applications using HPKE APIs should not assume that the errors here
     are complete, nor should they assume certain classes of errors will
     always manifest the same way for all ciphersuites.  For example, the
     DHKEM specified in this document will emit a DeserializationError or
     ValidationError if a KEM public key is invalid.  However, a new KEM
     might not have an efficient algorithm for determining whether or not
     a public key is valid.  In this case, an invalid public key might
     instead yield an OpenError when trying to decrypt a ciphertext.

  9.  Security Considerations

  9.1.  Security Properties

     HPKE has several security goals, depending on the mode of operation,
     against active and adaptive attackers that can compromise partial
     secrets of senders and recipients.  The desired security goals are
     detailed below:

     *  Message secrecy: Confidentiality of the sender's messages against
        chosen ciphertext attacks

     *  Export key secrecy: Indistinguishability of each export secret
        from a uniformly random bitstring of equal length, i.e.,
        Context.Export is a variable-length PRF

     *  Sender authentication: Proof of sender origin for the PSK mode

     These security goals are expected to hold for any honest sender and
     honest recipient keys, as well as if the honest sender and honest
     recipient keys are the same.

     HPKE mitigates malleability problems (called benign malleability
     [SECG]) in prior public key encryption standards based on ECIES by
     including all public keys in the context of the key schedule.






  Barnes, et al.             Expires 8 May 2026                  [Page 29]


  Internet-Draft                    HPKE                     November 2025


     HPKE does not provide forward secrecy with respect to recipient
     compromise.  In the Base mode, the secrecy properties are only
     expected to hold if the recipient private key skR is not compromised
     at any point in time.  In the PSK mode, the secrecy properties are
     expected to hold if the recipient private key skR and the pre-shared
     key are not both compromised at any point in time.  See Section 9.7
     for more details.

     Besides forward secrecy and key-compromise impersonation, which are
     highlighted in this section because of their particular cryptographic
     importance, HPKE has other non-goals that are described in
     Section 9.7: no tolerance of message reordering or loss, no downgrade
     or replay prevention, no hiding of the plaintext length, and no
     protection against bad ephemeral randomness.  Section 9.7 suggests
     application-level mitigations for some of them.

  9.1.1.  Computational Analysis

     It is shown in [CS01] that a hybrid public key encryption scheme of
     essentially the same form as the Base mode described here is IND-
     CCA2-secure as long as the underlying KEM and AEAD schemes are IND-
     CCA2-secure.  Moreover, it is shown in [HHK06] that IND-CCA2 security
     of the KEM and the data encapsulation mechanism are necessary
     conditions to achieve IND-CCA2 security for hybrid public key
     encryption.  The main difference between the scheme proposed in
     [CS01] and the Base mode in this document (both named HPKE) is that
     we interpose some KDF calls between the KEM and the AEAD.  Analyzing
     the HPKE Base mode instantiation in this document therefore requires
     verifying that the additional KDF calls do not cause the IND-CCA2
     property to fail, as well as verifying the additional export key
     secrecy property.

     A preliminary computational analysis of all HPKE modes has been done
     in [HPKEAnalysis], indicating asymptotic security for the case where
     the KEM is DHKEM, the AEAD is any IND-CPA-secure and INT-CTXT-secure
     scheme, and the DH group and KDF satisfy the following conditions:

     *  DH group: The gap Diffie-Hellman (GDH) problem is hard in the
        appropriate subgroup [GAP].

     *  Extract() and Expand(): Extract() can be modeled as a random
        oracle.  Expand() can be modeled as a pseudorandom function,
        wherein the first argument is the key.

     In particular, the KDFs and DH groups defined in this document (see
     Section 7.2 and Section 7.1) satisfy these properties when used as
     specified.  The analysis in [HPKEAnalysis] demonstrates that under
     these constraints, HPKE continues to provide IND-CCA2 security, and



  Barnes, et al.             Expires 8 May 2026                  [Page 30]


  Internet-Draft                    HPKE                     November 2025


     provides the additional properties noted above.  Also, the analysis
     confirms the expected properties hold under the different key
     compromise cases mentioned above.  The analysis considers a sender
     that sends one message using the encryption context, and additionally
     exports two independent secrets using the secret export interface.

     The table below summarizes the main results from [HPKEAnalysis].  N/A
     means that a property does not apply for the given mode, whereas Y
     means the given mode satisfies the property.

            +=========+==============+=============+==============+
            | Variant | Message Sec. | Export Sec. | Sender Auth. |
            +=========+==============+=============+==============+
            | Base    |      Y       |      Y      |     N/A      |
            +---------+--------------+-------------+--------------+
            | PSK     |      Y       |      Y      |      Y       |
            +---------+--------------+-------------+--------------+

                                    Table 6

     If non-DH-based KEMs are to be used with HPKE, further analysis will
     be necessary to prove their security.  The results from [CS01]
     provide some indication that any IND-CCA2-secure KEM will suffice
     here, but are not conclusive given the differences in the schemes.

  9.1.2.  Post-Quantum Security

     All of [CS01], [HPKEAnalysis], and [ABHKLR20] are premised on
     classical security models and assumptions, and do not consider
     adversaries capable of quantum computation.  A full proof of post-
     quantum security would need to take appropriate security models and
     assumptions into account, in addition to simply using a post-quantum
     KEM.

     In future work, the analysis from [ABHKLR20] can be extended to cover
     HPKE's other modes and desired security properties.  The hybrid
     quantum-resistance property described above, which is achieved by
     using the PSK mode, is not proven in [HPKEAnalysis] because this
     analysis requires the random oracle model; in a quantum setting, this
     model needs adaption to, for example, the quantum random oracle
     model.

  9.2.  Security Requirements on a KEM Used within HPKE

     A KEM used within HPKE MUST allow HPKE to satisfy its desired
     security properties described in Section 9.1.  Section 9.6 lists
     requirements concerning domain separation.




  Barnes, et al.             Expires 8 May 2026                  [Page 31]


  Internet-Draft                    HPKE                     November 2025


     In particular, the KEM shared secret MUST be a uniformly random byte
     string of length Nsecret.  This means, for instance, that it would
     not be sufficient if the KEM shared secret is only uniformly random
     as an element of some set prior to its encoding as a byte string.

  9.2.1.  Encap/Decap Interface

     As mentioned in Section 9, [CS01] provides some indications that if
     the KEM's Encap()/Decap() interface (which is used in the Base and
     PSK modes) is IND-CCA2-secure, HPKE is able to satisfy its desired
     security properties.  An appropriate definition of IND-CCA2 security
     for KEMs can be found in [CS01] and [BHK09].

  9.2.2.  KEM Key Reuse

     An ikm input to DeriveKeyPair() (Section 7.1.3) MUST NOT be reused
     elsewhere, in particular not with DeriveKeyPair() of a different KEM.

     Since a KEM key pair belonging to a sender or recipient works with
     all modes, it can be used with multiple modes in parallel.  HPKE is
     constructed to be secure in such settings due to domain separation
     using the suite_id variable.  However, there is no formal proof of
     security at the time of writing for using multiple modes in parallel;
     [HPKEAnalysis] and [ABHKLR20] only analyze isolated modes.

  9.3.  Security Requirements on a KDF

     The choice of the KDF for HPKE SHOULD be made based on the security
     level provided by the KEM and, if applicable, by the PSK.  The KDF
     SHOULD at least have the security level of the KEM and SHOULD at
     least have the security level provided by the PSK.

  9.4.  Security Requirements on an AEAD

     All AEADs MUST be IND-CCA2-secure, as is currently true for all AEADs
     listed in Section 7.3.

  9.5.  Pre-Shared Key Recommendations

     In the PSK modes, the PSK MUST have at least 32 bytes of entropy and
     SHOULD be of length Nh bytes or longer.  Using a PSK longer than 32
     bytes but shorter than Nh bytes is permitted.

     HPKE is specified to use HKDF as its key derivation function.  HKDF
     is not designed to slow down dictionary attacks (see [RFC5869]).
     Thus, HPKE's PSK mechanism is not suitable for use with a low-entropy
     password as the PSK: In scenarios in which the adversary knows the
     KEM shared secret shared_secret and has access to an oracle that



  Barnes, et al.             Expires 8 May 2026                  [Page 32]


  Internet-Draft                    HPKE                     November 2025


     distinguishes between a good and a wrong PSK, it can perform PSK-
     recovering attacks.  This oracle can be the decryption operation on a
     captured HPKE ciphertext or any other recipient behavior that is
     observably different when using a wrong PSK.  The adversary knows the
     KEM shared secret shared_secret if it knows all KEM private keys of
     one participant.  In the PSK mode, this is trivially the case if the
     adversary acts as the sender.

     To recover a lower entropy PSK, an attacker in this scenario can
     trivially perform a dictionary attack.  Given a set S of possible PSK
     values, the attacker generates an HPKE ciphertext for each value in
     S, and submits the resulting ciphertexts to the oracle to learn which
     PSK is being used by the recipient.  Further, because HPKE uses AEAD
     schemes that are not key-committing, an attacker can mount a
     partitioning oracle attack [LGR20] that can recover the PSK from a
     set of S possible PSK values, with |S| = m*k, in roughly m + log k
     queries to the oracle using ciphertexts of length proportional to k,
     the maximum message length in blocks.  (Applying the multi-collision
     algorithm from [LGR20] requires a small adaptation to the algorithm
     wherein the appropriate nonce is computed for each candidate key.
     This modification adds one call to HKDF per key.  The number of
     partitioning oracle queries remains unchanged.)  As a result, the PSK
     must therefore be chosen with sufficient entropy so that m + log k is
     prohibitive for attackers (e.g., 2^128).  Future specifications can
     define new AEAD algorithms that are key-committing.

  9.6.  Domain Separation

     HPKE allows combining a DHKEM variant DHKEM(Group, KDF') and a KDF
     such that both KDFs are instantiated by the same KDF.  By design, the
     calls to Extract() and Expand() inside DHKEM and the remainder of
     HPKE use separate input domains.  This justifies modeling them as
     independent functions even if instantiated by the same KDF.  This
     domain separation between DHKEM and the remainder of HPKE is achieved
     by using prefix-free sets of suite_id values in LabeledExtract(),
     LabeledExpand(), and LabeledDerive (KEM... in DHKEM and HPKE... in
     the remainder of HPKE).  Recall that a set is prefix-free if no
     element is a prefix of another within the set.

     Separation between uses of the one-stage and two-stage KDFs is
     ensured by the inclusion of the suite_id in LabeledExtract,
     LabeledExpand, and LabeledDerive.

     Future KEM instantiations MUST ensure, should Extract(), Expand(),
     and/or Derive() be used internally, that they can be modeled as
     functions independent from the invocations of these functions in the
     remainder of HPKE.  One way to ensure this is by using
     LabeledExtract() / LabeledExpand() / LabeledDerive() functions with a



  Barnes, et al.             Expires 8 May 2026                  [Page 33]


  Internet-Draft                    HPKE                     November 2025


     suite_id as defined in Section 4, which will ensure input domain
     separation, as outlined above.  Particular attention needs to be paid
     if the KEM directly invokes functions that are used internally in
     HPKE's Extract() or Expand(), such as Hash() and HMAC() in the case
     of HKDF.  It MUST be ensured that inputs to these invocations cannot
     collide with inputs to the internal invocations of these functions
     inside Extract() or Expand().  In HPKE's KeySchedule() this is
     avoided by using Extract() instead of Hash() on the arbitrary-length
     inputs info and psk_id.

     The string literal "HPKE-v1" used in LabeledExtract() /
     LabeledExpand() / LabeledDerive() ensures that any secrets derived in
     HPKE are bound to the scheme's name and version, even when possibly
     derived from the same Diffie-Hellman or KEM shared secret as in
     another scheme or version.

  9.7.  Application Embedding and Non-Goals

     HPKE is designed to be a fairly low-level mechanism.  As a result, it
     assumes that certain properties are provided by the application in
     which HPKE is embedded and leaves certain security properties to be
     provided by other mechanisms.  Otherwise said, certain properties are
     out-of-scope for HPKE.

  9.7.1.  Message Order and Message Loss

     The primary requirement that HPKE imposes on applications is the
     requirement that ciphertexts MUST be presented to ContextR.Open() in
     the same order in which they were generated by ContextS.Seal().  When
     the single-shot API is used (see Section 6), this is trivially true
     (since there is only ever one ciphertext.  Applications that allow
     for multiple invocations of Open() / Seal() on the same context MUST
     enforce the ordering property described above.

     Ordering requirements of this character are usually fulfilled by
     providing a sequence number in the framing of encrypted messages.
     Whatever information is used to determine the ordering of HPKE-
     encrypted messages SHOULD be included in the AAD passed to
     ContextS.Seal() and ContextR.Open().  The specifics of this scheme
     are up to the application.

     HPKE is not tolerant of lost messages.  Applications MUST be able to
     detect when a message has been lost.  When an unrecoverable loss is
     detected, the application MUST discard any associated HPKE context.







  Barnes, et al.             Expires 8 May 2026                  [Page 34]


  Internet-Draft                    HPKE                     November 2025


  9.7.2.  Downgrade Prevention

     HPKE assumes that the sender and recipient agree on what algorithms
     to use.  Depending on how these algorithms are negotiated, it may be
     possible for an intermediary to force the two parties to use
     suboptimal algorithms.

  9.7.3.  Replay Protection

     The requirement that ciphertexts be presented to the ContextR.Open()
     function in the same order they were generated by ContextS.Seal()
     provides a degree of replay protection within a stream of ciphertexts
     resulting from a given context.  HPKE provides no other replay
     protection.

     While a sender can guarantee the uniqueness of HPKE ciphertexts, a
     recipient might receive the same ciphertext multiple times.  Unless
     the recipient takes particular care to guarantee that replay is
     impossible, such as tracking all enc values that are received, this
     can result in multiple contexts that have the same shared secret.
     This is particularly relevant for exported secrets.

     If an attacker can cause a recipient to re-use an enc value, any
     exported secrets will be the same as in the initial transaction.
     While the exported values are still known only to the sender and
     recipient (not the replay attacker), such replay can allow the
     attacker to cause the recipient to re-use the exported values.

     Consider the following scenario, in which B is using the recipient-
     to-sender encryption described as an example in Section 9.8 of
     [RFC9180]:




















  Barnes, et al.             Expires 8 May 2026                  [Page 35]


  Internet-Draft                    HPKE                     November 2025


     B->A: pk

     A:    enc1, ctx = SetupBaseS(pk)
           ct1 = ctx.seal(aad, pt)
     A->B: enc1, ct1

     B:    ctx = SetupBaseR(sk, enc1)
           key, nonce = ctx.export(...)
           ct2 = AEAD.seal(key, nonce, aad2, pt2)
     B->A: ct2

     X->B: enc1, ct1 [replay of previously sent values]

     B:    ctx = SetupBaseR(sk, enc)
           key, nonce = ctx.export(...)
           ct3 = AEAD.seal(key, nonce, aad3, pt3)
     B->X: ct3

              Figure 1: Attacker-triggered nonce reuse via replay

     In this scenario, if aad2 is different from aad3 or pt2 is different
     from pt3 (for example, due to the use of a timestamp in either
     field), then the ciphertexts ct2 and ct3 will represent encryptions
     of different values with the same (key, nonce) pair -- a nonce reuse
     condition that can completely break the authenticated encryption
     guarantees for several AEAD algorithms, including those defined in
     Section 7.3.

     In order to avoid such risks, applications SHOULD incorporate a fresh
     recipient-provided nonce when deriving values from an export context,
     as discussed in Section 4.4 of [RFC9458] and Section 9.8.

  9.7.4.  Forward Secrecy

     HPKE ciphertexts are not forward secret with respect to recipient
     compromise in any mode.  This means that compromise of long-term
     recipient secrets allows an attacker to decrypt past ciphertexts
     encrypted under said secrets.  This is because only long-term secrets
     are used on the side of the recipient.

     HPKE ciphertexts are forward secret with respect to sender compromise
     in all modes.  This is because ephemeral randomness is used on the
     sender's side, which is supposed to be erased directly after
     computation of the KEM shared secret and ciphertext.







  Barnes, et al.             Expires 8 May 2026                  [Page 36]


  Internet-Draft                    HPKE                     November 2025


  9.7.5.  Bad Ephemeral Randomness

     If the randomness used for KEM encapsulation is bad -- i.e., of low
     entropy or compromised because of a broken or subverted random number
     generator -- the confidentiality guarantees of HPKE degrade
     significantly.  In Base mode, confidentiality guarantees can be lost
     completely; in the other modes, at least forward secrecy with respect
     to sender compromise can be lost completely.

     Such a situation could also lead to the reuse of the same KEM shared
     secret and thus to the reuse of same key-nonce pairs for the AEAD.
     The AEADs specified in this document are not secure in case of nonce
     reuse.  This attack vector is particularly relevant in the
     authenticated mode because knowledge of the ephemeral randomness is
     not enough to derive shared_secret in these modes.

     One way for applications to mitigate the impacts of bad ephemeral
     randomness is to combine ephemeral randomness with a local long-term
     secret that has been generated securely, as described in [RFC8937].

  9.7.6.  Hiding Plaintext Length

     AEAD ciphertexts produced by HPKE do not hide the plaintext length.
     Applications requiring this level of privacy should use a suitable
     padding mechanism.  See [I-D.ietf-tls-esni] and [RFC8467] for
     examples of protocol-specific padding policies.

  9.8.  Bidirectional Encryption

     As discussed in Section 5.2, HPKE encryption is unidirectional from
     sender to recipient.  Applications that require bidirectional
     encryption can derive necessary keying material with the secret
     export interface Section 5.3.  The type and length of such keying
     material depends on the application use case.

     As an example, if an application needs AEAD encryption from the
     recipient to the sender, it can derive a key and nonce from the
     corresponding HPKE context as follows:

     def EncryptResponse(context, enc, response_aad, response_pt):
       secret = context.Export("[application] response", Nh)
       response_nonce = random(Nh)
       salt = concat(enc, response_nonce)
       prk = Extract(salt, secret)
       aead_key = Expand(prk, "key", Nk)
       aead_nonce = Expand(prk, "nonce", Nn)
       ct = Seal(aead_key, aead_nonce, response_aad, response_pt)
       return (response_nonce, ct)



  Barnes, et al.             Expires 8 May 2026                  [Page 37]


  Internet-Draft                    HPKE                     November 2025


     This example mechanism differs from the example mechanism in
     [RFC9180] by incorporating a per-transaction random value
     response_nonce.  Because HPKE does not provide replay protection, the
     mechanism in [RFC9180] enabled an attacker to trigger reuse of a
     (key, nonce) pair by replaying an HPKE message under certain
     application circumstances.  Incorporating per-transaction entropy
     ensures that the key and nonce used in AEAD encryption will be
     distinct for every invocation of the mechanism.

     In this context, HPKE's limitations with regard to sender
     authentication become limits on recipient authentication.  In
     particular, in the Base mode, there is no authentication of the
     remote party at all.

  9.9.  Metadata Protection

     The PSK mode of HPKE requires that the recipient know what key
     material to use for the sender.  This can be signaled in applications
     by sending the PSK ID (psk_id above) and/or the sender's public key
     (pkS).  However, these values themselves might be considered
     sensitive, since, in a given application context, they might identify
     the sender.

     An application that wishes to protect these metadata values without
     requiring further provisioning of keys can use an additional instance
     of HPKE, using the unauthenticated Base mode.  Where the application
     might have sent (psk_id, enc, ciphertext) before, it would now send
     (enc2, ciphertext2, enc, ciphertext), where (enc2, ciphertext2)
     represent the encryption of the psk_id value.

     The cost of this approach is an additional KEM operation each for the
     sender and the recipient.  A potential lower-cost approach (involving
     only symmetric operations) would be available if the nonce-protection
     schemes in [BNT19] could be extended to cover other metadata.
     However, this construction would require further analysis.

  10.  Message Encoding

     This document does not specify a wire format encoding for HPKE
     messages.  Applications that adopt HPKE must therefore specify an
     unambiguous encoding mechanism that includes, minimally: the
     encapsulated secret enc, ciphertext value(s) (and order if there are
     multiple), and any info values that are not implicit.  One example of
     a non-implicit value is the recipient public key used for
     encapsulation, which may be needed if a recipient has more than one
     public key.





  Barnes, et al.             Expires 8 May 2026                  [Page 38]


  Internet-Draft                    HPKE                     November 2025


     The AEAD interface used in this document is based on [RFC5116], which
     produces and consumes a single ciphertext value.  As discussed in
     [RFC5116], this ciphertext value contains the encrypted plaintext as
     well as any authentication data, encoded in a manner described by the
     individual AEAD scheme.  Some implementations are not structured in
     this way, instead providing a separate ciphertext and authentication
     tag.  When such AEAD implementations are used in HPKE
     implementations, the HPKE implementation must combine these inputs
     into a single ciphertext value within Seal() and parse them out
     within Open(), where the parsing details are defined by the AEAD
     scheme.  For example, with the AES-GCM schemes specified in this
     document, the GCM authentication tag is placed in the last Nt bytes
     of the ciphertext output.

  11.  IANA Considerations

     IANA created three new registries as requested in Section 11 of
     [RFC9180]:

     *  HPKE KEM Identifiers

     *  HPKE KDF Identifiers

     *  HPKE AEAD Identifiers

     All these registries are under "Hybrid Public Key Encryption", and
     administered under a Specification Required policy [RFC8126].

     This document requests that entries in these registries referring to
     RFC 9180 be updated to refer to this document.

  11.1.  KEM Identifiers

     The "HPKE KEM Identifiers" registry lists identifiers for key
     encapsulation algorithms defined for use with HPKE.  These
     identifiers are two-byte values, so the maximum possible value is
     0xFFFF = 65535.

     Template:

     *  Value: The two-byte identifier for the algorithm

     *  KEM: The name of the algorithm

     *  Nsecret: The length in bytes of a KEM shared secret produced by
        the algorithm





  Barnes, et al.             Expires 8 May 2026                  [Page 39]


  Internet-Draft                    HPKE                     November 2025


     *  Nenc: The length in bytes of an encoded encapsulated secret
        produced by the algorithm

     *  Npk: The length in bytes of an encoded public key for the
        algorithm

     *  Nsk: The length in bytes of an encoded private key for the
        algorithm

     *  Auth: A boolean indicating if this algorithm provides the
        AuthEncap()/AuthDecap() interface

     *  Reference: Where this algorithm is defined

     Initial contents: Provided in Table 2

  11.2.  KDF Identifiers

     The "HPKE KDF Identifiers" registry lists identifiers for key
     derivation functions defined for use with HPKE.  These identifiers
     are two-byte values, so the maximum possible value is 0xFFFF = 65535.

     Template:

     *  Value: The two-byte identifier for the algorithm

     *  KDF: The name of the algorithm

     *  Nh: The output size of the Extract function in bytes

     *  Reference: Where this algorithm is defined

     Initial contents: Provided in Table 3

  11.3.  AEAD Identifiers

     The "HPKE AEAD Identifiers" registry lists identifiers for
     authenticated encryption with associated data (AEAD) algorithms
     defined for use with HPKE.  These identifiers are two-byte values, so
     the maximum possible value is 0xFFFF = 65535.

     Template:

     *  Value: The two-byte identifier for the algorithm

     *  AEAD: The name of the algorithm

     *  Nk: The length in bytes of a key for this algorithm



  Barnes, et al.             Expires 8 May 2026                  [Page 40]


  Internet-Draft                    HPKE                     November 2025


     *  Nn: The length in bytes of a nonce for this algorithm

     *  Nt: The length in bytes of an authentication tag for this
        algorithm

     *  Reference: Where this algorithm is defined

     Initial contents: Provided in Table 5

  12.  References

  12.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
                Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
                <https://www.rfc-editor.org/rfc/rfc5116>.

     [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
                "PKCS #1: RSA Cryptography Specifications Version 2.2",
                RFC 8017, DOI 10.17487/RFC8017, November 2016,
                <https://www.rfc-editor.org/rfc/rfc8017>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/rfc/rfc8126>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC9458]  Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458,
                DOI 10.17487/RFC9458, January 2024,
                <https://www.rfc-editor.org/rfc/rfc9458>.

  12.2.  Informative References

     [ABHKLR20] Alwen, J., Blanchet, B., Hauck, E., Kiltz, E., Lipp, B.,
                and D. Riepel, "Analysing the HPKE Standard", 2020,
                <https://eprint.iacr.org/2020/1499>.






  Barnes, et al.             Expires 8 May 2026                  [Page 41]


  Internet-Draft                    HPKE                     November 2025


     [ANSI]     American National Standards Institute, "ANSI X9.63 Public
                Key Cryptography for the Financial Services Industry --
                Key Agreement and Key Transport Using Elliptic Curve
                Cryptography", 2001.

     [BHK09]    Mihir Bellare, Dennis Hofheinz, and Eike Kiltz,
                "Subtleties in the Definition of IND-CCA: When and How
                Should Challenge-Decryption be Disallowed?", 2009,
                <https://eprint.iacr.org/2009/418>.

     [BNT19]    Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
                AEAD Revisited", 2019,
                <http://dx.doi.org/10.1007/978-3-030-26948-7_9>.

     [CS01]     Cramer, R. and V. Shoup, "Design and Analysis of Practical
                Public-Key Encryption Schemes Secure against Adaptive
                Chosen Ciphertext Attack", 2001,
                <https://eprint.iacr.org/2001/108>.

     [FIPS202]  "SHA-3 standard :: permutation-based hash and extendable-
                output functions", National Institute of Standards and
                Technology (U.S.), DOI 10.6028/nist.fips.202, 2015,
                <https://doi.org/10.6028/nist.fips.202>.

     [GAP]      Okamoto, T. and D. Pointcheval, "The Gap-Problems - a New
                Class of Problems for the Security of Cryptographic
                Schemes", ISBN 978-3-540-44586-9, 2001,
                <https://link.springer.com/content/
                pdf/10.1007/3-540-44586-2_8.pdf>.

     [GCM]      Dworkin, M., "Recommendation for block cipher modes of
                operation :: GaloisCounter Mode (GCM) and GMAC", National
                Institute of Standards and Technology,
                DOI 10.6028/nist.sp.800-38d, 2007,
                <https://doi.org/10.6028/nist.sp.800-38d>.

     [HHK06]    Herranz, J., Hofheinz, D., and E. Kiltz, "Some
                (in)sufficient conditions for secure hybrid encryption",
                2006, <https://eprint.iacr.org/2006/265>.

     [HPKEAnalysis]
                Lipp, B., "An Analysis of Hybrid Public Key Encryption",
                2020, <https://eprint.iacr.org/2020/243>.








  Barnes, et al.             Expires 8 May 2026                  [Page 42]


  Internet-Draft                    HPKE                     November 2025


     [I-D.ietf-tls-esni]
                Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
                Encrypted Client Hello", Work in Progress, Internet-Draft,
                draft-ietf-tls-esni-25, 14 June 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
                esni-25>.

     [IEEE1363] Institute of Electrical and Electronics Engineers, "IEEE
                1363a, Standard Specifications for Public Key Cryptography
                - Amendment 1 -- Additional Techniques"", 2004.

     [IMB]      Diffie, W., Van Oorschot, P., and M. Wiener,
                "Authentication and authenticated key exchanges", Springer
                Science and Business Media LLC, Designs, Codes and
                Cryptography vol. 2, no. 2, pp. 107-125,
                DOI 10.1007/bf00124891, June 1992,
                <https://doi.org/10.1007/bf00124891>.

     [ISO]      International Organization for Standardization /
                International Electrotechnical Commission, "ISO/IEC
                18033-2, Information Technology - Security Techniques -
                Encryption Algorithms - Part 2 -- Asymmetric Ciphers",
                2006.

     [keyagreement]
                Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
                Davis, "Recommendation for pair-wise key-establishment
                schemes using discrete logarithm cryptography", National
                Institute of Standards and Technology,
                DOI 10.6028/nist.sp.800-56ar3, April 2018,
                <https://doi.org/10.6028/nist.sp.800-56ar3>.

     [LGR20]    Len, J., Grubbs, P., and T. Ristenpart, "Partitioning
                Oracle Attacks", 2021,
                <https://eprint.iacr.org/2020/1491>.

     [MAEA10]   Gayoso Martinez, V., Hernandez Alvarez, F., Hernandez
                Encinas, L., and C. Sanchez Avila, "A Comparison of the
                Standardized Versions of ECIES", 2010,
                <https://ieeexplore.ieee.org/abstract/document/5604194/>.

     [NISTCurves]
                "Digital signature standard (DSS)", National Institute of
                Standards and Technology (U.S.),
                DOI 10.6028/nist.fips.186-4, 2013,
                <https://doi.org/10.6028/nist.fips.186-4>.





  Barnes, et al.             Expires 8 May 2026                  [Page 43]


  Internet-Draft                    HPKE                     November 2025


     [RFC1421]  Linn, J., "Privacy Enhancement for Internet Electronic
                Mail: Part I: Message Encryption and Authentication
                Procedures", RFC 1421, DOI 10.17487/RFC1421, February
                1993, <https://www.rfc-editor.org/rfc/rfc1421>.

     [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/rfc/rfc5869>.

     [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
                for Security", RFC 7748, DOI 10.17487/RFC7748, January
                2016, <https://www.rfc-editor.org/rfc/rfc7748>.

     [RFC8439]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
                Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
                <https://www.rfc-editor.org/rfc/rfc8439>.

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/rfc/rfc8446>.

     [RFC8467]  Mayrhofer, A., "Padding Policies for Extension Mechanisms
                for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
                October 2018, <https://www.rfc-editor.org/rfc/rfc8467>.

     [RFC8937]  Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
                and C. Wood, "Randomness Improvements for Security
                Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
                <https://www.rfc-editor.org/rfc/rfc8937>.

     [RFC9180]  Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
                Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
                February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.

     [RFC9420]  Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
                Omara, E., and K. Cohn-Gordon, "The Messaging Layer
                Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
                July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.

     [SECG]     "Elliptic Curve Cryptography, Standards for Efficient
                Cryptography Group, ver. 2", 2009,
                <https://secg.org/sec1-v2.pdf>.








  Barnes, et al.             Expires 8 May 2026                  [Page 44]


  Internet-Draft                    HPKE                     November 2025


     [SigncryptionDZ10]
                "Practical Signcryption", Springer Berlin Heidelberg,
                Information Security and Cryptography,
                DOI 10.1007/978-3-540-89411-7, ISBN ["9783540894094",
                "9783540894117"], 2010,
                <https://doi.org/10.1007/978-3-540-89411-7>.

     [TestVectors]
                "HPKE Test Vectors", 2021, <https://github.com/cfrg/draft-
                irtf-cfrg-
                hpke/blob/5f503c564da00b0687b3de75f1dfbdfc4079ad31/test-
                vectors.json>.

  Appendix A.  Differences from RFC 9180

     This specification is intended to be backwards-compatible with RFC
     9180, in the sense that any behavior specified in both this document
     and RFC 9180 should specify identical behavior for any functionality
     that they both specify.

     Within that constraint, the following list summarizes the major
     changes from RFC 9180:

     *  Incorporated fixes for all valid errata on RFC 9180.

     *  Updated the IANA considerations refer to existing registries.

     *  Added a framework for single-stage KDFs.

     *  Removed the Auth and AuthPSK modes.

     *  Extended the discussion of replay to conver considerations related
        to exported secrets.

  Appendix B.  Acknowledgements

     The authors would like to thank Joël Alwen, Jean-Philippe Aumasson,
     David Benjamin, Benjamin Beurdouche, Bruno Blanchet, Frank Denis,
     Stephen Farrell, Scott Fluhrer, Eduard Hauck, Scott Hollenbeck, Kevin
     Jacobs, Burt Kaliski, Eike Kiltz, Julia Len, John Mattsson,
     Christopher Patton, Doreen Riepel, Raphael Robert, Michael Rosenberg,
     Michael Scott, Martin Thomson, Steven Valdez, Riad Wahby, and other
     contributors in the CFRG for helpful feedback that greatly improved
     this document.







  Barnes, et al.             Expires 8 May 2026                  [Page 45]


  Internet-Draft                    HPKE                     November 2025


  Appendix C.  Test Vectors

     Each section below contains test vectors for a single HPKE
     ciphersuite and contains the following values:

     1.  Configuration information and private key material: This includes
         the mode, info string, HPKE ciphersuite identifiers (kem_id,
         kdf_id, aead_id), and all sender, recipient, and ephemeral key
         material.  For each role X, where X is one of S, R, or E, as
         sender, recipient, and ephemeral, respectively, key pairs are
         generated as (skX, pkX) = DeriveKeyPair(ikmX).  Each key pair
         (skX, pkX) is written in its serialized form, where skXm =
         SerializePrivateKey(skX) and pkXm = SerializePublicKey(pkX).  For
         applicable modes, the shared PSK and PSK identifier are also
         included.

     2.  Context creation intermediate values and outputs: This includes
         the KEM outputs enc and shared_secret used to create the context,
         along with intermediate values key_schedule_context and secret
         computed in the KeySchedule function in Section 5.1.  The outputs
         include the context values key, base_nonce, and exporter_secret.

     3.  Encryption test vectors: A fixed plaintext message is encrypted
         using different sequence numbers and AAD values using the context
         computed in (2).  Each test vector lists the sequence number and
         corresponding nonce computed with base_nonce, the plaintext
         message pt, AAD aad, and output ciphertext ct.

     4.  Export test vectors: Several exported values of the same length
         with differing context parameters are computed using the context
         computed in (2).  Each test vector lists the exporter_context,
         output length L, and resulting export value.

     These test vectors are also available in JSON format at
     [TestVectors].

  C.1.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM

  C.1.1.  Base Setup Information












  Barnes, et al.             Expires 8 May 2026                  [Page 46]


  Internet-Draft                    HPKE                     November 2025


     mode: 0
     kem_id: 32
     kdf_id: 1
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     7268600d403fce431561aef583ee1613527cff655c1343f29812e66706df3234
     pkEm:
     37fda3567bdbd628e88668c3c8d7e97d1d1253b6d4ea6d44c150f741f1bf4431
     skEm:
     52c4a758a802cd8b936eceea314432798d5baf2d7e9235dc084ab1b9cfa2f736
     ikmR:
     6db9df30aa07dd42ee5e8181afdb977e538f5e1fec8a06223f33f7013e525037
     pkRm:
     3948cfe0ad1ddb695d780e59077195da6c56506b027329794ab02bca80815c4d
     skRm:
     4612c550263fc8ad58375df3f557aac531d26850903e55a9f23f21d8534e8ac8
     enc:
     37fda3567bdbd628e88668c3c8d7e97d1d1253b6d4ea6d44c150f741f1bf4431
     shared_secret:
     fe0e18c9f024ce43799ae393c7e8fe8fce9d218875e8227b0187c04e7d2ea1fc
     key_schedule_context: 00725611c9d98c07c03f60095cd32d400d8347d45ed670
     97bbad50fc56da742d07cb6cffde367bb0565ba28bb02c90744a20f5ef37f3052352
     6106f637abb05449
     secret:
     12fff91991e93b48de37e7daddb52981084bd8aa64289c3788471d9a9712f397
     key: 4531685d41d65f03dc48f6b8302c05b0
     base_nonce: 56d890e5accaaf011cff4b7d
     exporter_secret:
     45ff1c2e220db587171952c0592d5f5ebe103f1561a2614e38f2ffd47e99e3f8

  C.1.1.1.  Encryptions



















  Barnes, et al.             Expires 8 May 2026                  [Page 47]


  Internet-Draft                    HPKE                     November 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 56d890e5accaaf011cff4b7d
     ct: f938558b5d72f1a23810b4be2ab4f84331acc02fc97babc53a52ae8218a355a9
     6d8770ac83d07bea87e13c512a

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 56d890e5accaaf011cff4b7c
     ct: af2d7e9ac9ae7e270f46ba1f975be53c09f8d875bdc8535458c2494e8a6eab25
     1c03d0c22a56b8ca42c2063b84

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 56d890e5accaaf011cff4b7f
     ct: 498dfcabd92e8acedc281e85af1cb4e3e31c7dc394a1ca20e173cb7251649158
     8d96a19ad4a683518973dcc180

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 56d890e5accaaf011cff4b79
     ct: 583bd32bc67a5994bb8ceaca813d369bca7b2a42408cddef5e22f880b631215a
     09fc0012bc69fccaa251c0246d

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 56d890e5accaaf011cff4b82
     ct: 7175db9717964058640a3a11fb9007941a5d1757fda1a6935c805c21af32505b
     f106deefec4a49ac38d71c9e0a

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 56d890e5accaaf011cff4a7d
     ct: 957f9800542b0b8891badb026d79cc54597cb2d225b54c00c5238c25d05c30e3
     fbeda97d2e0e1aba483a2df9f2

  C.1.1.2.  Exported Values








  Barnes, et al.             Expires 8 May 2026                  [Page 48]


  Internet-Draft                    HPKE                     November 2025


     exporter_context:
     L: 32
     exported_value:
     3853fe2b4035195a573ffc53856e77058e15d9ea064de3e59f4961d0095250ee

     exporter_context: 00
     L: 32
     exported_value:
     2e8f0b54673c7029649d4eb9d5e33bf1872cf76d623ff164ac185da9e88c21a5

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     e9e43065102c3836401bed8c3c3c75ae46be1639869391d62c61f1ec7af54931

  C.1.2.  PSK Setup Information



































  Barnes, et al.             Expires 8 May 2026                  [Page 49]


  Internet-Draft                    HPKE                     November 2025


     mode: 1
     kem_id: 32
     kdf_id: 1
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     78628c354e46f3e169bd231be7b2ff1c77aa302460a26dbfa15515684c00130b
     pkEm:
     0ad0950d9fb9588e59690b74f1237ecdf1d775cd60be2eca57af5a4b0471c91b
     skEm:
     463426a9ffb42bb17dbe6044b9abd1d4e4d95f9041cef0e99d7824eef2b6f588
     ikmR:
     d4a09d09f575fef425905d2ab396c1449141463f698f8efdb7accfaff8995098
     pkRm:
     9fed7e8c17387560e92cc6462a68049657246a09bfa8ade7aefe589672016366
     skRm:
     c5eb01eb457fe6c6f57577c5413b931550a162c71a03ac8d196babbd4e5ce0fd
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc:
     0ad0950d9fb9588e59690b74f1237ecdf1d775cd60be2eca57af5a4b0471c91b
     shared_secret:
     727699f009ffe3c076315019c69648366b69171439bd7dd0807743bde76986cd
     key_schedule_context: 01e78d5cf6190d275863411ff5edd0dece5d39fa48e04e
     ec1ed9b71be34729d18ccb6cffde367bb0565ba28bb02c90744a20f5ef37f3052352
     6106f637abb05449
     secret:
     3728ab0b024b383b0381e432b47cced1496d2516957a76e2a9f5c8cb947afca4
     key: 15026dba546e3ae05836fc7de5a7bb26
     base_nonce: 9518635eba129d5ce0914555
     exporter_secret:
     3d76025dbbedc49448ec3f9080a1abab6b06e91c0b11ad23c912f043a0ee7655

  C.1.2.1.  Encryptions
















  Barnes, et al.             Expires 8 May 2026                  [Page 50]


  Internet-Draft                    HPKE                     November 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 9518635eba129d5ce0914555
     ct: e52c6fed7f758d0cf7145689f21bc1be6ec9ea097fef4e959440012f4feb73fb
     611b946199e681f4cfc34db8ea

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 9518635eba129d5ce0914554
     ct: 49f3b19b28a9ea9f43e8c71204c00d4a490ee7f61387b6719db765e948123b45
     b61633ef059ba22cd62437c8ba

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 9518635eba129d5ce0914557
     ct: 257ca6a08473dc851fde45afd598cc83e326ddd0abe1ef23baa3baa4dd8cde99
     fce2c1e8ce687b0b47ead1adc9

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 9518635eba129d5ce0914551
     ct: a71d73a2cd8128fcccbd328b9684d70096e073b59b40b55e6419c9c68ae21069
     c847e2a70f5d8fb821ce3dfb1c

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 9518635eba129d5ce09145aa
     ct: 55f84b030b7f7197f7d7d552365b6b932df5ec1abacd30241cb4bc4ccea27bd2
     b518766adfa0fb1b71170e9392

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 9518635eba129d5ce0914455
     ct: c5bf246d4a790a12dcc9eed5eae525081e6fb541d5849e9ce8abd92a3bc15517
     76bea16b4a518f23e237c14b59

  C.1.2.2.  Exported Values








  Barnes, et al.             Expires 8 May 2026                  [Page 51]


  Internet-Draft                    HPKE                     November 2025


     exporter_context:
     L: 32
     exported_value:
     dff17af354c8b41673567db6259fd6029967b4e1aad13023c2ae5df8f4f43bf6

     exporter_context: 00
     L: 32
     exported_value:
     6a847261d8207fe596befb52928463881ab493da345b10e1dcc645e3b94e2d95

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     8aff52b45a1be3a734bc7a41e20b4e055ad4c4d22104b0c20285a7c4302401cd

  C.2.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, ChaCha20Poly1305

  C.2.1.  Base Setup Information

































  Barnes, et al.             Expires 8 May 2026                  [Page 52]


  Internet-Draft                    HPKE                     November 2025


     mode: 0
     kem_id: 32
     kdf_id: 1
     aead_id: 3
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     909a9b35d3dc4713a5e72a4da274b55d3d3821a37e5d099e74a647db583a904b
     pkEm:
     1afa08d3dec047a643885163f1180476fa7ddb54c6a8029ea33f95796bf2ac4a
     skEm:
     f4ec9b33b792c372c1d2c2063507b684ef925b8c75a42dbcbf57d63ccd381600
     ikmR:
     1ac01f181fdf9f352797655161c58b75c656a6cc2716dcb66372da835542e1df
     pkRm:
     4310ee97d88cc1f088a5576c77ab0cf5c3ac797f3d95139c6c84b5429c59662a
     skRm:
     8057991eef8f1f1af18f4a9491d16a1ce333f695d4db8e38da75975c4478e0fb
     enc:
     1afa08d3dec047a643885163f1180476fa7ddb54c6a8029ea33f95796bf2ac4a
     shared_secret:
     0bbe78490412b4bbea4812666f7916932b828bba79942424abb65244930d69a7
     key_schedule_context: 00431df6cd95e11ff49d7013563baf7f11588c75a6611e
     e2a4404a49306ae4cfc5b69c5718a60cc5876c358d3f7fc31ddb598503f67be58ea1
     e798c0bb19eb9796
     secret:
     5b9cd775e64b437a2335cf499361b2e0d5e444d5cb41a8a53336d8fe402282c6
     key:
     ad2744de8e17f4ebba575b3f5f5a8fa1f69c2a07f6e7500bc60ca6e3e3ec1c91
     base_nonce: 5c4d98150661b848853b547f
     exporter_secret:
     a3b010d4994890e2c6968a36f64470d3c824c8f5029942feb11e7a74b2921922

  C.2.1.1.  Encryptions


















  Barnes, et al.             Expires 8 May 2026                  [Page 53]


  Internet-Draft                    HPKE                     November 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 5c4d98150661b848853b547f
     ct: 1c5250d8034ec2b784ba2cfd69dbdb8af406cfe3ff938e131f0def8c8b60b4db
     21993c62ce81883d2dd1b51a28

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 5c4d98150661b848853b547e
     ct: 6b53c051e4199c518de79594e1c4ab18b96f081549d45ce015be002090bb119e
     85285337cc95ba5f59992dc98c

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 5c4d98150661b848853b547d
     ct: 71146bd6795ccc9c49ce25dda112a48f202ad220559502cef1f34271e0cb4b02
     b4f10ecac6f48c32f878fae86b

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 5c4d98150661b848853b547b
     ct: 63357a2aa291f5a4e5f27db6baa2af8cf77427c7c1a909e0b37214dd47db122b
     b153495ff0b02e9e54a50dbe16

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 5c4d98150661b848853b5480
     ct: 18ab939d63ddec9f6ac2b60d61d36a7375d2070c9b683861110757062c52b888
     0a5f6b3936da9cd6c23ef2a95c

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 5c4d98150661b848853b557f
     ct: 7a4a13e9ef23978e2c520fd4d2e757514ae160cd0cd05e556ef692370ca53076
     214c0c40d4c728d6ed9e727a5b

  C.2.1.2.  Exported Values








  Barnes, et al.             Expires 8 May 2026                  [Page 54]


  Internet-Draft                    HPKE                     November 2025


     exporter_context:
     L: 32
     exported_value:
     4bbd6243b8bb54cec311fac9df81841b6fd61f56538a775e7c80a9f40160606e

     exporter_context: 00
     L: 32
     exported_value:
     8c1df14732580e5501b00f82b10a1647b40713191b7c1240ac80e2b68808ba69

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     5acb09211139c43b3090489a9da433e8a30ee7188ba8b0a9a1ccf0c229283e53

  C.2.2.  PSK Setup Information



































  Barnes, et al.             Expires 8 May 2026                  [Page 55]


  Internet-Draft                    HPKE                     November 2025


     mode: 1
     kem_id: 32
     kdf_id: 1
     aead_id: 3
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     35706a0b09fb26fb45c39c2f5079c709c7cf98e43afa973f14d88ece7e29c2e3
     pkEm:
     2261299c3f40a9afc133b969a97f05e95be2c514e54f3de26cbe5644ac735b04
     skEm:
     0c35fdf49df7aa01cd330049332c40411ebba36e0c718ebc3edf5845795f6321
     ikmR:
     26b923eade72941c8a85b09986cdfa3f1296852261adedc52d58d2930269812b
     pkRm:
     13640af826b722fc04feaa4de2f28fbd5ecc03623b317834e7ff4120dbe73062
     skRm:
     77d114e0212be51cb1d76fa99dd41cfd4d0166b08caa09074430a6c59ef17879
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc:
     2261299c3f40a9afc133b969a97f05e95be2c514e54f3de26cbe5644ac735b04
     shared_secret:
     4be079c5e77779d0215b3f689595d59e3e9b0455d55662d1f3666ec606e50ea7
     key_schedule_context: 016870c4c76ca38ae43efbec0f2377d109499d7ce73f4a
     9e1ec37f21d3d063b97cb69c5718a60cc5876c358d3f7fc31ddb598503f67be58ea1
     e798c0bb19eb9796
     secret:
     16974354c497c9bd24c000ceed693779b604f1944975b18c442d373663f4a8cc
     key:
     600d2fdb0313a7e5c86a9ce9221cd95bed069862421744cfb4ab9d7203a9c019
     base_nonce: 112e0465562045b7368653e7
     exporter_secret:
     73b506dc8b6b4269027f80b0362def5cbb57ee50eed0c2873dac9181f453c5ac

  C.2.2.1.  Encryptions















  Barnes, et al.             Expires 8 May 2026                  [Page 56]


  Internet-Draft                    HPKE                     November 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 112e0465562045b7368653e7
     ct: 4a177f9c0d6f15cfdf533fb65bf84aecdc6ab16b8b85b4cf65a370e07fc1d78d
     28fb073214525276f4a89608ff

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 112e0465562045b7368653e6
     ct: 5c3cabae2f0b3e124d8d864c116fd8f20f3f56fda988c3573b40b09997fd6c76
     9e77c8eda6cda4f947f5b704a8

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 112e0465562045b7368653e5
     ct: 14958900b44bdae9cbe5a528bf933c5c990dbb8e282e6e495adf8205d19da9eb
     270e3a6f1e0613ab7e757962a4

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 112e0465562045b7368653e3
     ct: c2a7bc09ddb853cf2effb6e8d058e346f7fe0fb3476528c80db6b698415c5f8c
     50b68a9a355609e96d2117f8d3

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 112e0465562045b736865318
     ct: 2414d0788e4bc39a59a26d7bd5d78e111c317d44c37bd5a4c2a1235f2ddc2085
     c487d406490e75210c958724a7

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 112e0465562045b7368652e7
     ct: c567ae1c3f0f75abe1dd9e4532b422600ed4a6e5b9484dafb1e43ab9f5fd662b
     28c00e2e81d3cde955dae7e218

  C.2.2.2.  Exported Values








  Barnes, et al.             Expires 8 May 2026                  [Page 57]


  Internet-Draft                    HPKE                     November 2025


     exporter_context:
     L: 32
     exported_value:
     813c1bfc516c99076ae0f466671f0ba5ff244a41699f7b2417e4c59d46d39f40

     exporter_context: 00
     L: 32
     exported_value:
     2745cf3d5bb65c333658732954ee7af49eb895ce77f8022873a62a13c94cb4e1

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     ad40e3ae14f21c99bfdebc20ae14ab86f4ca2dc9a4799d200f43a25f99fa78ae

  C.3.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, AES-128-GCM

  C.3.1.  Base Setup Information

































  Barnes, et al.             Expires 8 May 2026                  [Page 58]


  Internet-Draft                    HPKE                     November 2025


     mode: 0
     kem_id: 16
     kdf_id: 1
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     4270e54ffd08d79d5928020af4686d8f6b7d35dbe470265f1f5aa22816ce860e
     pkEm: 04a92719c6195d5085104f469a8b9814d5838ff72b60501e2c4466e5e67b32
     5ac98536d7b61a1af4b78e5b7f951c0900be863c403ce65c9bfcb9382657222d18c4
     skEm:
     4995788ef4b9d6132b249ce59a77281493eb39af373d236a1fe415cb0c2d7beb
     ikmR:
     668b37171f1072f3cf12ea8a236a45df23fc13b82af3609ad1e354f6ef817550
     pkRm: 04fe8c19ce0905191ebc298a9245792531f26f0cece2460639e8bc39cb7f70
     6a826a779b4cf969b8a0e539c7f62fb3d30ad6aa8f80e30f1d128aafd68a2ce72ea0
     skRm:
     f3ce7fdae57e1a310d87f1ebbde6f328be0a99cdbcadf4d6589cf29de4b8ffd2
     enc: 04a92719c6195d5085104f469a8b9814d5838ff72b60501e2c4466e5e67b325
     ac98536d7b61a1af4b78e5b7f951c0900be863c403ce65c9bfcb9382657222d18c4
     shared_secret:
     c0d26aeab536609a572b07695d933b589dcf363ff9d93c93adea537aeabb8cb8
     key_schedule_context: 00b88d4e6d91759e65e87c470e8b9141113e9ad5f0c8ce
     efc1e088c82e6980500798e486f9c9c09c9b5c753ac72d6005de254c607d1b534ed1
     1d493ae1c1d9ac85
     secret:
     2eb7b6bf138f6b5aff857414a058a3f1750054a9ba1f72c2cf0684a6f20b10e1
     key: 868c066ef58aae6dc589b6cfdd18f97e
     base_nonce: 4e0bc5018beba4bf004cca59
     exporter_secret:
     14ad94af484a7ad3ef40e9f3be99ecc6fa9036df9d4920548424df127ee0d99f

  C.3.1.1.  Encryptions



















  Barnes, et al.             Expires 8 May 2026                  [Page 59]


  Internet-Draft                    HPKE                     November 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 4e0bc5018beba4bf004cca59
     ct: 5ad590bb8baa577f8619db35a36311226a896e7342a6d836d8b7bcd2f20b6c7f
     9076ac232e3ab2523f39513434

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 4e0bc5018beba4bf004cca58
     ct: fa6f037b47fc21826b610172ca9637e82d6e5801eb31cbd3748271affd4ecb06
     646e0329cbdf3c3cd655b28e82

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 4e0bc5018beba4bf004cca5b
     ct: 895cabfac50ce6c6eb02ffe6c048bf53b7f7be9a91fc559402cbc5b8dcaeb52b
     2ccc93e466c28fb55fed7a7fec

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 4e0bc5018beba4bf004cca5d
     ct: 8787491ee8df99bc99a246c4b3216d3d57ab5076e18fa27133f520703bc70ec9
     99dd36ce042e44f0c3169a6a8f

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 4e0bc5018beba4bf004ccaa6
     ct: 2ad71c85bf3f45c6eca301426289854b31448bcf8a8ccb1deef3ebd87f60848a
     a53c538c30a4dac71d619ee2cd

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 4e0bc5018beba4bf004ccb59
     ct: 10f179686aa2caec1758c8e554513f16472bd0a11e2a907dde0b212cbe87d74f
     367f8ffe5e41cd3e9962a6afb2

  C.3.1.2.  Exported Values








  Barnes, et al.             Expires 8 May 2026                  [Page 60]


  Internet-Draft                    HPKE                     November 2025


     exporter_context:
     L: 32
     exported_value:
     5e9bc3d236e1911d95e65b576a8a86d478fb827e8bdfe77b741b289890490d4d

     exporter_context: 00
     L: 32
     exported_value:
     6cff87658931bda83dc857e6353efe4987a201b849658d9b047aab4cf216e796

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     d8f1ea7942adbba7412c6d431c62d01371ea476b823eb697e1f6e6cae1dab85a

  C.3.2.  PSK Setup Information



































  Barnes, et al.             Expires 8 May 2026                  [Page 61]


  Internet-Draft                    HPKE                     November 2025


     mode: 1
     kem_id: 16
     kdf_id: 1
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     2afa611d8b1a7b321c761b483b6a053579afa4f767450d3ad0f84a39fda587a6
     pkEm: 04305d35563527bce037773d79a13deabed0e8e7cde61eecee403496959e89
     e4d0ca701726696d1485137ccb5341b3c1c7aaee90a4a02449725e744b1193b53b5f
     skEm:
     57427244f6cc016cddf1c19c8973b4060aa13579b4c067fd5d93a5d74e32a90f
     ikmR:
     d42ef874c1913d9568c9405407c805baddaffd0898a00f1e84e154fa787b2429
     pkRm: 040d97419ae99f13007a93996648b2674e5260a8ebd2b822e84899cd52d874
     46ea394ca76223b76639eccdf00e1967db10ade37db4e7db476261fcc8df97c5ffd1
     skRm:
     438d8bcef33b89e0e9ae5eb0957c353c25a94584b0dd59c991372a75b43cb661
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc: 04305d35563527bce037773d79a13deabed0e8e7cde61eecee403496959e89e
     4d0ca701726696d1485137ccb5341b3c1c7aaee90a4a02449725e744b1193b53b5f
     shared_secret:
     2e783ad86a1beae03b5749e0f3f5e9bb19cb7eb382f2fb2dd64c99f15ae0661b
     key_schedule_context: 01b873cdf2dff4c1434988053b7a775e980dd2039ea24f
     950b26b056ccedcb933198e486f9c9c09c9b5c753ac72d6005de254c607d1b534ed1
     1d493ae1c1d9ac85
     secret:
     f2f534e55931c62eeb2188c1f53450354a725183937e68c85e68d6b267504d26
     key: 55d9eb9d26911d4c514a990fa8d57048
     base_nonce: b595dc6b2d7e2ed23af529b1
     exporter_secret:
     895a723a1eab809804973a53c0ee18ece29b25a7555a4808277ad2651d66d705

  C.3.2.1.  Encryptions
















  Barnes, et al.             Expires 8 May 2026                  [Page 62]


  Internet-Draft                    HPKE                     November 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: b595dc6b2d7e2ed23af529b1
     ct: 90c4deb5b75318530194e4bb62f890b019b1397bbf9d0d6eb918890e1fb2be1a
     c2603193b60a49c2126b75d0eb

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: b595dc6b2d7e2ed23af529b0
     ct: 9e223384a3620f4a75b5a52f546b7262d8826dea18db5a365feb8b997180b22d
     72dc1287f7089a1073a7102c27

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: b595dc6b2d7e2ed23af529b3
     ct: adf9f6000773035023be7d415e13f84c1cb32a24339a32eb81df02be9ddc6abc
     880dd81cceb7c1d0c7781465b2

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: b595dc6b2d7e2ed23af529b5
     ct: 1f4cc9b7013d65511b1f69c050b7bd8bbd5a5c16ece82b238fec4f30ba2400e7
     ca8ee482ac5253cffb5c3dc577

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: b595dc6b2d7e2ed23af5294e
     ct: cdc541253111ed7a424eea5134dc14fc5e8293ab3b537668b8656789628e4589
     4e5bb873c968e3b7cdcbb654a4

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: b595dc6b2d7e2ed23af528b1
     ct: faf985208858b1253b97b60aecd28bc18737b58d1242370e7703ec33b73a4c31
     a1afee300e349adef9015bbbfd

  C.3.2.2.  Exported Values








  Barnes, et al.             Expires 8 May 2026                  [Page 63]


  Internet-Draft                    HPKE                     November 2025


     exporter_context:
     L: 32
     exported_value:
     a115a59bf4dd8dc49332d6a0093af8efca1bcbfd3627d850173f5c4a55d0c185

     exporter_context: 00
     L: 32
     exported_value:
     4517eaede0669b16aac7c92d5762dd459c301fa10e02237cd5aeb9be969430c4

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     164e02144d44b607a7722e58b0f4156e67c0c2874d74cf71da6ca48a4cbdc5e0

  C.4.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA512, AES-128-GCM

  C.4.1.  Base Setup Information

































  Barnes, et al.             Expires 8 May 2026                  [Page 64]


  Internet-Draft                    HPKE                     November 2025


     mode: 0
     kem_id: 16
     kdf_id: 3
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     4ab11a9dd78c39668f7038f921ffc0993b368171d3ddde8031501ee1e08c4c9a
     pkEm: 0493ed86735bdfb978cc055c98b45695ad7ce61ce748f4dd63c525a3b8d53a
     15565c6897888070070c1579db1f86aaa56deb8297e64db7e8924e72866f9a472580
     skEm:
     2292bf14bb6e15b8c81a0f45b7a6e93e32d830e48cca702e0affcfb4d07e1b5c
     ikmR:
     ea9ff7cc5b2705b188841c7ace169290ff312a9cb31467784ca92d7a2e6e1be8
     pkRm: 04085aa5b665dc3826f9650ccbcc471be268c8ada866422f739e2d531d4a88
     18a9466bc6b449357096232919ec4fe9070ccbac4aac30f4a1a53efcf7af90610edd
     skRm:
     3ac8530ad1b01885960fab38cf3cdc4f7aef121eaa239f222623614b4079fb38
     enc: 0493ed86735bdfb978cc055c98b45695ad7ce61ce748f4dd63c525a3b8d53a1
     5565c6897888070070c1579db1f86aaa56deb8297e64db7e8924e72866f9a472580
     shared_secret:
     02f584736390fc93f5b4ad039826a3fa08e9911bd1215a3db8e8791ba533cafd
     key_schedule_context: 005b8a3617af7789ee716e7911c7e77f84cdc4cc46e60f
     b7e19e4059f9aeadc00585e26874d1ddde76e551a7679cd47168c466f6e1f705cc93
     74c192778a34fcd5ca221d77e229a9d11b654de7942d685069c633b2362ce3b3d8ea
     4891c9a2a87a4eb7cdb289ba5e2ecbf8cd2c8498bb4a383dc021454d70d46fcbbad1
     252ef4f9
     secret: 0c7acdab61693f936c4c1256c78e7be30eebfe466812f9cc49f0b58dc970
     328dfc03ea359be0250a471b1635a193d2dfa8cb23c90aa2e25025b892a725353eeb
     key: 090ca96e5f8aa02b69fac360da50ddf9
     base_nonce: 9c995e621bf9a20c5ca45546
     exporter_secret: 4a7abb2ac43e6553f129b2c5750a7e82d149a76ed56dc342d7b
     ca61e26d494f4855dff0d0165f27ce57756f7f16baca006539bb8e4518987ba61048
     0ac03efa8

  C.4.1.1.  Encryptions
















  Barnes, et al.             Expires 8 May 2026                  [Page 65]


  Internet-Draft                    HPKE                     November 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 9c995e621bf9a20c5ca45546
     ct: d3cf4984931484a080f74c1bb2a6782700dc1fef9abe8442e44a6f09044c8890
     7200b332003543754eb51917ba

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 9c995e621bf9a20c5ca45547
     ct: d14414555a47269dfead9fbf26abb303365e40709a4ed16eaefe1f2070f1ddeb
     1bdd94d9e41186f124e0acc62d

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 9c995e621bf9a20c5ca45544
     ct: 9bba136cade5c4069707ba91a61932e2cbedda2d9c7bdc33515aa01dd0e0f7e9
     d3579bf4016dec37da4aafa800

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 9c995e621bf9a20c5ca45542
     ct: a531c0655342be013bf32112951f8df1da643602f1866749519f5dcb09cc6843
     2579de305a77e6864e862a7600

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 9c995e621bf9a20c5ca455b9
     ct: be5da649469efbad0fb950366a82a73fefeda5f652ec7d3731fac6c4ffa21a70
     04d2ab8a04e13621bd3629547d

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 9c995e621bf9a20c5ca45446
     ct: 62092672f5328a0dde095e57435edf7457ace60b26ee44c9291110ec135cb0e1
     4b85594e4fea11247d937deb62

  C.4.1.2.  Exported Values








  Barnes, et al.             Expires 8 May 2026                  [Page 66]


  Internet-Draft                    HPKE                     November 2025


     exporter_context:
     L: 32
     exported_value:
     a32186b8946f61aeead1c093fe614945f85833b165b28c46bf271abf16b57208

     exporter_context: 00
     L: 32
     exported_value:
     84998b304a0ea2f11809398755f0abd5f9d2c141d1822def79dd15c194803c2a

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     93fb9411430b2cfa2cf0bed448c46922a5be9beff20e2e621df7e4655852edbc

  C.4.2.  PSK Setup Information



































  Barnes, et al.             Expires 8 May 2026                  [Page 67]


  Internet-Draft                    HPKE                     November 2025


     mode: 1
     kem_id: 16
     kdf_id: 3
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     c11d883d6587f911d2ddbc2a0859d5b42fb13bf2c8e89ef408a25564893856f5
     pkEm: 04a307934180ad5287f95525fe5bc6244285d7273c15e061f0f2efb211c350
     57f3079f6e0abae200992610b25f48b63aacfcb669106ddee8aa023feed301901371
     skEm:
     a5901ff7d6931959c2755382ea40a4869b1dec3694ed3b009dda2d77dd488f18
     ikmR:
     75bfc2a3a3541170a54c0b06444e358d0ee2b4fb78a401fd399a47a33723b700
     pkRm: 043f5266fba0742db649e1043102b8a5afd114465156719cea90373229aabd
     d84d7f45dabfc1f55664b888a7e86d594853a6cccdc9b189b57839cbbe3b90b55873
     skRm:
     bc6f0b5e22429e5ff47d5969003f3cae0f4fec50e23602e880038364f33b8522
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc: 04a307934180ad5287f95525fe5bc6244285d7273c15e061f0f2efb211c3505
     7f3079f6e0abae200992610b25f48b63aacfcb669106ddee8aa023feed301901371
     shared_secret:
     2912aacc6eaebd71ff715ea50f6ef3a6637856b2a4c58ea61e0c3fc159e3bc16
     key_schedule_context: 01713f73042575cebfd132f0cc4338523f8eae95c80a74
     9f7cf3eb9436ff1c612ca62c37df27ca46d2cc162445a92c5f5fdc57bcde129ca7b1
     f284b0c12297c037ca221d77e229a9d11b654de7942d685069c633b2362ce3b3d8ea
     4891c9a2a87a4eb7cdb289ba5e2ecbf8cd2c8498bb4a383dc021454d70d46fcbbad1
     252ef4f9
     secret: ff2051d2128d5f3078de867143e076262ce1d0aecafc3fff3d607f1eaff0
     5345c7d5ffcb3202cdecb3d1a2f7da20592a237747b6e855390cbe2109d3e6ac70c2
     key: 0b910ba8d9cfa17e5f50c211cb32839a
     base_nonce: 0c29e714eb52de5b7415a1b7
     exporter_secret: 50c0a182b6f94b4c0bd955c4aa20df01f282cc12c43065a0812
     fe4d4352790171ed2b2c4756ad7f5a730ba336c8f1edd0089d8331192058c385bae3
     9c7cc8b57

  C.4.2.1.  Encryptions













  Barnes, et al.             Expires 8 May 2026                  [Page 68]


  Internet-Draft                    HPKE                     November 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 0c29e714eb52de5b7415a1b7
     ct: 57624b6e320d4aba0afd11f548780772932f502e2ba2a8068676b2a0d3b5129a
     45b9faa88de39e8306da41d4cc

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 0c29e714eb52de5b7415a1b6
     ct: 159d6b4c24bacaf2f5049b7863536d8f3ffede76302dace42080820fa51925d4
     e1c72a64f87b14291a3057e00a

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 0c29e714eb52de5b7415a1b5
     ct: bd24140859c99bf0055075e9c460032581dd1726d52cf980d308e9b20083ca62
     e700b17892bcf7fa82bac751d0

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 0c29e714eb52de5b7415a1b3
     ct: 93ddd55f82e9aaaa3cfc06840575f09d80160b20538125c2549932977d1238dd
     e8126a4a91118faf8632f62cb8

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 0c29e714eb52de5b7415a148
     ct: 377a98a3c34bf716581b05a6b3fdc257f245856384d5f2241c8840571c52f5c8
     5c21138a4a81655edab8fe227d

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 0c29e714eb52de5b7415a0b7
     ct: cc161f5a179831d456d119d2f2c19a6817289c75d1c61cd37ac8a450acd9efba
     02e0ac00d128c17855931ff69a

  C.4.2.2.  Exported Values








  Barnes, et al.             Expires 8 May 2026                  [Page 69]


  Internet-Draft                    HPKE                     November 2025


     exporter_context:
     L: 32
     exported_value:
     8158bea21a6700d37022bb7802866edca30ebf2078273757b656ef7fc2e428cf

     exporter_context: 00
     L: 32
     exported_value:
     6a348ba6e0e72bb3ef22479214a139ef8dac57be34509a61087a12565473da8d

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     2f6d4f7a18ec48de1ef4469f596aada4afdf6d79b037ed3c07e0118f8723bffc

  C.5.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, ChaCha20Poly1305

  C.5.1.  Base Setup Information

































  Barnes, et al.             Expires 8 May 2026                  [Page 70]


  Internet-Draft                    HPKE                     November 2025


     mode: 0
     kem_id: 16
     kdf_id: 1
     aead_id: 3
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     f1f1a3bc95416871539ecb51c3a8f0cf608afb40fbbe305c0a72819d35c33f1f
     pkEm: 04c07836a0206e04e31d8ae99bfd549380b072a1b1b82e563c935c09582782
     4fc1559eac6fb9e3c70cd3193968994e7fe9781aa103f5b50e934b5b2f387e381291
     skEm:
     7550253e1147aae48839c1f8af80d2770fb7a4c763afe7d0afa7e0f42a5b3689
     ikmR:
     61092f3f56994dd424405899154a9918353e3e008171517ad576b900ddb275e7
     pkRm: 04a697bffde9405c992883c5c439d6cc358170b51af72812333b015621dc0f
     40bad9bb726f68a5c013806a790ec716ab8669f84f6b694596c2987cf35baba2a006
     skRm:
     a4d1c55836aa30f9b3fbb6ac98d338c877c2867dd3a77396d13f68d3ab150d3b
     enc: 04c07836a0206e04e31d8ae99bfd549380b072a1b1b82e563c935c095827824
     fc1559eac6fb9e3c70cd3193968994e7fe9781aa103f5b50e934b5b2f387e381291
     shared_secret:
     806520f82ef0b03c823b7fc524b6b55a088f566b9751b89551c170f4113bd850
     key_schedule_context: 00b738cd703db7b4106e93b4621e9a19c89c838e559642
     40e5d3f331aaf8b0d58b2e986ea1c671b61cf45eec134dac0bae58ec6f63e790b140
     0b47c33038b0269c
     secret:
     fe891101629aa355aad68eff3cc5170d057eca0c7573f6575e91f9783e1d4506
     key:
     a8f45490a92a3b04d1dbf6cf2c3939ad8bfc9bfcb97c04bffe116730c9dfe3fc
     base_nonce: 726b4390ed2209809f58c693
     exporter_secret:
     4f9bd9b3a8db7d7c3a5b9d44fdc1f6e37d5d77689ade5ec44a7242016e6aa205

  C.5.1.1.  Encryptions


















  Barnes, et al.             Expires 8 May 2026                  [Page 71]


  Internet-Draft                    HPKE                     November 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 726b4390ed2209809f58c693
     ct: 6469c41c5c81d3aa85432531ecf6460ec945bde1eb428cb2fedf7a29f5a685b4
     ccb0d057f03ea2952a27bb458b

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 726b4390ed2209809f58c692
     ct: f1564199f7e0e110ec9c1bcdde332177fc35c1adf6e57f8d1df24022227ffa87
     16862dbda2b1dc546c9d114374

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 726b4390ed2209809f58c691
     ct: 39de89728bcb774269f882af8dc5369e4f3d6322d986e872b3a8d074c7c18e85
     49ff3f85b6d6592ff87c3f310c

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 726b4390ed2209809f58c697
     ct: bc104a14fbede0cc79eeb826ea0476ce87b9c928c36e5e34dc9b6905d91473ec
     369a08b1a25d305dd45c6c5f80

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 726b4390ed2209809f58c66c
     ct: 8f2814a2c548b3be50259713c6724009e092d37789f6856553d61df23ebc0792
     35f710e6af3c3ca6eaba7c7c6c

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 726b4390ed2209809f58c793
     ct: b45b69d419a9be7219d8c94365b89ad6951caf4576ea4774ea40e9b7047a09d6
     537d1aa2f7c12d6ae4b729b4d0

  C.5.1.2.  Exported Values








  Barnes, et al.             Expires 8 May 2026                  [Page 72]


  Internet-Draft                    HPKE                     November 2025


     exporter_context:
     L: 32
     exported_value:
     9b13c510416ac977b553bf1741018809c246a695f45eff6d3b0356dbefe1e660

     exporter_context: 00
     L: 32
     exported_value:
     6c8b7be3a20a5684edecb4253619d9051ce8583baf850e0cb53c402bdcaf8ebb

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     477a50d804c7c51941f69b8e32fe8288386ee1a84905fe4938d58972f24ac938

  C.5.2.  PSK Setup Information



































  Barnes, et al.             Expires 8 May 2026                  [Page 73]


  Internet-Draft                    HPKE                     November 2025


     mode: 1
     kem_id: 16
     kdf_id: 1
     aead_id: 3
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     e1a4e1d50c4bfcf890f2b4c7d6b2d2aca61368eddc3c84162df2856843e1057a
     pkEm: 04f336578b72ad7932fe867cc4d2d44a718a318037a0ec271163699cee653f
     a805c1fec955e562663e0c2061bb96a87d78892bff0cc0bad7906c2d998ebe1a7246
     skEm:
     7d6e4e006cee68af9b3fdd583a0ee8962df9d59fab029997ee3f456cbc857904
     ikmR:
     ee51dec304abf993ef8fd52aacdd3b539108bbf6e491943266c1de89ec596a17
     pkRm: 041eb8f4f20ab72661af369ff3231a733672fa26f385ffb959fd1bae46bfda
     43ad55e2d573b880831381d9367417f554ce5b2134fbba5235b44db465feffc6189e
     skRm:
     12ecde2c8bc2d5d7ed2219c71f27e3943d92b344174436af833337c557c300b3
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc: 04f336578b72ad7932fe867cc4d2d44a718a318037a0ec271163699cee653fa
     805c1fec955e562663e0c2061bb96a87d78892bff0cc0bad7906c2d998ebe1a7246
     shared_secret:
     ac4f260dce4db6bf45435d9c92c0e11cfdd93743bd3075949975974cc2b3d79e
     key_schedule_context: 01622b72afcc3795841596c67ea74400ca3b029374d7d5
     640bda367c5d67b3fbeb2e986ea1c671b61cf45eec134dac0bae58ec6f63e790b140
     0b47c33038b0269c
     secret:
     858c8087a1c056db5811e85802f375bb0c19b9983204a1575de4803575d23239
     key:
     6d61cb330b7771168c8619498e753f16198aad9566d1f1c6c70e2bc1a1a8b142
     base_nonce: 0de7655fb65e1cd51a38864e
     exporter_secret:
     754ca00235b245e72d1f722a7718e7145bd113050a2aa3d89586d4cb7514bfdb

  C.5.2.1.  Encryptions















  Barnes, et al.             Expires 8 May 2026                  [Page 74]


  Internet-Draft                    HPKE                     November 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 0de7655fb65e1cd51a38864e
     ct: 21433eaff24d7706f3ed5b9b2e709b07230e2b11df1f2b1fe07b3c70d5948a53
     d6fa5c8bed194020bd9df0877b

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 0de7655fb65e1cd51a38864f
     ct: c74a764b4892072ea8c2c56b9bcd46c7f1e9ca8cb0a263f8b40c2ba59ac9c857
     033f176019562218769d3e0452

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 0de7655fb65e1cd51a38864c
     ct: dc8cd68863474d6e9cbb6a659335a86a54e036249d41acf909e738c847ff2bd3
     6fe3fcacda4ededa7032c0a220

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 0de7655fb65e1cd51a38864a
     ct: cd54a8576353b1b9df366cb0cc042e46eef6f4cf01e205fe7d47e306b2fdd90f
     7185f289a26c613ca094e3be10

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 0de7655fb65e1cd51a3886b1
     ct: 6324570c9d542c70c7e70570c1d8f4c52a89484746bf0625441890ededcc80c2
     4ef2301c38bfd34d689d19f67d

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 0de7655fb65e1cd51a38874e
     ct: 1ea6326c8098ed0437a553c466550114fb2ca1412cca7de98709b9ccdf19206e
     52c3d39180e2cf62b3e9f4baf4

  C.5.2.2.  Exported Values








  Barnes, et al.             Expires 8 May 2026                  [Page 75]


  Internet-Draft                    HPKE                     November 2025


     exporter_context:
     L: 32
     exported_value:
     530bbc2f68f078dccc89cc371b4f4ade372c9472bafe4601a8432cbb934f528d

     exporter_context: 00
     L: 32
     exported_value:
     6e25075ddcc528c90ef9218f800ca3dfe1b8ff4042de5033133adb8bd54c401d

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     6f6fbd0d1c7733f796461b3235a856cc34f676fe61ed509dfc18fa16efe6be78

  C.6.  DHKEM(P-521, HKDF-SHA512), HKDF-SHA512, AES-256-GCM

  C.6.1.  Base Setup Information

































  Barnes, et al.             Expires 8 May 2026                  [Page 76]


  Internet-Draft                    HPKE                     November 2025


     mode: 0
     kem_id: 18
     kdf_id: 3
     aead_id: 2
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE: 7f06ab8215105fc46aceeb2e3dc5028b44364f960426eb0d8e4026c2f8b5d7
     e7a986688f1591abf5ab753c357a5d6f0440414b4ed4ede71317772ac98d9239f709
     04
     pkEm: 040138b385ca16bb0d5fa0c0665fbbd7e69e3ee29f63991d3e9b5fa740aab8
     900aaeed46ed73a49055758425a0ce36507c54b29cc5b85a5cee6bae0cf1c21f2731
     ece2013dc3fb7c8d21654bb161b463962ca19e8c654ff24c94dd2898de12051f1ed0
     692237fb02b2f8d1dc1c73e9b366b529eb436e98a996ee522aef863dd5739d2f29b0
     skEm: 014784c692da35df6ecde98ee43ac425dbdd0969c0c72b42f2e708ab9d5354
     15a8569bdacfcc0a114c85b8e3f26acf4d68115f8c91a66178cdbd03b7bcc5291e37
     4b
     ikmR: 2ad954bbe39b7122529f7dde780bff626cd97f850d0784a432784e69d86ecc
     aade43b6c10a8ffdb94bf943c6da479db137914ec835a7e715e36e45e29b587bab3b
     f1
     pkRm: 0401b45498c1714e2dce167d3caf162e45e0642afc7ed435df7902ccae0e84
     ba0f7d373f646b7738bbbdca11ed91bdeae3cdcba3301f2457be452f271fa6837580
     e661012af49583a62e48d44bed350c7118c0d8dc861c238c72a2bda17f64704f464b
     57338e7f40b60959480c0e58e6559b190d81663ed816e523b6b6a418f66d2451ec64
     skRm: 01462680369ae375e4b3791070a7458ed527842f6a98a79ff5e0d4cbde83c2
     7196a3916956655523a6a2556a7af62c5cadabe2ef9da3760bb21e005202f7b24628
     47
     enc: 040138b385ca16bb0d5fa0c0665fbbd7e69e3ee29f63991d3e9b5fa740aab89
     00aaeed46ed73a49055758425a0ce36507c54b29cc5b85a5cee6bae0cf1c21f2731e
     ce2013dc3fb7c8d21654bb161b463962ca19e8c654ff24c94dd2898de12051f1ed06
     92237fb02b2f8d1dc1c73e9b366b529eb436e98a996ee522aef863dd5739d2f29b0
     shared_secret: 776ab421302f6eff7d7cb5cb1adaea0cd50872c71c2d63c30c4f1
     d5e43653336fef33b103c67e7a98add2d3b66e2fda95b5b2a667aa9dac7e59cc1d46
     d30e818
     key_schedule_context: 0083a27c5b2358ab4dae1b2f5d8f57f10ccccc822a4733
     26f543f239a70aee46347324e84e02d7651a10d08fb3dda739d22d50c53fbfa8122b
     aacd0f9ae5913072ef45baa1f3a4b169e141feb957e48d03f28c837d8904c3d67753
     08c3d3faa75dd64adfa44e1a1141edf9349959b8f8e5291cbdc56f62b0ed6527d692
     e85b09a4
     secret: 49fd9f53b0f93732555b2054edfdc0e3101000d75df714b98ce5aa295a37
     f1b18dfa86a1c37286d805d3ea09a20b72f93c21e83955a1f01eb7c5eead563d21e7
     key:
     751e346ce8f0ddb2305c8a2a85c70d5cf559c53093656be636b9406d4d7d1b70
     base_nonce: 55ff7a7d739c69f44b25447b
     exporter_secret: e4ff9dfbc732a2b9c75823763c5ccc954a2c0648fc6de80a585
     81252d0ee3215388a4455e69086b50b87eb28c169a52f42e71de4ca61c920e7bd24c
     95cc3f992

  C.6.1.1.  Encryptions




  Barnes, et al.             Expires 8 May 2026                  [Page 77]


  Internet-Draft                    HPKE                     November 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 55ff7a7d739c69f44b25447b
     ct: 170f8beddfe949b75ef9c387e201baf4132fa7374593dfafa90768788b7b2b20
     0aafcc6d80ea4c795a7c5b841a

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 55ff7a7d739c69f44b25447a
     ct: d9ee248e220ca24ac00bbbe7e221a832e4f7fa64c4fbab3945b6f3af0c5ecd5e
     16815b328be4954a05fd352256

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 55ff7a7d739c69f44b254479
     ct: 142cf1e02d1f58d9285f2af7dcfa44f7c3f2d15c73d460c48c6e0e506a3144ba
     e35284e7e221105b61d24e1c7a

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 55ff7a7d739c69f44b25447f
     ct: 3bb3a5a07100e5a12805327bf3b152df728b1c1be75a9fd2cb2bf5eac0cca1fb
     80addb37eb2a32938c7268e3e5

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 55ff7a7d739c69f44b254484
     ct: 4f268d0930f8d50b8fd9d0f26657ba25b5cb08b308c92e33382f369c768b558e
     113ac95a4c70dd60909ad1adc7

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 55ff7a7d739c69f44b25457b
     ct: dbbfc44ae037864e75f136e8b4b4123351d480e6619ae0e0ae437f036f2f8f1e
     f677686323977a1ccbb4b4f16a

  C.6.1.2.  Exported Values








  Barnes, et al.             Expires 8 May 2026                  [Page 78]


  Internet-Draft                    HPKE                     November 2025


     exporter_context:
     L: 32
     exported_value:
     05e2e5bd9f0c30832b80a279ff211cc65eceb0d97001524085d609ead60d0412

     exporter_context: 00
     L: 32
     exported_value:
     fca69744bb537f5b7a1596dbf34eaa8d84bf2e3ee7f1a155d41bd3624aa92b63

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     f389beaac6fcf6c0d9376e20f97e364f0609a88f1bc76d7328e9104df8477013

  C.6.2.  PSK Setup Information

     mode: 1
     kem_id: 18
     kdf_id: 3
     aead_id: 2
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE: f3ebfa9a69a924e672114fcd9e06fa9559e937f7eccce4181a2b506df53dbe
     514be12f094bb28e01de19dd345b4f7ede5ad7eaa6b9c3019592ec68eaae9a14732c
     e0
     pkEm: 040085eff0835cc84351f32471d32aa453cdc1f6418eaaecf1c2824210eb1d
     48d0768b368110fab21407c324b8bb4bec63f042cfa4d0868d19b760eb4beba1bff7
     93b30036d2c614d55730bd2a40c718f9466faf4d5f8170d22b6df98dfe0c067d02b3
     49ae4a142e0c03418f0a1479ff78a3db07ae2c2e89e5840f712c174ba2118e90fdcb
     skEm: 012e5cfe0daf5fe2a1cd617f4c4bae7c86f1f527b3207f115e262a98cc6526
     8ec88cb8645aec73b7aa0a472d0292502d1078e762646e0c093cf873243d12c39915
     f6
     ikmR: a2a2458705e278e574f835effecd18232f8a4c459e7550a09d44348ae5d3b1
     ea9d95c51995e657ad6f7cae659f5e186126a471c017f8f5e41da9eba74d4e0473e1
     79
     pkRm: 04006917e049a2be7e1482759fb067ddb94e9c4f7f5976f655088dec452466
     14ff924ed3b385fc2986c0ecc39d14f907bf837d7306aada59dd5889086125ecd038
     ead400603394b5d81f89ebfd556a898cc1d6a027e143d199d3db845cb91c5289fb26
     c5ff80832935b0e8dd08d37c6185a6f77683347e472d1edb6daa6bd7652fea628fae
     skRm: 011bafd9c7a52e3e71afbdab0d2f31b03d998a0dc875dd7555c63560e142bd
     e264428de03379863b4ec6138f813fa009927dc5d15f62314c56d4e7ff2b485753eb
     72
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc: 040085eff0835cc84351f32471d32aa453cdc1f6418eaaecf1c2824210eb1d4
     8d0768b368110fab21407c324b8bb4bec63f042cfa4d0868d19b760eb4beba1bff79
     3b30036d2c614d55730bd2a40c718f9466faf4d5f8170d22b6df98dfe0c067d02b34



  Barnes, et al.             Expires 8 May 2026                  [Page 79]


  Internet-Draft                    HPKE                     November 2025


     9ae4a142e0c03418f0a1479ff78a3db07ae2c2e89e5840f712c174ba2118e90fdcb
     shared_secret: 0d52de997fdaa4797720e8b1bebd3df3d03c4cf38cc8c1398168d
     36c3fc7626428c9c254dd3f9274450909c64a5b3acbe45e2d850a2fd69ac0605fe5c
     8a057a5
     key_schedule_context: 0124497637cf18d6fbcc16e9f652f00244c981726f293b
     b7819861e85e50c94f0be30e022ab081e18e6f299fd3d3d976a4bc590f85bc7711bf
     ce32ee1a7fb1c154ef45baa1f3a4b169e141feb957e48d03f28c837d8904c3d67753
     08c3d3faa75dd64adfa44e1a1141edf9349959b8f8e5291cbdc56f62b0ed6527d692
     e85b09a4
     secret: 2cf425e26f65526afc0634a3dba4e28d980c1015130ce07c2ac7530d7a39
     1a75e5a0db428b09f27ad4d975b4ad1e7f85800e03ffeea35e8cf3fe67b18d4a1345
     key:
     f764a5a4b17e5d1ffba6e699d65560497ebaea6eb0b0d9010a6d979e298a39ff
     base_nonce: 479afdf3546ddba3a9841f38
     exporter_secret: 5c3d4b65a13570502b93095ef196c42c8211a4a188c4590d358
     63665c705bb140ecba6ce9256be3fad35b4378d41643867454612adfd0542a684b61
     799bf293f

  C.6.2.1.  Encryptions
































  Barnes, et al.             Expires 8 May 2026                  [Page 80]


  Internet-Draft                    HPKE                     November 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 479afdf3546ddba3a9841f38
     ct: de69e9d943a5d0b70be3359a19f317bd9aca4a2ebb4332a39bcdfc97d5fe62f3
     a77702f4822c3be531aa7843a1

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 479afdf3546ddba3a9841f39
     ct: 77a16162831f90de350fea9152cfc685ecfa10acb4f7994f41aed43fa5431f23
     82d078ec88baec53943984553e

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 479afdf3546ddba3a9841f3a
     ct: f1d48d09f126b9003b4c7d3fe6779c7c92173188a2bb7465ba43d899a6398a33
     3914d2bb19fd769d53f3ec7336

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 479afdf3546ddba3a9841f3c
     ct: 829b11c082b0178082cd595be6d73742a4721b9ac05f8d2ef8a7704a53022d82
     bd0d8571f578c5c13b99eccff8

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 479afdf3546ddba3a9841fc7
     ct: a3ee291e20f37021e82df14d41f3fbe98b27c43b318a36cacd8471a3b1051ab1
     2ee055b62ded95b72a63199a3f

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 479afdf3546ddba3a9841e38
     ct: eecc2173ce1ac14b27ee67041e90ed50b7809926e55861a579949c07f6d26137
     bf9cf0d097f60b5fd2fbf348ec

  C.6.2.2.  Exported Values








  Barnes, et al.             Expires 8 May 2026                  [Page 81]


  Internet-Draft                    HPKE                     November 2025


     exporter_context:
     L: 32
     exported_value:
     62691f0f971e34de38370bff24deb5a7d40ab628093d304be60946afcdb3a936

     exporter_context: 00
     L: 32
     exported_value:
     76083c6d1b6809da088584674327b39488eaf665f0731151128452e04ce81bff

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     0c7cfc0976e25ae7680cf909ae2de1859cd9b679610a14bec40d69b91785b2f6

  C.7.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, Export-Only AEAD

  C.7.1.  Base Setup Information

































  Barnes, et al.             Expires 8 May 2026                  [Page 82]


  Internet-Draft                    HPKE                     November 2025


     mode: 0
     kem_id: 32
     kdf_id: 1
     aead_id: 65535
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     55bc245ee4efda25d38f2d54d5bb6665291b99f8108a8c4b686c2b14893ea5d9
     pkEm:
     e5e8f9bfff6c2f29791fc351d2c25ce1299aa5eaca78a757c0b4fb4bcd830918
     skEm:
     095182b502f1f91f63ba584c7c3ec473d617b8b4c2cec3fad5af7fa6748165ed
     ikmR:
     683ae0da1d22181e74ed2e503ebf82840deb1d5e872cade20f4b458d99783e31
     pkRm:
     194141ca6c3c3beb4792cd97ba0ea1faff09d98435012345766ee33aae2d7664
     skRm:
     33d196c830a12f9ac65d6e565a590d80f04ee9b19c83c87f2c170d972a812848
     enc:
     e5e8f9bfff6c2f29791fc351d2c25ce1299aa5eaca78a757c0b4fb4bcd830918
     shared_secret:
     e81716ce8f73141d4f25ee9098efc968c91e5b8ce52ffff59d64039e82918b66
     key_schedule_context: 009bd09219212a8cf27c6bb5d54998c5240793a70ca0a8
     92234bd5e082bc619b6a3f4c22aa6d9a0424c2b4292fdf43b8257df93c2f6adbf6dd
     c9c64fee26bdd292
     secret:
     04d64e0620aa047e9ab833b0ebcd4ff026cefbe44338fd7d1a93548102ee01af
     key:
     base_nonce:
     exporter_secret:
     79dc8e0509cf4a3364ca027e5a0138235281611ca910e435e8ed58167c72f79b

  C.7.1.1.  Exported Values

     exporter_context:
     L: 32
     exported_value:
     7a36221bd56d50fb51ee65edfd98d06a23c4dc87085aa5866cb7087244bd2a36

     exporter_context: 00
     L: 32
     exported_value:
     d5535b87099c6c3ce80dc112a2671c6ec8e811a2f284f948cec6dd1708ee33f0

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     ffaabc85a776136ca0c378e5d084c9140ab552b78f039d2e8775f26efff4c70e




  Barnes, et al.             Expires 8 May 2026                  [Page 83]


  Internet-Draft                    HPKE                     November 2025


  C.7.2.  PSK Setup Information

     mode: 1
     kem_id: 32
     kdf_id: 1
     aead_id: 65535
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     c51211a8799f6b8a0021fcba673d9c4067a98ebc6794232e5b06cb9febcbbdf5
     pkEm:
     d3805a97cbcd5f08babd21221d3e6b362a700572d14f9bbeb94ec078d051ae3d
     skEm:
     1d72396121a6a826549776ef1a9d2f3a2907fc6a38902fa4e401afdb0392e627
     ikmR:
     5e0516b1b29c0e13386529da16525210c796f7d647c37eac118023a6aa9eb89a
     pkRm:
     d53af36ea5f58f8868bb4a1333ed4cc47e7a63b0040eb54c77b9c8ec456da824
     skRm:
     98f304d4ecb312689690b113973c61ffe0aa7c13f2fbe365e48f3ed09e5a6a0c
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc:
     d3805a97cbcd5f08babd21221d3e6b362a700572d14f9bbeb94ec078d051ae3d
     shared_secret:
     024573db58c887decb4c57b6ed39f2c9a09c85600a8a0ecb11cac24c6aaec195
     key_schedule_context: 01446fb1fe2632a0a338f0a85ed1f3a0ac475bdea2cd72
     f8c713b3a46ee737379a3f4c22aa6d9a0424c2b4292fdf43b8257df93c2f6adbf6dd
     c9c64fee26bdd292
     secret:
     638b94532e0d0bf812cf294f36b97a5bdcb0299df36e22b7bb6858e3c113080b
     key:
     base_nonce:
     exporter_secret:
     04261818aeae99d6aba5101bd35ddf3271d909a756adcef0d41389d9ed9ab153

  C.7.2.1.  Exported Values














  Barnes, et al.             Expires 8 May 2026                  [Page 84]


  Internet-Draft                    HPKE                     November 2025


     exporter_context:
     L: 32
     exported_value:
     be6c76955334376aa23e936be013ba8bbae90ae74ed995c1c6157e6f08dd5316

     exporter_context: 00
     L: 32
     exported_value:
     1721ed2aa852f84d44ad020c2e2be4e2e6375098bf48775a533505fd56a3f416

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     7c9d79876a288507b81a5a52365a7d39cc0fa3f07e34172984f96fec07c44cba

  Authors' Addresses

     Richard L. Barnes
     Cisco
     Email: rlb@ipv.sx


     Karthik Bhargavan
     Inria
     Email: karthikeyan.bhargavan@inria.fr


     Benjamin Lipp
     Inria
     Email: ietf@benjaminlipp.de


     Christopher A. Wood
     Email: caw@heapingbits.net

















  Barnes, et al.             Expires 8 May 2026                  [Page 85]


name: draft-ietf-lamps-rfc7030-csrattrs
rev: 23
title: Clarification and enhancement of RFC7030 CSR Attributes definition
time: 2026-01-06T19:11:51Z
group_uri: /api/v1/group/group/2164/
expires: 2025-12-31T00:06:48Z
ad: /api/v1/person/person/123703/
shepherd: /api/v1/person/email/housley@vigilsec.com/
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.886213+00:00
source: ietf
abstract:
  This document updates RFC7030, Enrollment over Secure Transport
     (EST), clarifying how the Certificate Signiing Request (CSR)
     Attributes Response can be used by an EST server to specify both CSR
     attribute Object IDs (OID) and also CSR attribute values, in
     particular X.509 extension values, that the server expects the client
     to include in subsequent CSR request.  RFC9148 is derived from
     RFC7030, and it is also updated.

     RFC7030 (EST) is ambiguous in its specification of the CSR Attributes
     Response.  This has resulted in implementation challenges and
     implementor confusion.  As a result, there was not universal
     understanding of what was specified.  This document clarifies the
     encoding rules.

     This document therefore also provides a new straightforward approach:
     using a template for CSR contents that may be partially filled in by
     the server.  This also allows an EST server to specify a subject
     Distinguished Name (DN).

states:
  ["/api/v1/doc/state/3/", "/api/v1/doc/state/108/", "/api/v1/doc/state/154/", "/api/v1/doc/state/115/", "/api/v1/doc/state/7/", "/api/v1/doc/state/44/"]

full_text:
  LAMPS Working Group                                   M. Richardson, Ed.
  Internet-Draft                                  Sandelman Software Works
  Updates: 70309148 (if approved)                                 O. Friel
  Intended status: Standards Track                                   Cisco
  Expires: 30 December 2025                                  D. von Oheimb
                                                                   Siemens
                                                                D. Harkins
                                                     The Industrial Lounge
                                                              28 June 2025


     Clarification and enhancement of RFC7030 CSR Attributes definition
                    draft-ietf-lamps-rfc7030-csrattrs-23

  Abstract

     This document updates RFC7030, Enrollment over Secure Transport
     (EST), clarifying how the Certificate Signiing Request (CSR)
     Attributes Response can be used by an EST server to specify both CSR
     attribute Object IDs (OID) and also CSR attribute values, in
     particular X.509 extension values, that the server expects the client
     to include in subsequent CSR request.  RFC9148 is derived from
     RFC7030, and it is also updated.

     RFC7030 (EST) is ambiguous in its specification of the CSR Attributes
     Response.  This has resulted in implementation challenges and
     implementor confusion.  As a result, there was not universal
     understanding of what was specified.  This document clarifies the
     encoding rules.

     This document therefore also provides a new straightforward approach:
     using a template for CSR contents that may be partially filled in by
     the server.  This also allows an EST server to specify a subject
     Distinguished Name (DN).

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.







  Richardson, et al.      Expires 30 December 2025                [Page 1]


  Internet-Draft                  CSRAttrs                       June 2025


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 30 December 2025.

  Copyright Notice

     Copyright (c) 2025 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, as 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 are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  CSR Attributes Handling . . . . . . . . . . . . . . . . . . .   4
       3.1.  Extensions to RFC 7030 section 2.6  . . . . . . . . . . .   4
       3.2.  Extensions to RFC 7030 section 4.5.2  . . . . . . . . . .   4
       3.3.  Update to RFC9148 . . . . . . . . . . . . . . . . . . . .   6
       3.4.  Use of CSR templates  . . . . . . . . . . . . . . . . . .   6
     4.  Co-existence with existing implementations  . . . . . . . . .  11
     5.  Examples using the original RFC 7030 approach . . . . . . . .  11
       5.1.  Require an RFC8994/ACP subjectAltName with specific
             otherName . . . . . . . . . . . . . . . . . . . . . . . .  11
         5.1.1.  Base64 encoded example  . . . . . . . . . . . . . . .  11
         5.1.2.  ASN.1 DUMP output . . . . . . . . . . . . . . . . . .  11
       5.2.  RFC7030 original example  . . . . . . . . . . . . . . . .  13
         5.2.1.  Base64 encoded example  . . . . . . . . . . . . . . .  13
         5.2.2.  ASN.1 DUMP output . . . . . . . . . . . . . . . . . .  13
       5.3.  Require a specific subjectAltName extension . . . . . . .  14
         5.3.1.  Base64 encoded example  . . . . . . . . . . . . . . .  14
         5.3.2.  ASN.1 DUMP output . . . . . . . . . . . . . . . . . .  14
       5.4.  Require a public key of a specific size . . . . . . . . .  15
         5.4.1.  Base64 encoded example  . . . . . . . . . . . . . . .  15
         5.4.2.  ASN.1 DUMP output . . . . . . . . . . . . . . . . . .  16
       5.5.  Require a public key of a specific curve  . . . . . . . .  16
         5.5.1.  Base64 encoded example  . . . . . . . . . . . . . . .  16
         5.5.2.  ASN.1 DUMP output . . . . . . . . . . . . . . . . . .  16



  Richardson, et al.      Expires 30 December 2025                [Page 2]


  Internet-Draft                  CSRAttrs                       June 2025


       5.6.  Require specific extensions and attributes  . . . . . . .  17
         5.6.1.  Base64 encoded example  . . . . . . . . . . . . . . .  17
         5.6.2.  ASN.1 DUMP output . . . . . . . . . . . . . . . . . .  17
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
       6.1.  Identity and Privacy Considerations . . . . . . . . . . .  18
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  19
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  20
     Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .  22
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

  1.  Introduction

     This document updates RFC7030 Enrollment over Secure Transport (EST)
     and clarifies how the Certificate Signing Request (CSR) Attributes
     Response can be used by an EST server to specify both CSR attribute
     OIDs and also CSR attribute values.  In particular, the server needs
     to be able to specify X.509 extension values that it expects the
     client to include in the subsequent CSR.

     Enrollment over Secure Transport [RFC7030] (EST) has been used in a
     wide variety of applications.  In particular, [RFC8994] and [RFC8995]
     describe a way to use it in order to build out an Autonomic Control
     Plane (ACP) [RFC8368].

     When bootstrapping the ACP, there is a requirement that each node be
     given a very specific subjectAltName.  In [RFC8994], the ACP
     specification, the EST server is specified to make use of the CSR
     Attributes ("/csrattrs") resource (specified in [RFC7030],
     Section 2.6) to convey to the EST client the actual subjectAltName
     that needs to go into its CSR and thus ultimately into its End Entity
     certificate.

     As a result of some implementation challenges, it came to light that
     this particular way of using the CSR attributes was not universally
     agreed upon, and it was suggested that it went contrary to [RFC7030],
     Section 2.6.

     [RFC7030], Section 2.6 says that the CSR attributes "can provide
     additional descriptive information that the EST server cannot access
     itself".  This is extended to describe how the EST server can provide
     values that it demands be used.

     After significant discussion, it has been determined that Section 4.5
     of [RFC7030] specification is sufficiently difficult to read and
     ambiguous to interpret that clarification is needed.



  Richardson, et al.      Expires 30 December 2025                [Page 3]


  Internet-Draft                  CSRAttrs                       June 2025


     Also, [RFC7030], Section 4.5.2 is extended to clarify the use of the
     existing ASN.1 syntax [X.680][X.690].

     This covers all uses and is fully backward compatible with existing
     use, including addressesing the needs of [RFC8994] and [RFC8995].

  2.  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.

  3.  CSR Attributes Handling

  3.1.  Extensions to RFC 7030 section 2.6

     Replace the second paragraph with the following text:

     These attributes can provide additional information that
     the EST server cannot access itself, such as the Media Access Control
     (MAC) address of an interface of the EST client. The EST server can
     also provide concrete values that it tells the client to include in
     the CSR, such as a specific X.509 Subject Alternative Name extension.
     Moreover, these attributes can indicate the type of the included
     public key or which crypto algorithms to use for the self-signature,
     such as a specific elliptic curve or a specific hash function that
     the client is expected to use when generating the CSR.

  3.2.  Extensions to RFC 7030 section 4.5.2

     The ASN.1 syntax for CSR Attributes as defined in EST [RFC7030],
     Section 4.5.2 is as follows:

        CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID

        AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }

        Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
             type   ATTRIBUTE.&id({IOSet}),
             values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }

     This remains unchanged, such that bits-on-the-wire compatibility is
     maintained.






  Richardson, et al.      Expires 30 December 2025                [Page 4]


  Internet-Draft                  CSRAttrs                       June 2025


     Key parts that were unclear were which OID to use in the 'type' field
     and that the 'values' field can contain an entire sequence of X.509
     extensions.

     The OID to use for such attributes in the 'type' field MUST be id-
     ExtensionReq, which has the value 1.2.840.113549.1.9.14.  Note that
     is the same as pkcs-9-at-extensionRequest defined in PKCS#9
     [RFC2985].  There MUST be only one such attribute.

     The 'values' field of this attribute MUST contain a set with exactly
     one element, and this element MUST be of type Extensions, as per
     Section 4.1 of [RFC5280]:

        Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

        Extension  ::=  SEQUENCE  {
             extnID      OBJECT IDENTIFIER,
             critical    BOOLEAN DEFAULT FALSE,
             extnValue   OCTET STRING
                         -- contains the DER encoding of an ASN.1 value
                         -- corresponding to the extension type identified
                         -- by extnID
             }

     An Extension comprises the OID of the specific X.509 extension
     (extnID), optionally the 'critical' bit, and the extension value
     (extnValue).

     An Extensions structure, which is a sequence of elements of type
     Extension, MUST NOT include more than one element with a particular
     extnID.

     When not using the template-based approach of Section 3.4, specifying
     the requirement for a public key of a specific type and optionally
     its size and other parameters MUST be done as follows: Include
     exactly one Attribute with the type field being the OID specifying
     the type of the key, such as ecPublicKey or rsaEncryption.  The
     'values' field MAY be empty to indicate no further requirements on
     the key.  Otherwise, it MUST contain suitable parameters for the
     given key type, such as a singleton set containing the OID of an EC
     curve such as secp384r1 or containing an integer value for the RSA
     key size such as 4096.  Many examples for this are given in
     Section 5.








  Richardson, et al.      Expires 30 December 2025                [Page 5]


  Internet-Draft                  CSRAttrs                       June 2025


  3.3.  Update to RFC9148

     The updates to EST in this THISRFC equally apply when using CoAP as a
     transport as described in [RFC9148].  THISRFC therefore adds the
     following paragraph after the second paragraph of [RFC9148],
     Section 1:

        |  RFC EDITOR: Please replace THISRFC with the RFC number for this
        |  document.

     EST over CoAP as specified in {{RFC9148}} applies unchanged to
     {{RFC7030}} updated by THISRFC.  Hence, all references to {{RFC7030}}
     in {{RFC9148}} are assumed to indicate {{RFC7030}} updated by
     THISRFC.

  3.4.  Use of CSR templates

     Alternatively to the unstructured inclusion of CSR attributes
     specified in [RFC7030], Section 4.5.2 with its limitations and
     ambiguities, Appendix B of [RFC8295] describes an approach using a
     CSR template.  An entire CSR object is returned with various fields
     filled out, and other fields waiting to be filled in.  In that
     approach, a pKCS7PDU attribute includes a Full PKI Data content type
     [RFC5272] and that in turn includes an [RFC2986] CSR or a Certificate
     Request Message Format (CRMF) formatted request (for details see
     [RFC6268] Sections 5 or 9, respectively).

     One drawback to that approach, particularly for the CSR, is that some
     unused fields have to be included; specifically, the 'signature'
     field on the CSR is faked with an empty bit string.

     A similar method has been defined in CMP Updates [RFC9480] and the
     Lightweight CMP profile [RFC9483], Section 4.3.3, using a CSR
     template as defined for CRMF [RFC4211].  Like the approach mentioned
     before, this method does not properly deal with absent Relative
     Distinguished Name (RDN) values, as it would encode them as invalid
     empty strings.  Also encoding an absent 'subjectPublicKey' value as
     an empty BIT STRING and an absent X.509 extension value as an empty
     OCTET STRING can cause issues with strict ASN.1 parsing and decoding.

     These drawbacks are avoided as follows:

     This specification defines a new Certificate Request Information
     Template attribute for CsrAttrs (as given in Section 3.2) that is
     essentially a partially filled in PKCS#10 CSR minus the signature
     wrapper:





  Richardson, et al.      Expires 30 December 2025                [Page 6]


  Internet-Draft                  CSRAttrs                       June 2025


       CertificationRequestInfoTemplate ::= SEQUENCE {
           version       INTEGER { v1(0) } (v1, ... ),
           subject       NameTemplate OPTIONAL,
           subjectPKInfo [0] SubjectPublicKeyInfoTemplate
                                     {{ PKInfoAlgorithms }} OPTIONAL,
           attributes    [1] Attributes{{ CRIAttributes }}
       }

     Appendix A contains all detail.

     The CertificationRequestInfoTemplate closely resembles the
     CertificationRequestInfo from [RFC5912], Section 5:

       CertificationRequestInfo ::= SEQUENCE {
         version       INTEGER { v1(0) } (v1,...),
         subject       Name,
         subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
         attributes    [0] Attributes{{ CRIAttributes }}
       }

     with the following differences.

     *  The 'subject' field has been made OPTIONAL.  It MUST be present if
        the server places any requirements on the RDNs of the subject
        name; otherwise, it MUST be absent.

     *  RelativeDistinguishedNames (RDNs) in the 'subject' fields are
        allowed to have no value, which has been achieved by adding
        OPTIONAL to the 'value' field of SingleAttributeTemplate.  If the
        client is expected to provide an RDN of a certain type such as
        commonName, the respective RDN MUST be present in the 'subject'
        field; otherwise it MUST be absent.  If the server in addition
        gives an RDN value, this means that the client is expected to use
        this value for the RDN, otherwise the client is expected to fill
        in a suitable value.  The example at the end of this section has a
        'subject' field that contains both forms of RDN specifications.

       SingleAttributeTemplate {ATTRIBUTE:AttrSet} ::= SEQUENCE {
           type      ATTRIBUTE.&id({AttrSet}),
           value     ATTRIBUTE.&Type({AttrSet}{@type}) OPTIONAL
       }

     *  The 'subjectPKInfo' field has been made OPTIONAL.  The field MUST
        be absent if the server places no requirements on the key.
        Otherwise, it MUST be present, and the 'algorithm' field specifies
        the type of the key pair the client is expected to use.





  Richardson, et al.      Expires 30 December 2025                [Page 7]


  Internet-Draft                  CSRAttrs                       June 2025


     *  The 'subjectPublicKey' field contained in
        SubjectPublicKeyInfoTemplate has been made OPTIONAL because
        usually it is not needed.  In case the server requires use of an
        RSA key and needs to specify its size, the field MUST be present
        and contain a placeholder public key value of the desired RSA
        modulus length.  Otherwise, the subjectPublicKey MUST be absent.

       SubjectPublicKeyInfoTemplate{PUBLIC-KEY:IOSet} ::= SEQUENCE {
           algorithm        AlgorithmIdentifier{PUBLIC-KEY, {IOSet}},
           subjectPublicKey BIT STRING OPTIONAL
       }

     *  A new OID id-aa-extensionReqTemplate and the related
        ExtensionTemplate structure is defined where the 'extnValue' field
        has been made OPTIONAL.  This is only needed to enable specifying
        partial extensions with values to be filled in by the client;
        otherwise the id-ExtensionReq OID and the respective value of type
        ExtensionReq MUST be used for specifying requirements on X.509
        extensions.

     For each extension of type Extension or ExtensionTemplate provided by
     the server, the client is expected to include an extension of the
     type given by the extnID.  If the 'critical' field is present, the
     client SHOULD use it in the extension as well.  If the 'extnValue' is
     present (which is always the case when type Extension is used), the
     client SHOULD use the given extension value in its CSR.  When the
     type ExtensionTemplate is used, the 'extnValue' can be absent, and
     then the client SHOULD provide an extension value in an Extension
     with the given extnID.  For instance, if the server includes an
     ExtensionTemplate with the extnID 'subjectAltName' but without an
     extnValue, the client SHOULD include a SAN extension with a suitable
     value.

     In case the server includes an ExtensionTemplate with the extnID
     'subjectAltName' and a partially filled in extnValue, such as a
     'directoryName' choice containing the NULL-DN (i.e., an empty
     sequence of RDNs) or the 'iPAddress' choice with an empty OCTET
     STRING, this means that the client SHOULD fill in the respective
     GeneralName value.












  Richardson, et al.      Expires 30 December 2025                [Page 8]


  Internet-Draft                  CSRAttrs                       June 2025


     ExtensionTemplate {EXTENSION:ExtensionSet} ::= SEQUENCE {
        extnID      EXTENSION.&id({ExtensionSet}),
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING (CONTAINING
                    EXTENSION.&ExtnType({ExtensionSet}{@extnID})) OPTIONAL
                    --  contains the DER encoding of the ASN.1 value
                    --  corresponding to the extension type identified
                    --  by extnID when present
     }

     The 'version' field of the CertificationRequestInfoTemplate MUST
     contain v1 (0).

     The 'attributes' field MUST NOT contain multiple id-aa-
     extensionReqTemplate attributes and MUST NOT contain both id-
     ExtensionReq and id-aa-extensionReqTemplate attributes.

     The 'values' field of an id-aa-extensionReqTemplate attribute MUST
     contain a set with exactly one element, and this element MUST be of
     type ExtensionTemplate.

     Suppose the server requires that the CSR will contain:

     *  the 'subject' field with a common name to be filled in by the EE
        and two organizational unit names with given values "myDept" and
        "myGroup",

     *  the 'publicKey' field contains an Elliptic Curve Cryptography
        (ECC) key on curve secp256r1,

     *  the 'subjectAltName' extension with two entries; one DNS entry
        with name "www.myServer.com" and IP entry that is empty for the IP
        address to be filled in.

     *  the 'keyUsage' extension marked critical with the value
        digitalSignature and keyAgreement, and

     *  the 'extKeyUsage' extension with value to be filled in by the EE.

     Then the CertificationRequestInfo structure constructed by the server
     will be as follows:

     SEQUENCE {
       INTEGER 0
       SEQUENCE {
         SET {
           SEQUENCE {
             OBJECT IDENTIFIER commonName (2 5 4 3)



  Richardson, et al.      Expires 30 December 2025                [Page 9]


  Internet-Draft                  CSRAttrs                       June 2025


             }
           }
         SET {
           SEQUENCE {
             OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
             UTF8String "myDept"
             }
           }
         SET {
           SEQUENCE {
             OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
             UTF8String "myGroup"
             }
           }
         }
       [0] {
         SEQUENCE {
           OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
           OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7)
           }
         }
       [1] {
         SEQUENCE {
           OBJECT IDENTIFIER id-aa-extensionReqTemplate
                             (1 2 840 113549 1 9 TBD3)
           SET {
             SEQUENCE {
               SEQUENCE {
                 OBJECT IDENTIFIER subjectAltName (2 5 29 17)
                 OCTET STRING, encapsulates {
                   SEQUENCE {
                     [2] "www.myServer.com"
                     [7] ""
                     }
                   }
                 }
               SEQUENCE {
                 OBJECT IDENTIFIER keyUsage (2 5 29 15)
                 BOOLEAN TRUE
                 OCTET STRING, encapsulates {
                   BIT STRING 3 unused bits
                     "10001"B
                   }
                 }
               SEQUENCE {
                 OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
                 }
               }



  Richardson, et al.      Expires 30 December 2025               [Page 10]


  Internet-Draft                  CSRAttrs                       June 2025


             }
           }
         }
       }

  4.  Co-existence with existing implementations

     EST servers with legacy clients MAY continue to use the [RFC7030]-
     style unstructured list of attribute/value pairs, and MAY also
     include the template style described in Section 3.4 for newer
     clients.  Clients which understand both MUST use the template only,
     and ignore all other CSRattrs elements.  Older clients will ignore
     the new CertificationRequestInfoTemplate element.

  5.  Examples using the original RFC 7030 approach

     Each example has a high-level (English) explanation of what is
     expected.  Some mapping back to the Attribute and Extension
     definitions above are included.  The base64 DER encoding is then
     shown.  The output of "dumpasn1" [dumpasn1] is then provided to
     detail what the contents are.

  5.1.  Require an RFC8994/ACP subjectAltName with specific otherName

     A single subjectAltName extension is specified in a single [RFC7030]
     CsrAttrs attribute with OID 'id-ExtensionReq' indicating type
     Extensions.  This is what might be created by an [RFC8995] Registrar
     that is asking for [RFC8994] AcpNodeName with format 'otherNames'.

  5.1.1.  Base64 encoded example

     The Base64:

     MGgwZgYJKoZIhvcNAQkOMVkwVzBVBgNVHREBAf8ESzBJoEcG
     CCsGAQUFBwgKoDsWOXJmYzg5OTQrZmQ3MzlmYzIzYzM0NDAx
     MTIyMzM0NDU1MDAwMDAwMDArQGFjcC5leGFtcGxlLmNvbQ==

  5.1.2.  ASN.1 DUMP output

     There is a single subjectAltName Extension with an Attribute with
     Extension type.










  Richardson, et al.      Expires 30 December 2025               [Page 11]


  Internet-Draft                  CSRAttrs                       June 2025


         <30 68>
       0 104: SEQUENCE {
         <30 66>
       2 102:   SEQUENCE {
         <06 09>
       4   9:     OBJECT IDENTIFIER
            :       extensionRequest (1 2 840 113549 1 9 14)
            :       (PKCS #9 via CRMF)
         <31 59>
      15  89:     SET {
         <30 57>
      17  87:       SEQUENCE {
         <30 55>
      19  85:         SEQUENCE {
         <06 03>
      21   3:           OBJECT IDENTIFIER
            :             subjectAltName (2 5 29 17)
            :             (X.509 extension)
         <01 01>
      26   1:           BOOLEAN TRUE
         <04 4B>
      29  75:           OCTET STRING, encapsulates {
         <30 49>
      31  73:             SEQUENCE {
         <A0 47>
      33  71:               [0] {
         <06 08>
      35   8:                 OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 10'
         <A0 3B>
      45  59:                 [0] {
         <16 39>
      47  57:                   IA5String
            :                   'rfc8994+fd739fc23c34401122334455'
            :                   '00000000+@acp.example.com'
            :                   }
            :                 }
            :               }
            :             }
            :           }
            :         }
            :       }
            :     }
            :   }








  Richardson, et al.      Expires 30 December 2025               [Page 12]


  Internet-Draft                  CSRAttrs                       June 2025


  5.2.  RFC7030 original example

     In this example, taken from [RFC7030], Section 4.5.2, a few different
     attributes are included.  The original encoding of the 'macAddress'
     part in the example is NOT CORRECT.  It was not aligned with the
     definition of the Extension Request attribute as specified in
     Section 5.4.2 of [RFC2985].  The revised encoding given here does not
     use an 'id-ExtensionReq' attribute because the MAC Address is not an
     X.509 certificate extension by itself and because the server provides
     its OID without a value, which is not allowed syntactically within a
     structure of type 'Extension'.

  5.2.1.  Base64 encoded example

     The Base64:

     MDIGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiBgcr
     BgEBAQEWBggqhkjOPQQDAw==

  5.2.2.  ASN.1 DUMP output

     The CsrAttrs structure contains:

     1.  The challengePassword attribute is included to indicate that the
         CSR should include this value.

     2.  An ecPublicKey OID is provided with the value secp384r1 to
         indicate what kind of public key should be submitted.

     3.  The macAddress OID 1.3.6.1.1.1.1.22 is included to indicate that
         the CSR is expected to include (in a subjectDirectoryAttributes
         extension) a MAC address value.

     4.  The ecdsaWithSHA384 OID is included to indicate what kind of hash
         is expected to be used for the self-signature in the PKCS#10 CSR.
















  Richardson, et al.      Expires 30 December 2025               [Page 13]


  Internet-Draft                  CSRAttrs                       June 2025


         <30 32>
       0  50: SEQUENCE {
         <06 09>
       2   9:   OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
            :     (PKCS #9)
         <30 12>
      13  18:   SEQUENCE {
         <06 07>
      15   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
            :       (ANSI X9.62 public key type)
         <31 07>
      24   7:     SET {
         <06 05>
      26   5:       OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
            :         (SECG (Certicom) named elliptic curve)
            :       }
            :     }
         <06 07>
      33   7:   OBJECT IDENTIFIER '1 3 6 1 1 1 1 22'
         <06 08>
      42   8:   OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
            :     (ANSI X9.62 ECDSA algorithm with SHA384)
            :   }

  5.3.  Require a specific subjectAltName extension

     This example is the same as the previous one except that instead of
     the OID for a macAddress, a subjectAltName is specified as the only
     Extension element.

  5.3.1.  Base64 encoded example

     The Base64:

     MEUGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAjBgkq
     hkiG9w0BCRQGCgmSJomT8ixkAQUGA1UEBQYIKoZIzj0EAwQ=

  5.3.2.  ASN.1 DUMP output

     The CsrAttrs structure contains:

     1.  The challengePassword attribute is included to indicate that the
         CSR should include this value.

     2.  An ecPublicKey OID is provided with the value secp521r1 to
         indicate what kind of public key should be submitted.





  Richardson, et al.      Expires 30 December 2025               [Page 14]


  Internet-Draft                  CSRAttrs                       June 2025


     3.  An extensionRequest container with a subjectAltName value
         containing the name potato@example.com

     4.  The ecdsaWithSHA512 OID is included to indicate the SHA-512 hash
         is expected to be used for the self-signature in the PKCS#10 CSR.

      <30 45>
    0  69: SEQUENCE {
      <06 09>
    2   9:   OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
         :     (PKCS #9)
      <30 12>
   13  18:   SEQUENCE {
      <06 07>
   15   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
         :       (ANSI X9.62 public key type)
      <31 07>
   24   7:     SET {
      <06 05>
   26   5:       OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
         :         (SECG (Certicom) named elliptic curve)
         :       }
         :     }
      <06 09>
   33   9:   OBJECT IDENTIFIER friendlyName (for PKCS #12) (1 2 840 113549 1 9 20)
         :     (PKCS #9 via PKCS #12)
      <06 0A>
   44  10:   OBJECT IDENTIFIER '0 9 2342 19200300 100 1 5'
      <06 03>
   56   3:   OBJECT IDENTIFIER serialNumber (2 5 4 5)
         :     (X.520 DN component)
      <06 08>
   61   8:   OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
         :     (ANSI X9.62 ECDSA algorithm with SHA512)
         :   }

  5.4.  Require a public key of a specific size

     (RFC-editor please remove: Example ref Harkins01)

     The CSR requires an RSA public key of a specific size.

  5.4.1.  Base64 encoded example

     The Base64:

     MCkGCSqGSIb3DQEJBzARBgkqhkiG9w0BAQExBAICEAAGCSqG
     SIb3DQEBCw==



  Richardson, et al.      Expires 30 December 2025               [Page 15]


  Internet-Draft                  CSRAttrs                       June 2025


  5.4.2.  ASN.1 DUMP output

     Provide a CSR with an RSA key that's 4096 bits and use SHA256 as the
     hash algorithm within the signature.

         <30 29>
       0  41: SEQUENCE {
         <06 09>
       2   9:   OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
            :     (PKCS #9)
         <30 11>
      13  17:   SEQUENCE {
         <06 09>
      15   9:     OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
            :       (PKCS #1)
         <31 04>
      26   4:     SET {
         <02 02>
      28   2:       INTEGER 4096
            :       }
            :     }
         <06 09>
      32   9:   OBJECT IDENTIFIER sha256WithRSAEncryption
                                  (1 2 840 113549 1 1 11)
            :     (PKCS #1)
            :   }

  5.5.  Require a public key of a specific curve

     (RFC-editor please remove: Example ref Harkins02)

     The CSR requires an ECC public key with a specific curve.

  5.5.1.  Base64 encoded example

     The Base64:

     MC4GCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiBgNV
     BAUGCCqGSM49BAMD

  5.5.2.  ASN.1 DUMP output

     Provide a CSR with an ECC key from p384, include your serial number,
     and use SHA384 as the hash algorithm within the signature.







  Richardson, et al.      Expires 30 December 2025               [Page 16]


  Internet-Draft                  CSRAttrs                       June 2025


         <30 2E>
       0  46: SEQUENCE {
         <06 09>
       2   9:   OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
            :     (PKCS #9)
         <30 12>
      13  18:   SEQUENCE {
         <06 07>
      15   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
            :       (ANSI X9.62 public key type)
         <31 07>
      24   7:     SET {
         <06 05>
      26   5:       OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
            :         (SECG (Certicom) named elliptic curve)
            :       }
            :     }
         <06 03>
      33   3:   OBJECT IDENTIFIER serialNumber (2 5 4 5)
            :     (X.520 DN component)
         <06 08>
      38   8:   OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
            :     (ANSI X9.62 ECDSA algorithm with SHA384)
            :   }

  5.6.  Require specific extensions and attributes

     (RFC-editor please remove: Example ref Harkins03)

     The CSR is required to have an EC key, to include a serial number, a
     friendly name, favorite drink [favoritedrink] [OID
     0.9.2342.19200300.100.1.5], and use SHA512 as the hash algorithm
     within the signature.

  5.6.1.  Base64 encoded example

     The Base64:

     MEUGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAjBgkq
     hkiG9w0BCRQGCgmSJomT8ixkAQUGA1UEBQYIKoZIzj0EAwQ=

  5.6.2.  ASN.1 DUMP output

     Provide a CSR with an EC key from sha521, include your serial number,
     friendly name, and favorite drink, and hash it with SHA512.






  Richardson, et al.      Expires 30 December 2025               [Page 17]


  Internet-Draft                  CSRAttrs                       June 2025


      <30 45>
    0  69: SEQUENCE {
      <06 09>
    2   9:   OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
         :     (PKCS #9)
      <30 12>
   13  18:   SEQUENCE {
      <06 07>
   15   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
         :       (ANSI X9.62 public key type)
      <31 07>
   24   7:     SET {
      <06 05>
   26   5:       OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
         :         (SECG (Certicom) named elliptic curve)
         :       }
         :     }
      <06 09>
   33   9:   OBJECT IDENTIFIER friendlyName (for PKCS #12) (1 2 840 113549 1 9 20)
         :     (PKCS #9 via PKCS #12)
      <06 0A>
   44  10:   OBJECT IDENTIFIER '0 9 2342 19200300 100 1 5'
      <06 03>
   56   3:   OBJECT IDENTIFIER serialNumber (2 5 4 5)
         :     (X.520 DN component)
      <06 08>
   61   8:   OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
         :     (ANSI X9.62 ECDSA algorithm with SHA512)
         :   }

  6.  Security Considerations

     The security considerations from EST [RFC7030] section 6 are
     unchanged.

  6.1.  Identity and Privacy Considerations

     An EST server may use this mechanism to instruct the EST client about
     the identities it should include in the CSR it sends as part of
     enrollment.  The client may only be aware of its IDevID Subject,
     which includes a manufacturer serial number.  The EST server can use
     this mechanism to tell the client to include a specific fully
     qualified domain name in the CSR in order to complete domain
     ownership proofs required by the CA.  Additionally, the EST server
     may deem the manufacturer serial number in an IDevID as personally
     identifiable information, and may want to specify a new random opaque
     identifier that the pledge should use in its CSR.  This may be
     desirable if the CA and EST server have different operators.



  Richardson, et al.      Expires 30 December 2025               [Page 18]


  Internet-Draft                  CSRAttrs                       June 2025


  7.  IANA Considerations

     IANA is asked to allocate three new Object Identifiers:

     *  One (TBD1) from the SMI Security for S/MIME Module Identifier
        (1.2.840.113549.1.9.16.0) registry for the ASN.1 module: id-mod-
        critemplate; see Appendix A

     *  One (TBD2) from the SMI Security for S/MIME Attributes
        (1.2.840.113549.1.9.16.2) registry for the Certification Request
        Information Template (id-aa-certificationRequestInfoTemplate)
        attribute; see Appendix A

     *  One (TBD3) SMI Security for S/MIME Attributes
        (1.2.840.113549.1.9.16.2) registry for the extension request
        template (id-aa-extensionReqTemplate) attribute; see Appendix A

  8.  Acknowledgments

     Corey Bonnell crafted example02 using a different tool, and this
     helped debug other running code.

     Carl Wallace provided major parts of the
     CertificationRequestInfoTemplate syntax declaration.

     Russ Housley did many reviews of the ASN.1 and suggested many fixes.

     Deb Cooley did the usual Area Director Review.

  9.  References

  9.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
                Request Syntax Specification Version 1.7", RFC 2986,
                DOI 10.17487/RFC2986, November 2000,
                <https://www.rfc-editor.org/rfc/rfc2986>.

     [RFC5911]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for
                Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
                DOI 10.17487/RFC5911, June 2010,
                <https://www.rfc-editor.org/rfc/rfc5911>.




  Richardson, et al.      Expires 30 December 2025               [Page 19]


  Internet-Draft                  CSRAttrs                       June 2025


     [RFC5912]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
                Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
                DOI 10.17487/RFC5912, June 2010,
                <https://www.rfc-editor.org/rfc/rfc5912>.

     [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/rfc/rfc6268>.

     [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
                "Enrollment over Secure Transport", RFC 7030,
                DOI 10.17487/RFC7030, October 2013,
                <https://www.rfc-editor.org/rfc/rfc7030>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC9148]  van der Stok, P., Kampanakis, P., Richardson, M., and S.
                Raza, "EST-coaps: Enrollment over Secure Transport with
                the Secure Constrained Application Protocol", RFC 9148,
                DOI 10.17487/RFC9148, April 2022,
                <https://www.rfc-editor.org/rfc/rfc9148>.

     [X.680]    ITU-T, "Information technology -- Abstract Syntax Notation
                One (ASN.1): Specification of basic notation", ITU-T
                Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
                <https://www.itu.int/rec/T-REC-X.680>.

     [X.690]    ITU-T, "Information technology -- ASN.1 encoding rules:
                Specification of Basic Encoding Rules (BER), Canonical
                Encoding Rules (CER) and Distinguished Encoding Rules
                (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
                February 2021, <https://www.itu.int/rec/T-REC-X.690>.

  9.2.  Informative References

     [dumpasn1] Gutmann, P., "Dump ASN", n.d.,
                <https://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>.

     [favoritedrink]
                "Favorite Drink: arbitrary OID", n.d.,
                <https://oid-base.com/get/0.9.2342.19200300.100.1.5>.






  Richardson, et al.      Expires 30 December 2025               [Page 20]


  Internet-Draft                  CSRAttrs                       June 2025


     [RFC2985]  Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
                Classes and Attribute Types Version 2.0", RFC 2985,
                DOI 10.17487/RFC2985, November 2000,
                <https://www.rfc-editor.org/rfc/rfc2985>.

     [RFC4211]  Schaad, J., "Internet X.509 Public Key Infrastructure
                Certificate Request Message Format (CRMF)", RFC 4211,
                DOI 10.17487/RFC4211, September 2005,
                <https://www.rfc-editor.org/rfc/rfc4211>.

     [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
                (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
                <https://www.rfc-editor.org/rfc/rfc5272>.

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

     [RFC8295]  Turner, S., "EST (Enrollment over Secure Transport)
                Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018,
                <https://www.rfc-editor.org/rfc/rfc8295>.

     [RFC8368]  Eckert, T., Ed. and M. Behringer, "Using an Autonomic
                Control Plane for Stable Connectivity of Network
                Operations, Administration, and Maintenance (OAM)",
                RFC 8368, DOI 10.17487/RFC8368, May 2018,
                <https://www.rfc-editor.org/rfc/rfc8368>.

     [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
                Autonomic Control Plane (ACP)", RFC 8994,
                DOI 10.17487/RFC8994, May 2021,
                <https://www.rfc-editor.org/rfc/rfc8994>.

     [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
                and K. Watsen, "Bootstrapping Remote Secure Key
                Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
                May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.

     [RFC9480]  Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate
                Management Protocol (CMP) Updates", RFC 9480,
                DOI 10.17487/RFC9480, November 2023,
                <https://www.rfc-editor.org/rfc/rfc9480>.







  Richardson, et al.      Expires 30 December 2025               [Page 21]


  Internet-Draft                  CSRAttrs                       June 2025


     [RFC9483]  Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
                Certificate Management Protocol (CMP) Profile", RFC 9483,
                DOI 10.17487/RFC9483, November 2023,
                <https://www.rfc-editor.org/rfc/rfc9483>.

  Appendix A.  ASN.1 Module

        |  RFC EDITOR: Please replace TBD1, TBD2, and TBD3 with the value
        |  assigned by IANA during the publication of this document.

     This appendix provides an ASN.1 module [X.680] for the Certification
     Request Information Template attribute, and it follows the
     conventions established in [RFC5911], [RFC5912], and [RFC6268].

     CRITemplateModule
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) id-mod-critemplate(TBD1) }

     DEFINITIONS IMPLICIT TAGS ::=

     BEGIN

     IMPORTS -- from [RFC5912]

     SupportedAttributes
      FROM PKIX1Explicit-2009
       { iso(1) identified-organization(3) dod(6) internet(1) security(5)
         mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)}

     ATTRIBUTE, EXTENSION
      FROM PKIX-CommonTypes-2009
       { iso(1) identified-organization(3) dod(6) internet(1) security(5)
         mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) }

     PUBLIC-KEY, AlgorithmIdentifier{}
      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)}

     CertExtensions
      FROM PKIX1Implicit-2009
       { iso(1) identified-organization(3) dod(6) internet(1) security(5)
         mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}

     Attributes{}, CRIAttributes, PKInfoAlgorithms
      FROM PKCS-10
       { iso(1) identified-organization(3) dod(6) internet(1)



  Richardson, et al.      Expires 30 December 2025               [Page 22]


  Internet-Draft                  CSRAttrs                       June 2025


         security(5) mechanisms(5) pkix(7)
         id-mod(0) id-mod-pkcs10-2009(69) }
     ;

     aa-certificationRequestInfoTemplate ATTRIBUTE ::=
       { TYPE CertificationRequestInfoTemplate IDENTIFIED BY
         id-aa-certificationRequestInfoTemplate }

     id-aa-certificationRequestInfoTemplate OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
         smime(16) aa(2) id-aa-certificationRequestInfoTemplate(TBD2) }

     --  like CertificationRequestInfo but OPTIONAL subject, subjectPKInfo
     CertificationRequestInfoTemplate ::= SEQUENCE {
         version       INTEGER { v1(0) } (v1, ... ),
         subject       NameTemplate OPTIONAL,
         subjectPKInfo [0] SubjectPublicKeyInfoTemplate
                                   {{ PKInfoAlgorithms }} OPTIONAL,
         attributes    [1] Attributes{{ CRIAttributes }}
     }


     --  like Name, but with OPTIONAL RDN values
     NameTemplate ::= CHOICE { -- only one possibility for now --
         rdnSequence  RDNSequenceTemplate }

     RDNSequenceTemplate ::= SEQUENCE OF RelativeDistinguishedNameTemplate

     RelativeDistinguishedNameTemplate  ::= SET SIZE (1 .. MAX)
         OF SingleAttributeTemplate { {SupportedAttributes} }

     --  like Attributes, but with OPTIONAL value
     SingleAttributeTemplates{ATTRIBUTE:AttrSet} ::= SEQUENCE OF
         SingleAttributeTemplates{ {AttrSet} }

     --  like SingleAttribute, but with OPTIONAL value
     SingleAttributeTemplate{ATTRIBUTE:AttrSet} ::= SEQUENCE {
         type      ATTRIBUTE.&id({AttrSet}),
         value     ATTRIBUTE.&Type({AttrSet}{@type}) OPTIONAL
     }

     --  like SubjectPublicKeyInfo, but with OPTIONAL subjectPublicKey
     SubjectPublicKeyInfoTemplate{PUBLIC-KEY:IOSet} ::= SEQUENCE {
         algorithm        AlgorithmIdentifier{PUBLIC-KEY, {IOSet}},
         subjectPublicKey BIT STRING OPTIONAL
     }

     id-aa-extensionReqTemplate OBJECT IDENTIFIER ::=



  Richardson, et al.      Expires 30 December 2025               [Page 23]


  Internet-Draft                  CSRAttrs                       June 2025


     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
       smime(16) aa(2) id-aa-extensionReqTemplate(TBD3) }

     --  like extensionRequest, but with OPTIONAL Extension extnValues
     --  original definition was in PKCS#9 RFC 2985 section 5.4.2
     at-extensionReqTemplate ATTRIBUTE ::= {
         TYPE ExtensionReqTemplate IDENTIFIED BY id-aa-extensionReqTemplate }

     ExtensionReqTemplate ::= ExtensionTemplates{{CertExtensions}}

     --  like Extensions, but with OPTIONAL extnValue
     ExtensionTemplates{EXTENSION:ExtensionSet} ::=
         SEQUENCE SIZE (1..MAX) OF ExtensionTemplate{{ExtensionSet}}

     --  like Extension, but with OPTIONAL extnValue
     ExtensionTemplate{EXTENSION:ExtensionSet} ::= SEQUENCE {
         extnID    EXTENSION.&id({ExtensionSet}),
         critical  BOOLEAN
       --                   (EXTENSION.&Critical({ExtensionSet}{@extnID}))
                          DEFAULT FALSE,
         extnValue OCTET STRING (CONTAINING
                   EXTENSION.&ExtnType({ExtensionSet}{@extnID})) OPTIONAL
                   --  contains the DER encoding of the ASN.1 value
                   --  corresponding to the extension type identified
                   --  by extnID when present
     }

     END

  Authors' Addresses

     Michael Richardson (editor)
     Sandelman Software Works
     Email: mcr+ietf@sandelman.ca


     Owen Friel
     Cisco
     Email: ofriel@cisco.com


     Dr. David von Oheimb
     Siemens
     Email: dev@ddvo.net


     Dan Harkins
     The Industrial Lounge



  Richardson, et al.      Expires 30 December 2025               [Page 24]


  Internet-Draft                  CSRAttrs                       June 2025


     Email: dharkins@lounge.org


















































  Richardson, et al.      Expires 30 December 2025               [Page 25]


name: draft-ietf-suit-firmware-encryption
rev: 26
title: Encrypted Payloads in SUIT Manifests
time: 2025-12-08T19:57:52Z
group_uri: /api/v1/group/group/2211/
expires: 2026-06-11T19:12:27Z
ad: /api/v1/person/person/123703/
shepherd: /api/v1/person/email/akira.tsukamoto@gmail.com/
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.890394+00:00
source: ietf
abstract:
  This document specifies techniques for encrypting software, firmware,
     machine learning models, and personalization data by utilizing the
     IETF SUIT manifest.  Key agreement is provided by ephemeral-static
     (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW).  ES-DH uses
     public key cryptography while AES-KW uses a pre-shared key.
     Encryption of the plaintext is accomplished with conventional
     symmetric key cryptography.

states:
  ["/api/v1/doc/state/1/", "/api/v1/doc/state/108/", "/api/v1/doc/state/115/", "/api/v1/doc/state/17/", "/api/v1/doc/state/34/", "/api/v1/doc/state/44/"]

full_text:
  SUIT                                                       H. Tschofenig
  Internet-Draft                                                     H-BRS
  Intended status: Standards Track                              R. Housley
  Expires: 11 June 2026                                     Vigil Security
                                                                  B. Moran
                                                               Arm Limited
                                                                  D. Brown
                                                                    Linaro
                                                               K. Takayama
                                                           SECOM CO., LTD.
                                                           8 December 2025


                    Encrypted Payloads in SUIT Manifests
                   draft-ietf-suit-firmware-encryption-26

  Abstract

     This document specifies techniques for encrypting software, firmware,
     machine learning models, and personalization data by utilizing the
     IETF SUIT manifest.  Key agreement is provided by ephemeral-static
     (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW).  ES-DH uses
     public key cryptography while AES-KW uses a pre-shared key.
     Encryption of the plaintext is accomplished with conventional
     symmetric key cryptography.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 11 June 2026.

  Copyright Notice

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




  Tschofenig, et al.        Expires 11 June 2026                  [Page 1]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     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, as 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 are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   4
     3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Encryption Extensions . . . . . . . . . . . . . . . . . . . .   7
       4.1.  Directive Write . . . . . . . . . . . . . . . . . . . . .   8
       4.2.  Directive Copy  . . . . . . . . . . . . . . . . . . . . .   9
       4.3.  Authenticating the Payload  . . . . . . . . . . . . . . .   9
     5.  Content Key Distribution  . . . . . . . . . . . . . . . . . .  10
       5.1.  Content Key Distribution with AES Key Wrap  . . . . . . .  11
         5.1.1.  Introduction  . . . . . . . . . . . . . . . . . . . .  11
         5.1.2.  Deployment Options  . . . . . . . . . . . . . . . . .  11
         5.1.3.  The CDDL of SUIT_Encryption_Info for AES-KW binary  .  12
       5.2.  Content Key Distribution with Ephemeral-Static
             Diffie-Hellman  . . . . . . . . . . . . . . . . . . . . .  13
         5.2.1.  Introduction  . . . . . . . . . . . . . . . . . . . .  13
         5.2.2.  Deployment Options  . . . . . . . . . . . . . . . . .  14
         5.2.3.  The CDDL of SUIT_Encryption_Info for ES-DH binary . .  15
         5.2.4.  Context Information Structure . . . . . . . . . . . .  16
     6.  Content Encryption  . . . . . . . . . . . . . . . . . . . . .  17
       6.1.  AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . .  18
         6.1.1.  Introduction  . . . . . . . . . . . . . . . . . . . .  18
         6.1.2.  AES-KW + AES-GCM Example  . . . . . . . . . . . . . .  19
         6.1.3.  ECDH-ES+AES-KW + AES-GCM Example  . . . . . . . . . .  20
       6.2.  AES-CTR . . . . . . . . . . . . . . . . . . . . . . . . .  21
         6.2.1.  Introduction  . . . . . . . . . . . . . . . . . . . .  22
         6.2.2.  AES-KW + AES-CTR Example  . . . . . . . . . . . . . .  23
         6.2.3.  ECDH-ES+AES-KW + AES-CTR Example  . . . . . . . . . .  24
     7.  Integrity Check on Encrypted and Decrypted Payloads . . . . .  26
       7.1.  Validating Payload Integrity  . . . . . . . . . . . . . .  26
         7.1.1.  Image Match after Decryption  . . . . . . . . . . . .  27
         7.1.2.  Image Match before Decryption . . . . . . . . . . . .  27
         7.1.3.  Checking Authentication Tag while Decrypting  . . . .  28
       7.2.  Payload Integrity Validation  . . . . . . . . . . . . . .  28
     8.  Firmware Updates on IoT Devices with Flash Memory . . . . . .  30
     9.  Complete Examples . . . . . . . . . . . . . . . . . . . . . .  33
       9.1.  AES Key Wrap Example with Write Directive . . . . . . . .  34
       9.2.  AES Key Wrap Example with Fetch + Copy Directives . . . .  36



  Tschofenig, et al.        Expires 11 June 2026                  [Page 2]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


       9.3.  ES-DH Example with Write + Copy Directives  . . . . . . .  42
       9.4.  ES-DH Example with Dependency . . . . . . . . . . . . . .  44
     10. Operational Considerations  . . . . . . . . . . . . . . . . .  48
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  49
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  51
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  51
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  51
       13.2.  Informative References . . . . . . . . . . . . . . . . .  52
     Appendix A.  Full CDDL  . . . . . . . . . . . . . . . . . . . . .  54
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  54
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  54

  1.  Introduction

     Vulnerabilities in Internet of Things (IoT) devices have highlighted
     the need for a reliable and secure firmware update mechanism,
     especially for constrained devices.  To protect firmware images, the
     SUIT manifest format was developed [I-D.ietf-suit-manifest].  A
     manifest is a bundle of metadata about the firmware for an IoT
     device, where to find the firmware, and the devices to which it
     applies.  [RFC9124] outlines the necessary information a SUIT
     manifest has to provide.  In addition to protecting against
     modification via digital signatures or message authentication codes,
     the format can also offer confidentiality.

     Encryption prevents third parties, including attackers, from
     accessing the payload.  Attackers often require detailed knowledge of
     a binary, such as a firmware image, to launch successful attacks.
     For instance, return-oriented programming (ROP) [ROP] requires access
     to the binary, and encryption makes writing exploits significantly
     more difficult.  Beyond ensuring the confidentiality of the binary
     itself, protecting the confidentiality of the source code will also
     be necessary to prevent reverse engineering and reproduction of the
     firmware.

     The initial motivation for this document was firmware encryption.
     However, the use of SUIT manifests has expanded to encompass other
     scenarios that require integrity and confidentiality protection,
     including:

     *  Software packages

     *  Personalization and configuration data

     *  Machine learning models






  Tschofenig, et al.        Expires 11 June 2026                  [Page 3]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     These additional use cases stem from the work on Trusted Execution
     Environment Provisioning (TEEP), as detailed in [RFC9397] and
     [I-D.ietf-teep-usecase-for-cc-in-network].  The distinction between
     software and firmware is clarified in [RFC9019].

     For consistency and simplicity, we use the term "payload" generically
     to refer to all objects subject to encryption.

     The payload is encrypted using a symmetric content encryption key,
     which can be established through various mechanisms.  This document
     defines two content key distribution methods for use with the SUIT
     manifest:

     *  Ephemeral-Static (ES) Diffie-Hellman (DH), and

     *  AES Key Wrap (AES-KW).

     The first method relies on asymmetric cryptography, while the second
     uses symmetric cryptography.

     Our design aims to reduce the number of content key distribution
     methods for payload encryption, thereby increasing interoperability
     between different SUIT manifest parser implementations.  The
     mandatory-to-implement algorithms are described in a separate
     document [I-D.ietf-suit-mti].

     The goal of this specification is to protect payloads both during
     end-to-end transport (from the distribution system to the device) and
     at rest when stored on the device.  Constrained devices often employ
     eXecute In Place (XIP), a method of executing code directly from
     flash memory rather than loading it into RAM.  Many of these devices
     lack hardware-based, on-the-fly decryption for code stored in flash
     memory, which may require decrypting and storing firmware images in
     on-chip flash before execution.  However, we expect hardware-based,
     on-the-fly decryption to become more common in the future, enhancing
     confidentiality at rest.

  2.  Conventions and 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.

     This document assumes familiarity with the SUIT manifest
     [I-D.ietf-suit-manifest], the SUIT information model [RFC9124], and
     the SUIT architecture [RFC9019].



  Tschofenig, et al.        Expires 11 June 2026                  [Page 4]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     The following abbreviations are used in this document:

     *  Key Wrap (KW), defined in [RFC3394] (for use with AES)

     *  Key-Encryption Key (KEK) [RFC3394]

     *  Content-Encryption Key (CEK) [RFC5652]

     *  Ephemeral-Static (ES) Diffie-Hellman (DH) [RFC9052]

     *  Authenticated Encryption with Associated Data (AEAD)

     *  Execute in Place (XIP)

     The terms sender and recipient have the following meaning:

     *  Sender: Entity that sends an encrypted payload.

     *  Recipient: Entity that receives an encrypted payload.

     Additionally, we introduce the term "distribution system" (or
     distributor) to refer to an entity that knows the recipients of
     payloads.  It is important to note that the distribution system is
     far more than a file server.  For use of encryption, the distribution
     system either knows the public key of the recipient (for ES-DH), or
     the KEK (for AES-KW).

     The author, which is responsible for creating the payload, does not
     know the recipients.  The author may, for example, be a developer
     building a firmware image.

     The author and the distribution system are logical roles.  In some
     deployments these roles are separated in different physical entities
     and in others they are co-located.

  3.  Architecture

     [RFC9019] outlines the architecture for distributing payloads and
     manifests from an author to devices.  However, it does not cover
     payload encryption in detail.  This document extends that
     architecture to support encryption, as illustrated in Figure 1.

     To encrypt a payload, it is essential to know the recipient.  For
     AES-KW, the Key Encryption Key (KEK) must be known, and for ES-DH,
     the sender needs access to the recipient's public key.  This public
     key and its associated parameters may be found in the recipient's
     X.509 certificate [RFC5280].  For authentication and integrity
     protection, recipients must be provisioned with a trust anchor when



  Tschofenig, et al.        Expires 11 June 2026                  [Page 5]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     the manifest is protected by a digital signature.  If a MAC is used
     for manifest protection, a symmetric key must be shared between the
     recipient and the sender.

     With encryption, the author cannot simply create and sign a manifest
     for the payload, as the recipients are often unknown.  Therefore, the
     author must collaborate with the distribution system.  The degree of
     this collaboration is discussed below.

     The primary purpose of encryption is to protect against adversaries
     along the path between the distribution system and the device.  There
     is also a risk that adversaries may extract the decrypted firmware
     image from the device itself.  Consequently, the device must be
     safeguarded against physical attacks.  Such countermeasures are
     outside the scope of this specification.

     Note: It is assumed that a mutually authenticated communication
     channel with integrity and confidentiality protection exists between
     the author and the distribution system.  For example, the author
     could upload the manifest and firmware image to the distribution
     system via a mutually authenticated HTTPS REST API.

      +----------+
      |  Device  |                              +----------+
      |    1     |<--+                          |  Author  |
      |          |   |                          +----+-----+
      +----------+   |                               |
                     |                               | Payload +
                     |                               | Manifest
                     |                               v
      +----------+   |                        +--------------+
      |  Device  |   |  Payload + Manifest    | Distribution |
      |    2     |<--+------------------------+    System    |
      |          |   |                        +--------------+
      +----------+   |
                     |
           ...       |
                     |
      +----------+   |
      |  Device  |   |
      |    n     |<--+
      |          |
      +----------+

       Figure 1: Architecture for the distribution of Encrypted Payloads.

     When the author delegates encryption rights to the distributor, two
     models are possible:



  Tschofenig, et al.        Expires 11 June 2026                  [Page 6]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     1.  Replacing the COSE_Encrypt and Re-signing the Manifest: The
         distributor replaces the COSE_Encrypt structure in the manifest
         and then signs the manifest again.  However, since the
         COSE_Encrypt structure is within a signed container, this
         presents a challenge: replacing COSE_Encrypt alters the digest of
         the manifest, thereby invalidating the signature.  As a result,
         the distributor must be able to sign the new manifest.  If this
         is the case, the distributor gains the authority to construct and
         sign manifests, effectively allowing them to sign code and giving
         them full control over the recipient.  Distributors typically
         perform re-encryption online to manage large numbers of devices
         efficiently, which prevents air-gapping the signing operations.
         This approach necessitates the secure storage of signing keys, as
         outlined in Section 4.3.17 and Section 4.3.18 of [RFC9124].
         Despite these issues, this model represents the current standard
         practice for IoT firmware updates.

     2.  Two-Layer Manifest System: The distributor creates a new manifest
         that overrides the COSE_Encrypt using the dependency system
         defined in [I-D.ietf-suit-trust-domains].  This method introduces
         additional overhead, including one more signature verification,
         one extra manifest, and the need for extra mechanisms on the
         recipient side to handle dependency processing.  While this adds
         complexity, it also enhances security.

     These two models offer different threat profiles for the distributor.
     If the distributor is limited to encryption rights, an attacker who
     breaches the distributor can only launch a limited attack by
     encrypting a modified binary.  However, recipients will detect the
     attack during the image digest check and immediately revert to the
     correct image.

     It is RECOMMENDED that distributors adopt the two-layer manifest
     approach to distribute content encryption keys without re-signing the
     manifest, despite the added complexity and the increased number of
     signature verifications required on the recipient side.

  4.  Encryption Extensions

     Extending the SUIT manifest to support payload encryption requires
     minimal changes and is achieved by adding the suit-parameter-
     encryption-info field to the SUIT_Parameters structure, as
     illustrated in Figure 2.  When the suit-parameter-encryption-info is
     included, the manifest processor will attempt to decrypt data during
     copy or write operations.






  Tschofenig, et al.        Expires 11 June 2026                  [Page 7]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     The SUIT_Encryption_Info structure contains the content key
     distribution information.  The details of the SUIT_Encryption_Info
     structure are provided in Section 5.1 (for AES-KW) and Section 5.2
     (for ES-DH).

     SUIT_Parameters //= (suit-parameter-encryption-info
         => bstr .cbor SUIT_Encryption_Info)

     suit-parameter-encryption-info = TBD19

                Figure 2: CDDL of the SUIT_Parameters Extension.

     RFC Editor's Note (TBD19): The value for the suit-parameter-
     encryption-info parameter is set to 19, as the proposed value.

     Once a CEK is available, the steps outlined in Section 6 apply to
     both content key distribution methods described in this section.

     When used with the "Directive Write" and "Directive Copy" directives,
     the SUIT_Encryption_Info structure MUST be included in either the
     suit-directive-override-parameters or the suit-directive-set-
     parameters.  An implementation conforming to this specification MUST
     support both of these parameters.

  4.1.  Directive Write

     An author uses the Directive Write (suit-directive-write) to decrypt
     the content specified by suit-parameter-content using suit-parameter-
     encryption-info.  This directive is used to write a specific data
     directly to a component.

     Figure 3 illustrates an example of the Directive Write, which is
     described in the CDDL in Figure 2.  The encrypted payload specified
     by parameter-content, represented as h'EA1...CED' in the example, is
     decrypted using the SUIT_Encryption_Info structure referenced by
     parameter-encryption-info, i.e., h'D86...1F0' in L3.  The resulting
     plaintext payload is then stored in component #0, which is the
     default if no specific component is explicitly designated.

     /  1/  / directive-override-parameters / 20, {
     /  2/    / parameter-content / 18: h'EA1...CED',
     /  3/    / parameter-encryption-info / TBD19: h'D86...1F0'
     /  4/  },
     /  5/  / directive-write / 18, 15

          Figure 3: Example showing the extended suit-directive-write.





  Tschofenig, et al.        Expires 11 June 2026                  [Page 8]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     RFC Editor's Note (TBD19): The value for the parameter-encryption-
     info parameter is set to 19, as the proposed value.

  4.2.  Directive Copy

     An author uses the Directive Copy (suit-directive-copy) to decrypt
     the content of the component specified by suit-parameter-source-
     component using suit-parameter-encryption-info.  This directive is
     used to copy data from one component to another.

     Figure 4 illustrates the Directive Copy.  In this example the
     encrypted payload is found at the URI indicated by the parameter-uri,
     i.e., "coaps://example.com/encrypted.bin" in L3.  The encrypted
     payload will be downloaded and stored in component #1, as indicated
     by directive-set-component-index in L1.

     Then, the information in the SUIT_Encryption_Info structure referred
     to by parameter-encryption-info, i.e., h'D86...1F0' in L9, will be
     used to decrypt the content in component #1 and the resulting
     plaintext payload will be stored into component #0 (as set in L7).
     The command in L12 invokes the operation.

     /  1/  / directive-set-component-index / 12, 1,
     /  2/  / directive-override-parameters / 20, {
     /  3/    / parameter-uri / 21: "coaps://example.com/encrypted.bin",
     /  4/   },
     /  5/  / directive-fetch / 21, 15,
     /  6/
     /  7/  / directive-set-component-index / 12, 0,
     /  8/  / directive-override-parameters / 20, {
     /  9/    / parameter-encryption-info / TBD19: h'D86...1F0',
     / 10/    / parameter-source-component / 22: 1
     / 11/  },
     / 12/  / directive-copy / 22, 15

          Figure 4: Example showing the extended suit-directive-copy.

     RFC Editor's Note (TBD19): The value for the suit-parameter-
     encryption-info parameter is set to 19, as the proposed value.

  4.3.  Authenticating the Payload

     The payload to be encrypted MAY be detached and, in that case, it is
     not covered by the digital signature or the MAC protecting the
     manifest.  (To be more precise, the suit-authentication-wrapper found
     in the envelope contains a digest of the manifest in the SUIT Digest
     Container.)




  Tschofenig, et al.        Expires 11 June 2026                  [Page 9]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     The lack of authentication and integrity protection of the payload is
     particularly a concern when a cipher without integrity protection is
     used.

     To provide authentication and integrity protection of the payload in
     the detached case a SUIT Digest Container with the hash of the
     encrypted and/or plaintext payload MUST be included in the manifest.
     See suit-parameter-image-digest parameter in Section 8.4.8.6 of
     [I-D.ietf-suit-manifest].

     Once a CEK is available, the steps described in Section 6 are
     applicable.  These steps apply to both content key distribution
     methods.

     More detailed examples for the two directives can be found in
     Section 9.1.

  5.  Content Key Distribution

     The following sub-sections describe two content key distribution
     methods: AES Key Wrap (AES-KW) and Ephemeral-Static Diffie-Hellman
     (ES-DH).  While many other methods are specified in the literature
     and supported by COSE, AES-KW and ES-DH were chosen for their
     widespread use in the market today.  They were selected for their
     maturity, differing security properties, and strong interoperability.

     Interoperability requirements for content key distribution methods
     differ: since a device typically supports only one of the two
     specified methods, the distribution system must be aware of the
     supported method.  Restricting a constrained device to a single
     content key distribution method also helps minimize code size.

     Both content key distribution methods require the CEKs to be randomly
     generated.  The guidelines for random number generation in [RFC8937]
     MUST be followed.

     When sending an encrypted payload to multiple recipients, various
     deployment options are available.  The following notation is used to
     explain these options:

       - KEK[R1, S] refers to a KEK shared between recipient R1 and
         the sender S.
       - CEK[R1, S] refers to a CEK shared between R1 and S.
       - CEK[*, S] or KEK[*, S] are used when a single CEK or a single
         KEK is shared with all authorized recipients by a given sender
         S in a certain context.
       - ENC(plaintext, k) refers to the encryption of plaintext with
         a key k.



  Tschofenig, et al.        Expires 11 June 2026                 [Page 10]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


  5.1.  Content Key Distribution with AES Key Wrap

  5.1.1.  Introduction

     The AES Key Wrap (AES-KW) algorithm, as described in [RFC3394], is
     used to encrypt a randomly generated content-encryption key (CEK)
     with a pre-shared key-encryption key (KEK).  The COSE conventions for
     using AES-KW are specified in Section 8.5.2 of [RFC9052] and in
     Section 6.2.1 of [RFC9053].  The encrypted CEK is carried within the
     COSE_recipient structure , which includes the necessary information
     for AES-KW.  The COSE_recipient structure, a substructure of
     COSE_Encrypt, contains the CEK encrypted by the KEK.

     To ensure high security when using AES Key Wrap, it is important that
     the KEK is of high entropy and that implementations protect the KEK
     from disclosure.  A compromised KEK could expose all data encrypted
     with it, including binaries and configuration data.

     The COSE_Encrypt structure conveys the information needed to encrypt
     the payload, including details such as the algorithm and IV.  Even
     though the payload may be conveyed as detached content, the
     encryption information is still embedded in the
     COSE_Encrypt.ciphertext structure.

  5.1.2.  Deployment Options

     There are three deployment options for use with AES Key Wrap for
     payload encryption:

     *  If all recipients (typically of the same product family) share the
        same KEK, a single COSE_recipient structure contains the encrypted
        CEK.  The sender executes the following steps:

          1. Fetch KEK[*, S]
          2. Generate CEK
          3. ENC(CEK, KEK)
          4. ENC(payload, CEK)

     This deployment option is strongly discouraged.  An attacker gaining
     access to the KEK will be able to encrypt and send payloads to all
     recipients configured to use this KEK.

     *  If recipients have different KEKs, then multiple COSE_recipient
        structures are included but only a single CEK is used.  Each
        COSE_recipient structure contains the CEK encrypted with the KEKs
        appropriate for a given recipient.  The benefit of this approach
        is that the payload is encrypted only once with a CEK while there
        is no sharing of the KEK across recipients.  Hence, authorized



  Tschofenig, et al.        Expires 11 June 2026                 [Page 11]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


        recipients still use their individual KEK to decrypt the CEK and
        to subsequently obtain the plaintext.  The steps taken by the
        sender are:

         1.  Generate CEK
         2.  for i=1 to n
             {
         2a.    Fetch KEK[Ri, S]
         2b.    ENC(CEK, KEK[Ri, S])
             }
         3.  ENC(payload, CEK)

     *  The third option is to use different CEKs encrypted with KEKs of
        authorized recipients.  This approach is appropriate when no
        benefits can be gained from encrypting and transmitting payloads
        only once.  Assume there are n recipients with their unique KEKs -
        KEK[R1, S], ..., KEK[Rn, S] and unique CEKs.  The sender needs to
        execute the following steps:

         1.  for i=1 to n
             {
         1a.    Fetch KEK[Ri, S]
         1b.    Generate CEK[Ri, S]
         1c.    ENC(CEK[Ri, S], KEK[Ri, S])
         1d.    ENC(payload, CEK[Ri, S])
         2.  }

  5.1.3.  The CDDL of SUIT_Encryption_Info for AES-KW binary

     The CDDL for the AES-KW binary is shown in Figure 5.
     empty_or_serialized_map and header_map are structures defined in
     [RFC9052].



















  Tschofenig, et al.        Expires 11 June 2026                 [Page 12]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     SUIT_Encryption_Info_AESKW = #6.96([
       protected   : outer_header_map_protected,
       unprotected : outer_header_map_unprotected,
       ciphertext  : bstr / nil,
       recipients  : [ + COSE_recipient_AESKW ]
     ])

     outer_header_map_protected = empty_or_serialized_map
     outer_header_map_unprotected = header_map

     COSE_recipient_AESKW = [
       protected   : bstr .size 0 / bstr .cbor empty_map,
       unprotected : recipient_header_unpr_map_aeskw,
       ciphertext  : bstr        ; CEK encrypted with KEK
     ]

     empty_map = {}

     recipient_header_unpr_map_aeskw =
     {
       ? 1 => int / tstr,  ; content encryption algorithm identifier
       ? 4 => bstr,        ; identifier of the KEK
                           ; pre-shared with the recipient
       * label => values   ; extension point
     }

            Figure 5: CDDL for AES-KW-based Content Key Distribution

     Note that the AES-KW algorithm, as defined in Section 2.2.3.1 of
     [RFC3394], does not have public parameters that vary on a per-
     invocation basis.  Hence, the protected header in the COSE_recipient
     structure is a byte string of zero length.

  5.2.  Content Key Distribution with Ephemeral-Static Diffie-Hellman

  5.2.1.  Introduction

     Ephemeral-Static Diffie-Hellman (ES-DH) is a public key encryption
     scheme that enables encryption using the recipient's public key.
     There are several variations of this scheme; this document adopts the
     version specified in Section 8.5.5 of [RFC9052].

     The structure is composed of two layers:

     *  Layer 0: Contains content encrypted with a Content Encryption Key
        (CEK).  The content may be provided separately.





  Tschofenig, et al.        Expires 11 June 2026                 [Page 13]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     *  Layer 1: Uses the AES Key Wrap (AES-KW) algorithm to encrypt the
        randomly generated CEK with a Key Encryption Key (KEK) derived via
        ES-DH.  The resulting symmetric key is processed through an HKDF-
        based key derivation function [RFC5869].

     This two-layer structure combines ES-DH with AES-KW and HKDF,
     referred to as ECDH-ES + AES-KW.  An example can be found in
     Figure 10.

     Another variant of the ES-DH algorithm, called ECDH-ES + HKDF, does
     not utilize AES Key Wrap.  However, this version is not covered in
     this document.

  5.2.2.  Deployment Options

     This approach supports only two deployment options, as it assumes
     that each recipient is always equipped with a device-specific public/
     private key pair.

     *  When a sender transmits a payload to multiple recipients, all
        recipients receive the same encrypted payload, meaning the same
        CEK is used to encrypt the content.  For each recipient, a
        separate COSE_recipient structure is used, which contains the CEK
        encrypted with the recipient-specific KEK.  To derive the KEK,
        each COSE_recipient structure includes a COSE_recipient_inner
        structure that carries the sender's ephemeral key and an
        identifier for the recipient's public key.

     The steps taken by the sender are:

         1.  Generate CEK
         2.  for i=1 to n
             {
         2a.     Generate KEK[Ri, S] using ES-DH
         2b.     ENC(CEK, KEK[Ri, S])
             }
         3.  ENC(payload,CEK)

     *  The alternative is to encrypt each device specific payload with a
        unique content encryption key (CEK), resulting in a manifest per
        device specific payload. his approach is useful when payloads
        contain device-specific information or when the optimization in
        previous approach are not applicable or not valuable enough.  In
        this case, the encryption operation becomes ENC(payload_i, CEK[Ri,
        S]) where each recipient Ri receives a unique CEK.  Assume that
        KEK[R1, S],..., KEK[Rn, S] have been generated for the recipients
        using ES-DH.  The sender must then follow these steps:




  Tschofenig, et al.        Expires 11 June 2026                 [Page 14]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


         1.  for i=1 to n
             {
         1a.     Generate KEK[Ri, S] using ES-DH
         1b.     Generate CEK[Ri, S]
         1c.     ENC(CEK[Ri, S], KEK[Ri, S])
         1d.     ENC(payload, CEK[Ri, S])
             }

  5.2.3.  The CDDL of SUIT_Encryption_Info for ES-DH binary

     The CDDL for the ECDH-ES+AES-KW binary is provided in Figure 6.  Only
     the essential parameters are included.  The structures
     empty_or_serialized_map and header_map are defined in [RFC9052].

     SUIT_Encryption_Info_ESDH = #6.96([
       protected   : outer_header_map_protected,
       unprotected : outer_header_map_unprotected,
       ciphertext  : bstr / nil,
       recipients  : [ + COSE_recipient_ESDH ]
     ])

     outer_header_map_protected = empty_or_serialized_map
     outer_header_map_unprotected = header_map

     COSE_recipient_ESDH = [
       protected   : bstr .cbor recipient_header_map_esdh,
       unprotected : recipient_header_unpr_map_esdh,
       ciphertext  : bstr        ; CEK encrypted with KEK
     ]

     recipient_header_map_esdh =
     {
       ?  1 => int / tstr, ; content encryption algorithm identifier
       * label => values   ; extension point
     }

     recipient_header_unpr_map_esdh =
     {
       ? 4 => bstr,        ; identifier of the recipient public key
        -1 => COSE_Key,    ; ephemeral public key for the sender
       * label => values   ; extension point
     }

            Figure 6: CDDL for ES-DH-based Content Key Distribution

     See Section 6 for a description on how to encrypt the payload.





  Tschofenig, et al.        Expires 11 June 2026                 [Page 15]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


  5.2.4.  Context Information Structure

     The context information structure ensures that the derived keying
     material is "bound" to the specific context of the transaction.  This
     specification reuses the structure defined in Section 5.2 of
     [RFC9053], with modifications to fit the current use case.

     The following elements are bound to the context:

     *  the protocol employing the key-derivation method,

     *  information about the utilized AES Key Wrap algorithm, and the key
        length.

     *  the protected header field, which contains the content key
        encryption algorithm.

     The sender and recipient identities are left empty.

     The following fields in Figure 7 require an explanation:

     *  The COSE_KDF_Context.AlgorithmID field MUST contain the identifier
        for the AES Key Wrap algorithm being used.  This specification
        uses the following values: A128KW (value -3), A192KW (value -4),
        or A256KW (value -5)

     *  The COSE_KDF_Context.SuppPubInfo.keyDataLength field MUST specify
        the key length, in bits, corresponding to the algorithm in the
        AlgorithmID field.  For A128KW the value is 128, for A192KW the
        value is 192, and for A256KW the value 256.

     *  The COSE_KDF_Context.SuppPubInfo.other field captures the protocol
        that uses the ES-DH content key distribution algorithm.  It MUST
        be set to the constant string "SUIT Payload Encryption".

     *  The COSE_KDF_Context.SuppPubInfo.protected field MUST contain the
        serialized content of the recipient_header_map_esdh field, which
        contains (among other elements) the identifier of the content key
        distribution method.












  Tschofenig, et al.        Expires 11 June 2026                 [Page 16]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     COSE_KDF_Context = [
         AlgorithmID : int,
         PartyUInfo : [ PartyInfoSender ],
         PartyVInfo : [ PartyInfoRecipient ],
         SuppPubInfo : [
             keyDataLength : uint,
             protected : bstr,
             other: 'SUIT Payload Encryption'
         ],
         ? SuppPrivInfo : bstr
     ]

     PartyInfoSender = (
         identity : nil,
         nonce : nil,
         other : nil
     )

     PartyInfoRecipient = (
         identity : nil,
         nonce : nil,
         other : nil
     )

                 Figure 7: CDDL for COSE_KDF_Context Structure

     The HKDF-based key derivation function MAY contain a salt value, as
     described in Section 5.1 of [RFC9053].  This optional value
     influences the key generation process, though this specification does
     not require the use of a salt.  If the salt is public and included in
     the message, the "salt" algorithm header parameter MUST be used.  The
     salt adds extra randomness to the KDF context.  When the salt is
     transmitted via the "salt" algorithm header parameter, the receiver
     MUST be capable of processing it and MUST pass it into the key
     derivation function.  For more details on salt usage, refer to
     [RFC5869] and NIST SP800-56 [SP800-56].

     Profiles of this specification MAY define an extended version of the
     context information structure or MAY employ a different context
     information structure.

  6.  Content Encryption

     This section summarizes the steps involved in content encryption,
     applicable to both content key distribution methods.






  Tschofenig, et al.        Expires 11 June 2026                 [Page 17]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     When using AEAD ciphers, such as AES-GCM or ChaCha20/Poly1305, the
     COSE specification requires a consistent byte stream to create the
     authenticated data structure.  This structure is illustrated in
     Figure 8 and defined in Section 5.3 of [RFC9052].

      Enc_structure = [
        context : "Encrypt",
        protected : empty_or_serialized_map,
        external_aad : bstr
      ]

                Figure 8: CDDL for Enc_structure Data Structure

     This Enc_structure must be populated as follows:

     *  The protected field in the Enc_structure from Figure 8 refers to
        the content of the protected field in the COSE_Encrypt structure.

     *  The value of external_aad MUST be set to a zero-length byte
        string, represented as h'' in diagnostic notation and encoded as
        0x40.

     Some ciphers, such as AES-CTR, provide confidentiality without
     integrity protection (see [RFC9459]).  For these ciphers, the
     Enc_structure shown in Figure 8 cannot be used, as the Additional
     Authenticated Data (AAD) byte string is only applicable to AEAD
     ciphers.  Therefore, the AAD structure is not passed to the API for
     these ciphers, and the protected header in the SUIT_Encryption_Info
     structure MUST be a zero-length byte string.

  6.1.  AES-GCM

  6.1.1.  Introduction

     AES-GCM is an AEAD cipher and provides confidentiality and integrity
     protection.

     Examples in this section use the following parameters:

     *  Algorithm for payload encryption: AES-GCM-128

        -  k: h'15F785B5C931414411B4B71373A9C0F7'

        -  IV: h'F14AAB9D81D51F7AD943FE87AF4F70CD'

     *  Plaintext: "This is a real firmware image."





  Tschofenig, et al.        Expires 11 June 2026                 [Page 18]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


        -  in hex:
           546869732069732061207265616C206669726D7761726520696D6167652E

  6.1.2.  AES-KW + AES-GCM Example

     This example uses the following parameters:

     *  Algorithm id for key wrap: A128KW

     *  KEK COSE_Key (Secret Key):

        -  kty: Symmetric

        -  k: 'aaaaaaaaaaaaaaaa'

        -  kid: 'kid-1'

     The COSE_Encrypt structure, in hex format, is (with a line break
     inserted):

     D8608443A10101A1054CF14AAB9D81D51F7AD943FE87F6818340A2012204
     456B69642D31581875603FFC9518D794713C8CA8A115A7FB32565A6D5953
     4D62

     The resulting COSE_Encrypt structure in a diagnostic format is shown
     in Figure 9.

     96([
       / protected: / << {
         / alg / 1: 1 / A128GCM /
       } >>,
       / unprotected: / {
         / IV / 5: h'F14AAB9D81D51F7AD943FE87'
       },
       / ciphertext: / null / detached ciphertext /,
       / recipients: / [
         [
           / protected: / h'',
           / unprotected: / {
             / alg / 1: -3 / A128KW /,
             / kid / 4: 'kid-1'
           },
           / ciphertext: /
             h'75603FFC9518D794713C8CA8A115A7FB32565A6D59534D62'
             / CEK encrypted with KEK /
         ]
       ]
     ])



  Tschofenig, et al.        Expires 11 June 2026                 [Page 19]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


                Figure 9: COSE_Encrypt Example for AES Key Wrap

     The encrypted payload (with a line feed added) was:

     758C4B7BBAE2C4C1D462423E0F0DC3164FFA7B85BB94D4BD6D7ED26AB32F
     EB063385D4D3465927EC82CB5E198A59

  6.1.3.  ECDH-ES+AES-KW + AES-GCM Example

     This example uses the following parameters:

     *  Algorithm for content key distribution: ECDH-ES + A128KW

     *  KEK COSE_Key (Receiver's Private Key):

        -  kty: EC2

        -  crv: P-256

        -  x: h'5886CD61DD875862E5AAA820E7A15274C968A9BC96048DDCACE32F50C3
           651BA3'

        -  y: h'9EED8125E932CD60C0EAD3650D0A485CF726D378D1B016ED4298B2961E
           258F1B'

        -  d: h'60FE6DD6D85D5740A5349B6F91267EEAC5BA81B8CB53EE249E4B4EB102
           C476B3'

        -  kid: 'kid-2'

     *  KDF Context

        -  Algorithm ID: -3 (A128KW)

        -  SuppPubInfo

           o  keyDataLength: 128

           o  protected: << { / alg / 1: -29 / ECDH-ES+A128KW / } >>

           o  other: 'SUIT Payload Encryption'

     The COSE_Encrypt structure, in hex format, is (with a line break
     inserted):







  Tschofenig, et al.        Expires 11 June 2026                 [Page 20]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     D8608443A10101A1054CF14AAB9D81D51F7AD943FE87F6818344A101381C
     A120A40102200121582073024F415AA51529A66CCEFD88F3F62A734492FF
     45F6AD37FD2888E73EAF19DA2258204005B48A6FD091AA6ABFE3CFBEEDE8
     8B347E521D43405FDBD7D2CFF0EBC21B265818A06B8E6550F308712B1DF0
     44B21B7D11D9B22792F1DE0997

     The resulting COSE_Encrypt structure in a diagnostic format is shown
     in Figure 10.

     96([
       / protected: / << {
         / alg / 1: 1 / A128GCM /
       } >>,
       / unprotected: / {
         / IV / 5: h'F14AAB9D81D51F7AD943FE87'
       },
       / ciphertext: / null / detached ciphertext /,
       / recipients: / [
         [
           / protected: / << {
             / alg / 1: -29 / ECDH-ES + A128KW /
           } >>,
           / unprotected: / {
             / ephemeral key / -1: {
               / kty / 1: 2 / EC2 /,
               / crv / -1: 1 / P-256 /,
               / x / -2: h'73024F415AA51529A66CCEFD88F3F62A
                           734492FF45F6AD37FD2888E73EAF19DA',
               / y / -3: h'4005B48A6FD091AA6ABFE3CFBEEDE88B
                           347E521D43405FDBD7D2CFF0EBC21B26'
             }
           },
           / ciphertext: /
             h'A06B8E6550F308712B1DF044B21B7D11D9B22792F1DE0997'
             / CEK encrypted with KEK /
         ]
       ]
     ])

                   Figure 10: COSE_Encrypt Example for ES-DH

     The encrypted payload (with a line feed added) was:

     758C4B7BBAE2C4C1D462423E0F0DC3164FFA7B85BB94D4BD6D7ED26AB32F
     EB063385D4D3465927EC82CB5E198A59

  6.2.  AES-CTR




  Tschofenig, et al.        Expires 11 June 2026                 [Page 21]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


  6.2.1.  Introduction

     AES-CTR is a non-AEAD cipher that provides confidentiality but lacks
     integrity protection.  Unlike AES-CBC, AES-CTR uses an IV per block,
     as shown in Figure 11.  Hence, when an image is encrypted using AES-
     CTR-128 or AES-CTR-256, the counter value MUST start with the IV
     value and incremented by one for each 16-byte plaintext block.  The
     IV value MAY be provided by the COSE header field or is communicated
     via out-of-band means, for example by setting it to a given value
     (e.g. the value of zero).  Firmware authors MUST make sure that the
     same IV and AES content key encryption combination is not used more
     than once.  Communicating the IV value inside the COSE header is
     RECOMMENDED.

     The following abbreviations are used in Figure 11:

     *  Pi = Plaintext blocks

     *  Ci = Ciphertext blocks

     *  E = Encryption function

     *  k = Symmetric key

     *  ⊕ = XOR operation

              IV1            IV2
               |              |
               |              |
               |              |
           +---+---+      +---+---+
           |       |      |       |
           |       |      |       |
        k--+   E   |   k--+   E   |
           |       |      |       |
           +---+---+      +---+---+
               |              |
          P1---⊕         P2---⊕
               |              |
               |              |
               C1             C2

                          Figure 11: AES-CTR Operation

     Examples in this section use the following parameters:

     *  Algorithm for payload encryption: AES-CTR-128




  Tschofenig, et al.        Expires 11 June 2026                 [Page 22]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


        -  k: h'261DE6165070FB8951EC5D7B92A065FE'

        -  IV: h'DAE613B2E0DC55F4322BE38BDBA9DC68'

     *  Plaintext: "This is a real firmware image."

        -  in hex:
           546869732069732061207265616C206669726D7761726520696D6167652E

  6.2.2.  AES-KW + AES-CTR Example

     This example uses the following parameters:

     *  Algorithm id for key wrap: A128KW

     *  KEK COSE_Key (Secret Key):

        -  kty: Symmetric

        -  k: 'aaaaaaaaaaaaaaaa'

        -  kid: 'kid-1'

     The COSE_Encrypt structure, in hex format, is (with a line break
     inserted):

     D8608440A20139FFFD0550DAE613B2E0DC55F4322BE38BDBA9DC68F68183
     40A2012204456B69642D315818CE34035CE5C2E2666E46D4C131FC561DD1
     90A6D26CFA1990

     The resulting COSE_Encrypt structure in a diagnostic format is shown
     in Figure 12.



















  Tschofenig, et al.        Expires 11 June 2026                 [Page 23]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     96([
       / protected: / h'',
       / unprotected: / {
         / alg / 1: -65534 / A128CTR /,
         / IV / 5: h'DAE613B2E0DC55F4322BE38BDBA9DC68'
       },
       / ciphertext: / null / detached ciphertext /,
       / recipients: / [
         [
           / protected: / h'',
           / unprotected: / {
             / alg / 1: -3 / A128KW /,
             / kid / 4: 'kid-1'
           },
           / ciphertext: /
             h'CE34035CE5C2E2666E46D4C131FC561DD190A6D26CFA1990'
             / CEK encrypted with KEK /
         ]
       ]
     ])

                Figure 12: COSE_Encrypt Example for AES Key Wrap

     The encrypted payload (with a line feed added) was:

     2BB8DB522AE978246CC775C3B0241BD4B0333FFDD2DB70C7EE7A4966E3B7

  6.2.3.  ECDH-ES+AES-KW + AES-CTR Example

     This example uses the following parameters:

     *  Algorithm for content key distribution: ECDH-ES + A128KW

     *  KEK COSE_Key (Receiver's Private Key):

        -  kty: EC2

        -  crv: P-256

        -  x: h'5886CD61DD875862E5AAA820E7A15274C968A9BC96048DDCACE32F50C3
           651BA3'

        -  y: h'9EED8125E932CD60C0EAD3650D0A485CF726D378D1B016ED4298B2961E
           258F1B'

        -  d: h'60FE6DD6D85D5740A5349B6F91267EEAC5BA81B8CB53EE249E4B4EB102
           C476B3'




  Tschofenig, et al.        Expires 11 June 2026                 [Page 24]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


        -  kid: 'kid-2'

     *  KDF Context

        -  Algorithm ID: -3 (A128KW)

        -  SuppPubInfo

           o  keyDataLength: 128

           o  protected: << { / alg / 1: -29 / ECDH-ES+A128KW / } >>

           o  other: 'SUIT Payload Encryption'

     The COSE_Encrypt structure, in hex format, is (with a line break
     inserted):

     D8608440A20139FFFD0550DAE613B2E0DC55F4322BE38BDBA9DC68F68183
     44A101381CA120A401022001215820EE0718F6B019C29CC611C18CEDE221
     4066DDCEDC2F0DBEF873CB224C715C1174225820279F2A88E4AB9E2ED30C
     0FCB69515B31B5D36725BFDB9AE02032ED4D5AB52CB85818E28B4502E4F5
     151884A995405579006E9465C3E94E3E0808

     The resulting COSE_Encrypt structure in a diagnostic format is shown
     in Figure 13.


























  Tschofenig, et al.        Expires 11 June 2026                 [Page 25]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     96([
       / protected: / h'',
       / unprotected: / {
         / alg / 1: -65534 / A128CTR /,
         / IV / 5: h'DAE613B2E0DC55F4322BE38BDBA9DC68'
       },
       / ciphertext: / null / detached ciphertext /,
       / recipients: / [
         [
           / protected: / << {
             / alg / 1: -29 / ECDH-ES + A128KW /
           } >>,
           / unprotected: / {
             / ephemeral key / -1: {
               / kty / 1: 2 / EC2 /,
               / crv / -1: 1 / P-256 /,
               / x / -2: h'EE0718F6B019C29CC611C18CEDE22140
                           66DDCEDC2F0DBEF873CB224C715C1174',
               / y / -3: h'279F2A88E4AB9E2ED30C0FCB69515B31
                           B5D36725BFDB9AE02032ED4D5AB52CB8'
             }
           },
           / ciphertext: /
             h'E28B4502E4F5151884A995405579006E9465C3E94E3E0808'
             / CEK encrypted with KEK /
         ]
       ]
     ])

                   Figure 13: COSE_Encrypt Example for ES-DH

     The encrypted payload (with a line feed added) was:

     2BB8DB522AE978246CC775C3B0241BD4B0333FFDD2DB70C7EE7A4966E3B7

  7.  Integrity Check on Encrypted and Decrypted Payloads

     In addition to suit-condition-image-match (see Section 8.4.9.2 of
     [I-D.ietf-suit-manifest]), AEAD algorithms used for content
     encryption provides another way to validate the integrity of
     components.  This section provides a guideline to construct secure
     but not redundant SUIT Manifest for encrypted payloads.

  7.1.  Validating Payload Integrity

     This sub-section explains three ways to validate the integrity of
     payloads.




  Tschofenig, et al.        Expires 11 June 2026                 [Page 26]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


  7.1.1.  Image Match after Decryption

     The suit-condition-image-match on the plaintext payload is used after
     decryption.  An example command sequence is shown in Figure 14.

     / directive-set-component-index / 12, 1,
     / directive-override-parameters / 20, {
       / parameter-uri / 21: "coaps://example.com/encrypted.bin"
     },
     / directive-fetch / 21, 15,

     / directive-set-component-index / 12, 0,
     / directive-override-parameters / 20, {
       / parameter-image-digest / 3: << {
         / algorithm-id: / -16 / SHA256 /,
         / digest-bytes: / h'3B1...92A' / digest of plaintext payload /
       } >>,
       / parameter-image-size / 14: 30 / size of plaintext payload /,
       / parameter-encryption-info / TBD19: h'369...50F',
       / parameter-source-component / 22: 1
     },
     / directive-copy / 22, 15,
     / condition-image-match / 3, 15 / check decrypted payload integrity /

                 Figure 14: Check Image Match After Decryption

     RFC Editor's Note (TBD19): The value for the suit-parameter-
     encryption-info parameter is set to 19, as the proposed value.

  7.1.2.  Image Match before Decryption

     The suit-condition-image-match can also be applied on encrypted
     payloads before decryption takes place.  An example command sequence
     is shown in Figure 15.

     This option mitigates battery exhaustion attacks discussed in
     Section 11.














  Tschofenig, et al.        Expires 11 June 2026                 [Page 27]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


    / directive-set-component-index / 12, 1,
    / directive-override-parameters / 20, {
      / parameter-image-digest / 3: << {
        / algorithm-id: / -16 / SHA256 /,
        / digest-bytes: / h'8B4...D34' / digest of encrypted payload /
      } >>,
      / parameter-image-size / 14: 30 / size of encrypted payload /,
      / parameter-uri / 21: "coaps://example.com/encrypted.bin"
    },

    / directive-fetch / 21, 15,
    / condition-image-match / 3, 15 / check decrypted payload integrity /,

    / directive-set-component-index / 12, 0,
    / directive-override-parameters / 20, {
      / parameter-encryption-info / TBD19: h'D86...1F0',
      / parameter-source-component / 22: 1
    },
    / directive-copy / 22, 15

                Figure 15: Check Image Match Before Decryption

     RFC Editor's Note (TBD19): The value for the suit-parameter-
     encryption-info parameter is set to 19, as the proposed value.

  7.1.3.  Checking Authentication Tag while Decrypting

     AEAD algorithms, such as AES-GCM and ChaCha20/Poly1305, verify the
     integrity of the encrypted concent.

  7.2.  Payload Integrity Validation

     This subsection offers guidelines for validating the integrity of
     payloads within the SUIT manifest.  The decision tree in Figure 16
     illustrates the process for establishing payload integrity.
















  Tschofenig, et al.        Expires 11 June 2026                 [Page 28]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     +------------------------------------------------+
     |        Q1. How is the Payload delivered?       |
     +-+--------------------------------------------+-+
       |                                            |
       | in Content                          others |
       |                                            v
       |             +--------------------------------+
       |             |      Q2. Mitigate Battery      |
       |             |       Exhaustion Attacks?      |
       |             +-+----------------------------+-+
       |               |                            |
       |               | No                     Yes |
       |               v                            |
       | +-----------------------+                  |
       | | Q3. AEAD cipher used? |                  |
       | +----+-------------+----+                  |
       |      |             |                       |
       |      | Yes      No |                       |
       v      v             v                       v
      .+------+.      .-----+-----.      .----------+.
     |   Not    |    |  BEFORE or  |    |   BEFORE    |
     | Required |    |    AFTER    |    | Decryption  |
     |          |    | Decryption  |    |             |
      '--------'      '-----------'      '-----------'

                Figure 16: Decision Tree: Validating the Payload

     There are three questions to ask:

     *  Q1.  How does the recipient receive the encrypted payload?  If the
        encrypted payload is used as the value of the suit-parameter-
        content, its integrity is already verified by the suit-
        authentication-wrapper.  Therefore, no additional integrity check
        is required.  However, if the encrypted payload is delivered via
        suit-directive-fetch from an integrated payload or from outside
        the SUIT envelope, for example "coaps://example.com/
        encrypted.bin", additional considerations must be addressed.

     *  Q2.  Are battery exhaustion attacks a concern?  If yes, the
        integrity of the encrypted payload must be checked before the
        payload is decrypted.  If no, then other questions need to be
        asked.









  Tschofenig, et al.        Expires 11 June 2026                 [Page 29]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     *  Q3.  Is the payload encrypted with an AEAD cipher?  If yes, no
        additional integrity check is required, as the recipient verifies
        the payload's integrity during decryption.  If no, integrity
        validation can occur either before or after decryption.  However,
        validating integrity before decryption is RECOMMENDED especially
        for the AES-CTR mode (see Section 8 of [RFC9459]).

  8.  Firmware Updates on IoT Devices with Flash Memory

     Embedded devices come in many forms, and the market is both large and
     fragmented.  As a result, some implementations and deployments may
     adopt firmware update procedures that differ from the descriptions
     provided here.  On a positive note, the SUIT manifest accommodates
     various deployment scenarios, thanks to the "scripting" functionality
     offered by its commands.

     This section specifically addresses firmware images on
     microcontrollers and does not pertain to generic software,
     configuration data, or machine learning models.  The differences
     arise from two main aspects:

     *  Use of Flash Memory: Flash memory in microcontrollers is a type of
        non-volatile memory that typically erases data in larger units
        called blocks, pages, or sectors, and rewrites data at the byte
        level (often 4 bytes) or larger units.  Furthermore, flash memory
        is segmented into different regions, storing the bootloader,
        various versions of firmware images (in designated slots), and
        configuration data.  An example layout of a microcontroller flash
        area is illustrated in Figure 17.

     *  Microcontroller Design: Code on microcontrollers typically cannot
        be executed from arbitrary locations in flash memory without
        additional software development and design efforts.  Consequently,
        developers often compile firmware so that the bootloader can
        execute code from a specific location in flash memory, commonly
        referred to as the "primary slot."

     Once the encrypted firmware image is transferred to the device, it is
     usually stored in a dedicated area known as the "secondary slot."

     During the next boot, the bootloader detects the new firmware image
     and begins decrypting it sector by sector, swapping it with the image
     located in the primary slot.  This method of swapping the newly
     downloaded image with the previously valid one requires two slots,
     allowing for a rollback if the new firmware fails to boot, thereby
     enhancing the robustness of the firmware update process.





  Tschofenig, et al.        Expires 11 June 2026                 [Page 30]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     The swap occurs only after verifying the signature on the plaintext.
     It is important to note that the plaintext firmware image is
     available in the primary slot only after the swap is completed,
     unless "dummy decrypt" is used to compute the hash over the plaintext
     prior to executing the decryption during the swap.  In this context,
     dummy decryption refers to decrypting the firmware image in the
     secondary slot sector by sector while computing a rolling hash over
     the resulting plaintext (also sector by sector) without performing
     the swap operation.  Although performance optimizations, such as
     conveying hashes for each sector in the manifest rather than a hash
     of the entire firmware image, are possible, these optimizations are
     not detailed in this specification.

     Without hardware-based, on-the-fly decryption, the image in the
     primary slot is available in cleartext and may need to be re-
     encrypted before copying it to the secondary slot.  This step might
     be necessary if the secondary slot has different access permissions
     or is located in off-chip flash memory, which tends to be more
     vulnerable to physical attacks.
































  Tschofenig, et al.        Expires 11 June 2026                 [Page 31]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     +--------------------------------------------------+
     | Bootloader                                       |
     +--------------------------------------------------+
     | Primary Slot                                     |
     |                                        (sector 0)|
     |..................................................|
     |                                                  |
     |                                        (sector 1)|
     |..................................................|
     |                                                  |
     |                                        (sector 2)|
     |..................................................|
     |                                                  |
     |                                           ...    |
     +--------------------------------------------------+
     | Secondary Slot                                   |
     |                                        (sector 0)|
     |..................................................|
     |                                                  |
     |                                        (sector 1)|
     |..................................................|
     |                                                  |
     |                                        (sector 2)|
     |..................................................|
     |                                                  |
     |                                           ...    |
     +--------------------------------------------------+
     | Swap Area                                        |
     |                                                  |
     +--------------------------------------------------+
     | Configuration Data                               |
     +--------------------------------------------------+

                      Figure 17: Example Flash Area Layout

     The ability to resume an interrupted firmware update is often
     essential for unattended devices, including low-end, constrained IoT
     devices.  To meet this requirement, a firmware image must be divided
     into sectors, with each sector encrypted individually using a cipher
     that does not increase the size of the resulting ciphertext (i.e., by
     avoiding the addition of an authentication tag after each encrypted
     block).

     If an update is aborted while the bootloader is decrypting the newly
     received image and swapping the sectors, the bootloader can restart
     from where it left off.  This technique enhances robustness and
     performance.




  Tschofenig, et al.        Expires 11 June 2026                 [Page 32]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     For this purpose, ciphers without integrity protection are employed
     to encrypt the firmware image.  It is crucial that integrity
     protection for the firmware image is provided, and the suit-
     parameter-image-digest, defined in Section 8.4.8.6 of
     [I-D.ietf-suit-manifest], MUST be utilized.

     [RFC9459] specifies the AES Counter (AES-CTR) mode and AES Cipher
     Block Chaining (AES-CBC) ciphers, both of which do not provide
     integrity protection.  These ciphers are suitable for firmware
     encryption in IoT devices.  However, for many other scenarios
     involving software packages, configuration information, or
     personalization data, the use of AEAD ciphers is RECOMMENDED.

     The following subsections offer additional information on the
     selection of initialization vectors (IVs) for use with AES-CTR in the
     context of firmware encryption.  A random CEK MUST be used with every
     plaintexts, as specified in Section 5, since the IVs are not random
     but are instead based on the slot/sector combination in flash memory.
     The discussion assumes that the block size of AES is significantly
     smaller than the sector size.  Typically, flash memory sectors are
     measured in KiB, necessitating the decryption of multiple AES blocks
     to complete the decryption of an entire sector.

     To offer a specific example, let us assume the slot size of a
     specific flash controller on an IoT device is 64 KiB, the sector size
     4096 bytes (4 KiB) and an AES plaintext block size of 16 bytes.  The
     counter values used with AES-CTR range from IV+0 to IV+255 in the
     first sector, and 16 * 256 counter values are required for the slot.
     This

     IV value is either communicated in the COSE header or via out-of-band
     means.

  9.  Complete Examples

     The following manifests illustrate how to deliver an encrypted
     payload along with its encryption information to devices.

     In the AES-KW examples, HMAC-256 MACs are included, utilizing the
     following secret key:

       'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
       (616161... in hex, and its length is 32)

     ES-DH examples are signed using the following ECDSA secp256r1 key:






  Tschofenig, et al.        Expires 11 June 2026                 [Page 33]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     -----BEGIN PRIVATE KEY-----
     MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgApZYjZCUGLM50VBC
     CjYStX+09jGmnyJPrpDLTz/hiXOhRANCAASEloEarguqq9JhVxie7NomvqqL8Rtv
     P+bitWWchdvArTsfKktsCYExwKNtrNHXi9OB3N+wnAUtszmR23M4tKiW
     -----END PRIVATE KEY-----

     The corresponding public key can be used to verify these examples:

     -----BEGIN PUBLIC KEY-----
     MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEhJaBGq4LqqvSYVcYnuzaJr6qi/Eb
     bz/m4rVlnIXbwK07HypLbAmBMcCjbazR14vTgdzfsJwFLbM5kdtzOLSolg==
     -----END PUBLIC KEY-----

     Each example uses SHA-256 as the digest function.

  9.1.  AES Key Wrap Example with Write Directive

     The following SUIT manifest instructs a parser to authenticate the
     manifest using COSE_Mac0 with HMAC256.  It also directs the parser to
     write and decrypt the encrypted payload into a component using the
     suit-directive-write directive.

     The SUIT manifest in diagnostic notation (with line breaks added for
     clarity) is displayed below:

     /  1/ / SUIT_Envelope_Tagged / 107({
     /  2/   / authentication-wrapper / 2: << [
     /  3/     << [
     /  4/       / digest-algorithm-id: / -16 / SHA256 /,
     /  5/       / digest-bytes: / h'037A5C325CE14078A0AADF007428EAC6
     /  6/                           59361AD9402A732410BDA542FAE94E2C'
     /  7/     ] >>,
     /  8/     << / COSE_Mac0_Tagged / 17([
     /  9/       / protected: / << {
     / 10/         / algorithm-id / 1: 5 / HMAC256 /
     / 11/       } >>,
     / 12/       / unprotected: / {},
     / 13/       / payload: / null,
     / 14/       / tag: / h'8D92599011C451A4C5FB69709FA6CA6C
     / 15/                  0F846D692BDBB3F624EC91F82F9F620A'
     / 16/     ]) >>
     / 17/   ] >>,
     / 18/   / manifest / 3: << {
     / 19/     / manifest-version / 1: 1,
     / 20/     / manifest-sequence-number / 2: 1,
     / 21/     / common / 3: << {
     / 22/       / components / 2: [
     / 23/         ['plaintext-firmware']



  Tschofenig, et al.        Expires 11 June 2026                 [Page 34]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     / 24/       ]
     / 25/     } >>,
     / 26/     / install / 20: << [
     / 27/       / fetch encrypted firmware /
     / 28/       / directive-override-parameters / 20, {
     / 29/         / parameter-content / 18:
     / 30/           h'758C4B7BBAE2C4C1D462423E0F0DC3164FFA7B85BB94D4
     / 31/             BD6D7ED26AB32FEB063385D4D3465927EC82CB5E198A59',
     / 32/         / parameter-encryption-info / 19: << 96([
     / 33/           / protected: / << {
     / 34/             / alg / 1: 1 / A128GCM /
     / 35/           } >>,
     / 36/           / unprotected: / {
     / 37/             / IV / 5: h'F14AAB9D81D51F7AD943FE87'
     / 38/           },
     / 39/           / ciphertext: / null / detached ciphertext /,
     / 40/           / recipients: / [
     / 41/             [
     / 42/               / protected: / h'',
     / 43/               / unprotected: / {
     / 44/                 / alg / 1: -3 / A128KW /,
     / 45/                 / kid / 4: 'kid-1'
     / 46/               },
     / 47/               / ciphertext: /
     / 48/                 h'75603FFC9518D794713C8CA8
     / 49/                   A115A7FB32565A6D59534D62'
     / 50/                 / CEK encrypted with KEK /
     / 51/             ]
     / 52/           ]
     / 53/         ]) >>
     / 54/       },
     / 55/
     / 56/       / decrypt encrypted firmware /
     / 57/       / directive-write / 18, 15
     / 58/         / consumes the SUIT_Encryption_Info above /
     / 59/     ] >>
     / 60/   } >>
     / 61/ })

     In hex format, the SUIT manifest is:











  Tschofenig, et al.        Expires 11 June 2026                 [Page 35]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     D86BA2025853825824822F5820037A5C325CE14078A0AADF007428EAC659
     361AD9402A732410BDA542FAE94E2C582AD18443A10105A0F658208D9259
     9011C451A4C5FB69709FA6CA6C0F846D692BDBB3F624EC91F82F9F620A03
     5898A4010102010357A102818152706C61696E746578742D6669726D7761
     72651458778414A212582E758C4B7BBAE2C4C1D462423E0F0DC3164FFA7B
     85BB94D4BD6D7ED26AB32FEB063385D4D3465927EC82CB5E198A5913583E
     D8608443A10101A1054CF14AAB9D81D51F7AD943FE87F6818340A2012204
     456B69642D31581875603FFC9518D794713C8CA8A115A7FB32565A6D5953
     4D62120F

  9.2.  AES Key Wrap Example with Fetch + Copy Directives

     The following SUIT manifest instructs a parser to fetch and store the
     encrypted payload.  Subsequently, the payload is decrypted and copied
     into another component using the suit-directive-copy directive.  This
     approach is particularly effective for constrained devices with
     execute-in-place (XIP) flash memory.

     The SUIT manifest in diagnostic notation (with line breaks added for
     clarity) is displayed below:

     /  1/ / SUIT_Envelope_Tagged / 107({
     /  2/   / authentication-wrapper / 2: << [
     /  3/     << [
     /  4/       / digest-algorithm-id: / -16 / SHA256 /,
     /  5/       / digest-bytes: / h'3C92AECEAA7225DDD5129A83B2842BF2
     /  6/                           8CC53B2C9467C5BF256E7108F2DA7C9C'
     /  7/     ] >>,
     /  8/     << / COSE_Mac0_Tagged / 17([
     /  9/       / protected: / << {
     / 10/         / algorithm-id / 1: 5 / HMAC256 /
     / 11/       } >>,
     / 12/       / unprotected: / {},
     / 13/       / payload: / null,
     / 14/       / tag: / h'46CB34181A04B967023D4C9E136DC5DC
     / 15/                  591D8A9BE9365DE4D282C9D6168C01FB'
     / 16/     ]) >>
     / 17/   ] >>,
     / 18/   / manifest / 3: << {
     / 19/     / manifest-version / 1: 1,
     / 20/     / manifest-sequence-number / 2: 1,
     / 21/     / common / 3: << {
     / 22/       / components / 2: [
     / 23/         ['plaintext-firmware'],
     / 24/         ['encrypted-firmware']
     / 25/       ]
     / 26/     } >>,
     / 27/     / install / 20: << [



  Tschofenig, et al.        Expires 11 June 2026                 [Page 36]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     / 28/       / fetch encrypted firmware /
     / 29/       / directive-set-component-index / 12,
     / 30/         1 / ['encrypted-firmware'] /,
     / 31/       / directive-override-parameters / 20, {
     / 32/         / parameter-image-size / 14: 46,
     / 33/         / parameter-uri / 21:
     / 34/           "coaps://example.com/encrypted-firmware"
     / 35/       },
     / 36/       / directive-fetch / 21, 15,
     / 37/
     / 38/       / decrypt encrypted firmware /
     / 39/       / directive-set-component-index / 12,
     / 40/         0 / ['plaintext-firmware'] /,
     / 41/       / directive-override-parameters / 20, {
     / 42/         / parameter-encryption-info / 19: << 96([
     / 43/           / protected: / << {
     / 44/             / alg / 1: 1 / A128GCM /
     / 45/           } >>,
     / 46/           / unprotected: / {
     / 47/             / IV / 5: h'F14AAB9D81D51F7AD943FE87'
     / 48/           },
     / 49/           / ciphertext: / null / detached ciphertext /,
     / 50/           / recipients: / [
     / 51/             [
     / 52/               / protected: / h'',
     / 53/               / unprotected: / {
     / 54/                 / alg / 1: -3 / A128KW /,
     / 55/                 / kid / 4: 'kid-1'
     / 56/               },
     / 57/               / ciphertext: /
     / 58/                 h'75603FFC9518D794713C8CA8
     / 59/                   A115A7FB32565A6D59534D62'
     / 60/                 / CEK encrypted with KEK /
     / 61/             ]
     / 62/           ]
     / 63/         ]) >>,
     / 64/         / parameter-source-component / 22:
     / 65/           1 / ['encrypted-firmware'] /
     / 66/       },
     / 67/       / directive-copy / 22,
     / 68/         15 / consumes the SUIT_Encryption_Info above /
     / 69/     ] >>
     / 70/   } >>
     / 71/ })







  Tschofenig, et al.        Expires 11 June 2026                 [Page 37]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     The default storage area is defined by the component identifier (see
     Section 8.4.5.1 of [I-D.ietf-suit-manifest]).  In this example, the
     component identifier for component #0 is ['plaintext-firmware'] and
     the file path "/plaintext-firmware" is the expected location.

     While parsing the manifest, the behavior of SUIT manifest processor
     would be

     *  [L2-L17] authenticates the manifest part on [L18-L68]

     *  [L22-L25] gets two component identifiers; ['plaintext-firmware']
        for component #0, and ['encrypted-firmware'] for component # 1
        respectively

     *  [L29] sets current component index # 1 (the lasting directives
        target ['encrypted-firmware'])

     *  [L33-L34] sets source uri parameter "coaps://example.com/
        encrypted-firmware"

     *  [L36] fetches content from source uri into ['encrypted-firmware']

     *  [L39] sets current component index # 0 (the lasting directives
        target ['plaintext-firmware'])

     *  [L42-L62] sets SUIT encryption info parameter

     *  [L63-L64] sets source component index parameter # 1

     *  [L66] decrypts component # 1 (source component index) and stores
        the result into component # 0 (current component index)

     Table 1 lists the features from the SUIT manifest specification,
     which are re-used by this specification.

















  Tschofenig, et al.        Expires 11 June 2026                 [Page 38]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


          +===============================+=========+===============+
          | Feature Name                  | Abbr.   | Manifest Ref. |
          +===============================+=========+===============+
          | component identifier          | CI      | Sec. 8.4.5.1  |
          +-------------------------------+---------+---------------+
          | (destination) component index | dst-CI  | Sec. 8.4.10.1 |
          +-------------------------------+---------+---------------+
          | (destination) component slot  | dst-CS  | Sec. 8.4.8.8  |
          | OPTIONAL param                |         |               |
          +-------------------------------+---------+---------------+
          | (source) uri OPTIONAL         | src-URI | Sec. 8.4.8.10 |
          | parameter                     |         |               |
          +-------------------------------+---------+---------------+
          | source component index        | src-CI  | Sec. 8.4.8.11 |
          | OPTIONAL parameter            |         |               |
          +-------------------------------+---------+---------------+

                       Table 1: Example Flash Area Layout

     The resulting state of the SUIT manifest processor is shown in
     Table 2.

      +==============+========================+========================+
      | Abbreviation | Plaintext              | Ciphertext             |
      +==============+========================+========================+
      | CI           | ['plaintext-firmware'] | ['encrypted-firmware'] |
      +--------------+------------------------+------------------------+
      | dst-CI       | 0                      | 1                      |
      +--------------+------------------------+------------------------+
      | dst-CS       | N/A                    | N/A                    |
      +--------------+------------------------+------------------------+
      | src-URI      | N/A                    | "coaps://example.com/  |
      |              |                        | encrypted-firmware"    |
      +--------------+------------------------+------------------------+
      | src-CI       | 1                      | N/A                    |
      +--------------+------------------------+------------------------+

                      Table 2: Manifest Processor State

     In hex format, the SUIT manifest shown above is:











  Tschofenig, et al.        Expires 11 June 2026                 [Page 39]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     D86BA2025853825824822F58203C92AECEAA7225DDD5129A83B2842BF28C
     C53B2C9467C5BF256E7108F2DA7C9C582AD18443A10105A0F6582046CB34
     181A04B967023D4C9E136DC5DC591D8A9BE9365DE4D282C9D6168C01FB03
     58B2A40101020103582BA102828152706C61696E746578742D6669726D77
     6172658152656E637279707465642D6669726D7761726514587C8C0C0114
     A20E182E157826636F6170733A2F2F6578616D706C652E636F6D2F656E63
     7279707465642D6669726D77617265150F0C0014A213583ED8608443A101
     01A1054CF14AAB9D81D51F7AD943FE87F6818340A2012204456B69642D31
     581875603FFC9518D794713C8CA8A115A7FB32565A6D59534D621601160F

     The encrypted payload (with a line feed added) to be fetched from
     "coaps://example.com/encrypted-firmware" is:

     758C4B7BBAE2C4C1D462423E0F0DC3164FFA7B85BB94D4BD6D7ED26AB32F
     EB063385D4D3465927EC82CB5E198A59

     The previous example does not utilize storage slots.  However, it is
     possible to implement this functionality for devices that support
     slots in flash memory.  In the enhanced example below, we reference
     the slots using [h'00'] and [h'01'].  In this context, the component
     identifier [h'00'] designates component slot #0.

     /  1/ / SUIT_Envelope_Tagged / 107({
     /  2/   / authentication-wrapper / 2: << [
     /  3/     << [
     /  4/       / digest-algorithm-id: / -16 / SHA256 /,
     /  5/       / digest-bytes: / h'6D74BD3110A2573236E03DD78693D5B2
     /  6/                           1C299C917A4327D9939DDF3582A41DE3'
     /  7/     ] >>,
     /  8/     << / COSE_Mac0_Tagged / 17([
     /  9/       / protected: / << {
     / 10/         / algorithm-id / 1: 5 / HMAC256 /
     / 11/       } >>,
     / 12/       / unprotected: / {},
     / 13/       / payload: / null,
     / 14/       / tag: / h'E6837A54A9B5813F8D5EDAD48AB96D5D
     / 15/                  7388D9D1C89AB29EC55AE964F67E01ED'
     / 16/     ]) >>
     / 17/   ] >>,
     / 18/   / manifest / 3: << {
     / 19/     / manifest-version / 1: 1,
     / 20/     / manifest-sequence-number / 2: 1,
     / 21/     / common / 3: << {
     / 22/       / components / 2: [
     / 23/         [h'00'],
     / 24/         [h'01']
     / 25/       ]
     / 26/     } >>,



  Tschofenig, et al.        Expires 11 June 2026                 [Page 40]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     / 27/     / install / 20: << [
     / 28/       / fetch encrypted firmware /
     / 29/       / directive-set-component-index / 12, 1 / [h'01'] /,
     / 30/       / directive-override-parameters / 20, {
     / 31/         / parameter-image-size / 14: 46,
     / 32/         / parameter-uri / 21:
     / 33/           "coaps://example.com/encrypted-firmware"
     / 34/       },
     / 35/       / directive-fetch / 21, 15,
     / 36/
     / 37/       / decrypt encrypted firmware /
     / 38/       / directive-set-component-index / 12, 0 / ['00'] /,
     / 39/       / directive-override-parameters / 20, {
     / 40/         / parameter-encryption-info / 19: << 96([
     / 41/           / protected: / << {
     / 42/             / alg / 1: 1 / A128GCM /
     / 43/           } >>,
     / 44/           / unprotected: / {
     / 45/             / IV / 5: h'F14AAB9D81D51F7AD943FE87'
     / 46/           },
     / 47/           / ciphertext: / null / detached ciphertext /,
     / 48/           / recipients: / [
     / 49/             [
     / 50/               / protected: / h'',
     / 51/               / unprotected: / {
     / 52/                 / alg / 1: -3 / A128KW /,
     / 53/                 / kid / 4: 'kid-1'
     / 54/               },
     / 55/               / ciphertext: /
     / 56/                 h'75603FFC9518D794713C8CA8
     / 57/                   A115A7FB32565A6D59534D62'
     / 58/                 / CEK encrypted with KEK /
     / 59/             ]
     / 60/           ]
     / 61/         ]) >>,
     / 62/         / parameter-source-component / 22: 1 / [h'01'] /
     / 63/       },
     / 64/       / directive-copy / 22, 15
     / 65/         / consumes the SUIT_Encryption_Info above /
     / 66/     ] >>
     / 67/   } >>
     / 68/ })









  Tschofenig, et al.        Expires 11 June 2026                 [Page 41]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


  9.3.  ES-DH Example with Write + Copy Directives

     The following SUIT manifest instructs a parser to authenticate the
     manifest using COSE_Sign1 with ES256.  It also directs the parser to
     write and decrypt the encrypted payload into a component via the
     suit-directive-write directive.

     The SUIT manifest in diagnostic notation (formatted with line breaks
     for clarity) is presented below:

     /  1/ / SUIT_Envelope_Tagged / 107({
     /  2/   / authentication-wrapper / 2: << [
     /  3/     << [
     /  4/       / digest-algorithm-id: / -16 / SHA256 /,
     /  5/       / digest-bytes: / h'1DB69EF1477E9942815F29F78E09957B
     /  6/                           26B4ADD03902BDB3D1EDF3DA2075F593'
     /  7/     ] >>,
     /  8/     << / COSE_Sign1_Tagged / 18([
     /  9/       / protected: / << {
     / 10/         / algorithm-id / 1: -9 / ESP256 /
     / 11/       } >>,
     / 12/       / unprotected: / {},
     / 13/       / payload: / null,
     / 14/       / signature: / h'2B20A797AC7DBEBC53147592BB110AEC
     / 15/                        43A2489AC19A169BB59FF6BD429300A9
     / 16/                        719FEB7DF277E4B8D1D821C816854229
     / 17/                        F266AC62AFD9DB52114F608EE66B187B'
     / 18/     ]) >>
     / 19/   ] >>,
     / 20/   / manifest / 3: << {
     / 21/     / manifest-version / 1: 1,
     / 22/     / manifest-sequence-number / 2: 1,
     / 23/     / common / 3: << {
     / 24/       / components / 2: [
     / 25/         ['decrypted-firmware']
     / 26/       ]
     / 27/     } >>,
     / 28/     / install / 20: << [
     / 29/       / directive-set-component-index / 12,
     / 30/         0 / ['plaintext-firmware'] /,
     / 31/       / directive-override-parameters / 20, {
     / 32/         / parameter-content / 18:
     / 33/           h'758C4B7BBAE2C4C1D462423E0F0DC3164FFA7B85BB94D4
     / 34/             BD6D7ED26AB32FEB063385D4D3465927EC82CB5E198A59',
     / 35/         / parameter-encryption-info / 19: << 96([
     / 36/           / protected: / << {
     / 37/             / alg / 1: 1 / A128GCM /
     / 38/           } >>,



  Tschofenig, et al.        Expires 11 June 2026                 [Page 42]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     / 39/           / unprotected: / {
     / 40/             / IV / 5: h'F14AAB9D81D51F7AD943FE87'
     / 41/           },
     / 42/           / ciphertext: / null / detached ciphertext /,
     / 43/           / recipients: / [
     / 44/             [
     / 45/               / protected: / << {
     / 46/                 / alg / 1: -29 / ECDH-ES + A128KW /
     / 47/               } >>,
     / 48/               / unprotected: / {
     / 49/                 / ephemeral key / -1: {
     / 50/                   / kty / 1: 2 / EC2 /,
     / 51/                   / crv / -1: 1 / P-256 /,
     / 52/                   / x / -2:
     / 53/                     h'73024F415AA51529A66CCEFD88F3F62A
     / 54/                       734492FF45F6AD37FD2888E73EAF19DA',
     / 55/                   / y / -3:
     / 56/                     h'4005B48A6FD091AA6ABFE3CFBEEDE88B
     / 57/                       347E521D43405FDBD7D2CFF0EBC21B26'
     / 58/                 },
     / 59/                 / kid / 4: 'kid-2'
     / 60/               },
     / 61/               / ciphertext: /
     / 62/                 h'A06B8E6550F308712B1DF044
     / 63/                   B21B7D11D9B22792F1DE0997'
     / 64/                 / CEK encrypted with KEK /
     / 65/             ]
     / 66/           ]
     / 67/         ]) >>
     / 68/       },
     / 69/       / directive-write / 18,
     / 70/         15 / consumes the SUIT_Encryption_Info above /
     / 71/     ] >>
     / 72/   } >>
     / 73/ })

     In hex format, the SUIT manifest is this:














  Tschofenig, et al.        Expires 11 June 2026                 [Page 43]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     D86BA2025873825824822F58201DB69EF1477E9942815F29F78E09957B26
     B4ADD03902BDB3D1EDF3DA2075F593584AD28443A10128A0F658402B20A7
     97AC7DBEBC53147592BB110AEC43A2489AC19A169BB59FF6BD429300A971
     9FEB7DF277E4B8D1D821C816854229F266AC62AFD9DB52114F608EE66B18
     7B0358E8A4010102010357A1028181526465637279707465642D6669726D
     776172651458C7860C0014A212582E758C4B7BBAE2C4C1D462423E0F0DC3
     164FFA7B85BB94D4BD6D7ED26AB32FEB063385D4D3465927EC82CB5E198A
     5913588CD8608443A10101A1054CF14AAB9D81D51F7AD943FE87F6818344
     A101381CA220A40102200121582073024F415AA51529A66CCEFD88F3F62A
     734492FF45F6AD37FD2888E73EAF19DA2258204005B48A6FD091AA6ABFE3
     CFBEEDE88B347E521D43405FDBD7D2CFF0EBC21B2604456B69642D325818
     A06B8E6550F308712B1DF044B21B7D11D9B22792F1DE0997120F

  9.4.  ES-DH Example with Dependency

     The following SUIT manifest requests a parser to resolve the
     dependency.

     The dependent manifest is signed with another key:

     -----BEGIN EC PRIVATE KEY-----
     MHcCAQEEIIQa67e56m8CYL5zVaJFiLl30j0qxb8ray2DeUMqH+qYoAoGCCqGSM49
     AwEHoUQDQgAEDpCKqPBm2x8ITgw2UsY5Ur2Z8qW9si+eATZ6rQOrpot32hvYrE8M
     tJC6IQZIv3mrFk1JrTVR1x0xSydJ7kLSmg==
     -----END EC PRIVATE KEY-----

     The dependency manifest is embedded as an integrated-dependency and
     referred to by the "#dependency-manifest" URI.

     The SUIT manifest in diagnostic notation (with line breaks added for
     readability) is shown here:

     /  1/ / SUIT_Envelope_Tagged / 107({
     /  2/   / authentication-wrapper / 2: << [
     /  3/     << [
     /  4/       / digest-algorithm-id: / -16 / SHA256 /,
     /  5/       / digest-bytes: / h'A00CB6C85515C1EF471B50B542FACDD8
     /  6/                           8B71B3C7EA2A43DE13D32C4A99056FE9'
     /  7/     ] >>,
     /  8/     << / COSE_Sign1_Tagged / 18([
     /  9/       / protected: / << {
     / 10/         / algorithm-id / 1: -9 / ESP256 /
     / 11/       } >>,
     / 12/       / unprotected: / {},
     / 13/       / payload: / null,
     / 14/       / signature: / h'3000301B7C54B3383CC4723C4B7BE667
     / 15/                        C6760C504213A105DD38401BED5EEF8E
     / 16/                        B915F8313420104F59467D76790A0EA2



  Tschofenig, et al.        Expires 11 June 2026                 [Page 44]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     / 17/                        20B6021B4ED87051B3B4A8D05F7E0254'
     / 18/     ]) >>
     / 19/   ] >>,
     / 20/   / manifest / 3: << {
     / 21/     / manifest-version / 1: 1,
     / 22/     / manifest-sequence-number / 2: 1,
     / 23/     / common / 3: << {
     / 24/       / dependencies / 1: {
     / 25/         / component-index / 1: {
     / 26/           / dependency-prefix / 1: [
     / 27/              'dependency-manifest.suit'
     / 28/           ]
     / 29/         }
     / 30/       },
     / 31/       / components / 2: [
     / 32/         ['decrypted-firmware']
     / 33/       ]
     / 34/     } >>,
     / 35/     / manifest-component-id / 5: [
     / 36/       'dependent-manifest.suit'
     / 37/     ],
     / 38/     / install / 20: << [
     / 39/       / NOTE: set SUIT_Encryption_Info /
     / 40/       / directive-set-component-index / 12,
     / 41/         0 / ['decrypted-firmware'] /,
     / 42/       / directive-override-parameters / 20, {
     / 43/         / parameter-content / 18:
     / 44/           h'758C4B7BBAE2C4C1D462423E0F0DC3164FFA7B85BB94D4
     / 45/             BD6D7ED26AB32FEB063385D4D3465927EC82CB5E198A59',
     / 46/         / parameter-encryption-info / 19: << 96([
     / 47/           / protected: / << {
     / 48/             / alg / 1: 1 / A128GCM /
     / 49/           } >>,
     / 50/           / unprotected: / {
     / 51/             / IV / 5: h'F14AAB9D81D51F7AD943FE87'
     / 52/           },
     / 53/           / ciphertext: / null / detached ciphertext /,
     / 54/           / recipients: / [
     / 55/             [
     / 56/               / protected: / << {
     / 57/                 / alg / 1: -29 / ECDH-ES + A128KW /
     / 58/               } >>,
     / 59/               / unprotected: / {
     / 60/                 / ephemeral key / -1: {
     / 61/                   / kty / 1: 2 / EC2 /,
     / 62/                   / crv / -1: 1 / P-256 /,
     / 63/                   / x / -2:
     / 64/                     h'73024F415AA51529A66CCEFD88F3F62A



  Tschofenig, et al.        Expires 11 June 2026                 [Page 45]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     / 65/                       734492FF45F6AD37FD2888E73EAF19DA',
     / 66/                   / y / -3:
     / 67/                     h'4005B48A6FD091AA6ABFE3CFBEEDE88B
     / 68/                       347E521D43405FDBD7D2CFF0EBC21B26'
     / 69/                 },
     / 70/                 / kid / 4: 'kid-2'
     / 71/               },
     / 72/               / ciphertext: /
     / 73/                 h'A06B8E6550F308712B1DF044
     / 74/                   B21B7D11D9B22792F1DE0997'
     / 75/                 / CEK encrypted with KEK /
     / 76/             ]
     / 77/           ]
     / 78/         ]) >>
     / 79/       },
     / 80/
     / 81/       / NOTE: call dependency-manifest /
     / 82/       / directive-set-component-index / 12,
     / 83/         1 / ['dependenty-manifest.suit'] /,
     / 84/       / directive-override-parameters / 20, {
     / 85/         / parameter-image-digest / 3: << [
     / 86/           / algorithm-id / -16 / SHA256 /,
     / 87/           / digest-bytes / h'4B15C90FBD776A820E7E733DF040D90B
     / 88/                              356B5C75982ECAECE8673818179BDF16'
     / 89/         ] >>,
     / 90/         / parameter-image-size / 14: 247,
     / 91/         / parameter-uri / 21: "#dependency-manifest"
     / 92/       },
     / 93/       / directive-fetch / 21, 15,
     / 94/       / condition-dependency-integrity / 7, 15,
     / 95/       / directive-process-dependency / 11, 15
     / 96/     ] >>
     / 97/   } >>,
     / 98/   "#dependency-manifest": <<
     / 99/     / SUIT_Envelope_Tagged / 107({
     /100/       / authentication-wrapper / 2: << [
     /101/         << [
     /102/           / digest-algorithm-id: / -16 / SHA256 /,
     /103/           / digest-bytes: /
     /104/             h'4B15C90FBD776A820E7E733DF040D90B
     /105/               356B5C75982ECAECE8673818179BDF16'
     /106/         ] >>,
     /107/         << / COSE_Sign1_Tagged / 18([
     /108/           / protected: / << {
     /109/             / algorithm-id / 1: -9 / ESP256 /
     /110/           } >>,
     /111/           / unprotected: / {},
     /112/           / payload: / null,



  Tschofenig, et al.        Expires 11 June 2026                 [Page 46]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     /113/           / signature: / h'BF95C29295B45470EF819E7F4E3C9084
     /114/                            F4534E26469C0A0F2B8B9664881A5359
     /115/                            D500F81BD3A6436A025C3E92E51CD714
     /116/                            8F83DF47D29FF253F8D41B4D350A2B75'
     /117/         ]) >>
     /118/       ] >>,
     /119/       / manifest / 3: << {
     /120/         / manifest-version / 1: 1,
     /121/         / manifest-sequence-number / 2: 1,
     /122/         / common / 3: << {
     /123/           / components / 2: [
     /124/             ['decrypted-firmware']
     /125/           ],
     /126/           / shared-sequence / 4: << [
     /127/             / directive-set-componnt-index / 12,
     /128/               0 / ['decrypted-firmware'] /,
     /129/             / directive-override-parameters / 20, {
     /130/               / parameter-image-digest / 3: << [
     /131/                 / algorithm-id / -16 / SHA256 /,
     /132/                 / digest-bytes /
     /133/                   h'36921488FE6680712F734E11F58D87EE
     /134/                     B66D4B21A8A1AD3441060814DA16D50F'
     /135/               ] >>,
     /136/               / parameter-image-size / 14: 30
     /137/             }
     /138/           ] >>
     /139/         } >>,
     /140/         / manifest-component-id / 5: [
     /141/           'dependency-manifest.suit'
     /142/         ],
     /143/         / validate / 7: << [
     /144/           / condition-image-match / 3, 15
     /145/         ] >>,
     /146/         / install / 20: << [
     /147/           / directive-set-component-index / 12,
     /148/             0 / ['decrypted-firmware'] /,
     /149/           / directive-write / 18, 15
     /150/             / consumes the SUIT_Encryption_Info /
     /151/             / set by the dependent /,
     /152/           / condition-image-match / 3, 15
     /153/             / check the integrity of the decrypted payload /
     /154/         ] >>
     /155/       } >>
     /156/     })
     /157/   >>
     /158/ })

     In hex format, the SUIT manifest is this:



  Tschofenig, et al.        Expires 11 June 2026                 [Page 47]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     D86BA3025873825824822F5820A00CB6C85515C1EF471B50B542FACDD88B
     71B3C7EA2A43DE13D32C4A99056FE9584AD28443A10128A0F65840300030
     1B7C54B3383CC4723C4B7BE667C6760C504213A105DD38401BED5EEF8EB9
     15F8313420104F59467D76790A0EA220B6021B4ED87051B3B4A8D05F7E02
     540359016CA501010201035837A201A101A101815818646570656E64656E
     63792D6D616E69666573742E73756974028181526465637279707465642D
     6669726D77617265058157646570656E64656E742D6D616E69666573742E
     737569741459010F8E0C0014A212582E758C4B7BBAE2C4C1D462423E0F0D
     C3164FFA7B85BB94D4BD6D7ED26AB32FEB063385D4D3465927EC82CB5E19
     8A5913588CD8608443A10101A1054CF14AAB9D81D51F7AD943FE87F68183
     44A101381CA220A40102200121582073024F415AA51529A66CCEFD88F3F6
     2A734492FF45F6AD37FD2888E73EAF19DA2258204005B48A6FD091AA6ABF
     E3CFBEEDE88B347E521D43405FDBD7D2CFF0EBC21B2604456B69642D3258
     18A06B8E6550F308712B1DF044B21B7D11D9B22792F1DE09970C0114A303
     5824822F58204B15C90FBD776A820E7E733DF040D90B356B5C75982ECAEC
     E8673818179BDF160E18F7157423646570656E64656E63792D6D616E6966
     657374150F070F0B0F7423646570656E64656E63792D6D616E6966657374
     58F7D86BA2025873825824822F58204B15C90FBD776A820E7E733DF040D9
     0B356B5C75982ECAECE8673818179BDF16584AD28443A10128A0F65840BF
     95C29295B45470EF819E7F4E3C9084F4534E26469C0A0F2B8B9664881A53
     59D500F81BD3A6436A025C3E92E51CD7148F83DF47D29FF253F8D41B4D35
     0A2B7503587BA601010201035849A2028181526465637279707465642D66
     69726D7761726504582F840C0014A2035824822F582036921488FE668071
     2F734E11F58D87EEB66D4B21A8A1AD3441060814DA16D50F0E181E058158
     18646570656E64656E63792D6D616E69666573742E73756974074382030F
     1447860C00120F030F

  10.  Operational Considerations

     The algorithms outlined in this document assume that the party
     responsible for payload encryption:

     *  shares a key-encryption key (KEK) with the recipient (for use with
        the AES Key Wrap scheme), or

     *  possesses the recipient's public key (for use with ES-DH).

     Both scenarios necessitate initial communication to distribute these
     keys among the involved parties.  This interaction can be facilitated
     by a device management protocol, as described in [RFC9019], or may
     occur earlier in the device lifecycle, such as during manufacturing
     or commissioning.  In addition to the keying material, key
     identifiers and algorithm information must also be provisioned.  This
     specification does not impose any requirements on the structure of
     the key identifier.






  Tschofenig, et al.        Expires 11 June 2026                 [Page 48]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     In certain situations, third-party companies analyze binaries for
     known security vulnerabilities.  However, encrypted payloads hinder
     this type of analysis.  Consequently, these third-party companies
     must either be granted access to the plaintext binary before
     encryption or be authorized recipients of the encrypted payloads.

  11.  Security Considerations

     This entire document focuses on security.

     It is considered best security practice to use different keys for
     different purposes.  For instance, the key-encryption key (KEK)
     utilized in an AES-KW-based content key distribution method for
     encryption should be distinct from the long-term symmetric key
     employed for authentication in a communication security protocol.

     The recipient MUST verify that the algorithm identifiers carried in
     both the outer header of the COSE_Encrypt structure and within each
     recipient structure correspond to the algorithm configuration
     expected at the recipient, as defined by local policy.  If any
     mismatch is detected between the algorithm identifiers and the
     configured algorithms, the recipient MUST reject the message.  This
     prevents an attacker from modifying the algorithm field to perform a
     downgrade attack (for example, changing an AEAD cipher to a non-AEAD
     cipher) or to cause the recipient to use a key for an unintended
     purpose.

     To further minimize the attack surface, it may be advantageous to use
     different long-term keys for encrypting various types of payloads.
     For example, KEK_1 could be used with an AES-KW content key
     distribution method to encrypt a firmware image, while KEK_2 would
     encrypt configuration data.

     A substantial part of this document focuses on content key
     distribution, utilizing two primary methods: AES Key Wrap (AES-KW)
     and Ephemeral-Static Diffie-Hellman (ES-DH).  The key properties
     associated with their deployment are summarized in Table 3.














  Tschofenig, et al.        Expires 11 June 2026                 [Page 49]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     +=================+=====================+============+==============+
     | Number ofLong-  | Number of           |Use Case    | Recommended? |
     | TermKeys        | ContentEncryption   |            |              |
     |                 | Keys (CEKs)         |            |              |
     +=================+=====================+============+==============+
     | Same key        | Single CEK per      |Legacy Usage| No, bad      |
     | for all         | payload shared      |            | practice     |
     | devices         | with all devies     |            |              |
     +-----------------+---------------------+------------+--------------+
     | One key         | Single CEK per      |Efficient   | Yes          |
     | per device      | payload shared      |Payload     |              |
     |                 | with all devies     |Distribution|              |
     +-----------------+---------------------+------------+--------------+
     | One Key         | One CEK per         |Point-to-   | Yes          |
     | per device      | payload             |Point       |              |
     |                 | encryption          |Payload     |              |
     |                 | transaction         |Distribution|              |
     |                 | per device          |            |              |
     +-----------------+---------------------+------------+--------------+

                 Table 3: Content Key Distribution: Comparison

     The use of firmware encryption in battery-powered IoT devices
     introduces the risk of a battery exhaustion attack.  This attack
     exploits the high energy cost of flash memory operations.  To execute
     this attack, the adversary must be able to swap detached payloads and
     trick the device into processing an incorrect payload.  Payload
     swapping is feasible only if there is no communication security
     protocol between the device and the distribution system or if the
     distribution system itself has been compromised.

     While the security features provided by the manifest can detect this
     attack and prevent the device from booting with an incorrectly
     supplied payload, the energy-intensive flash operations will have
     already occurred.  As a result, these operations can diminish the
     lifespan of the devices, making battery-powered IoT devices
     particularly susceptible to such attacks.  For further discussion on
     IoT devices using flash memory, see Section 8.

     Including the digest of the encrypted firmware in the manifest
     enables the device to detect a battery exhaustion attack before
     energy-consuming decryption and flash memory copy or swap operations
     take place.

     As specified in Section 8 of [RFC9459], recipients must perform
     integrity checks before decryption to mitigate padding oracle
     vulnerabilities, particularly when using the AES-CTR mode.  This
     practice not only prevents padding oracle attacks but also protects



  Tschofenig, et al.        Expires 11 June 2026                 [Page 50]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     against format and decryption oracles, as decryption is skipped if
     the integrity check fails.  For further details on payload integrity
     validation, see Section 7.2.

     The same combination of IV and AES key MUST NOT be reused.  This
     requirement applies not only to AES-CTR mode, as specified in
     Section 4 of [RFC9459], but also to other content encryption
     algorithms, including AEAD ciphers like AES-GCM.

     Although the examples in this document use the coaps scheme for
     payload retrieval, alternative URI schemes like coap and http can
     also be used.  This flexibility is possible because the SUIT manifest
     and this extension do not rely on the TLS layer for security.

     Confidentiality, integrity, and authentication are ensured by the
     SUIT manifest and the extensions defined in this document.  For
     details on how the SUIT manifest meets the security requirements
     outlined in [RFC9124], refer to Section 12 of
     [I-D.ietf-suit-manifest].  Additional security considerations for the
     cryptographic primitives used in these extensions are discussed in
     Section 11 of [RFC9053] and Section 8 of [RFC9459].

  12.  IANA Considerations

     IANA is asked to add the following value to the SUIT Parameters
     registry at [iana-suit], which is established by Section 11.5 of
     [I-D.ietf-suit-manifest]:

     Label      Name                 Reference
     -----------------------------------------
     TBD19      Encryption Info      Section 4

     RFC Editor's Note (TBD19): The value for the Encryption Info
     parameter is set to 19, as the proposed value.

  13.  References

  13.1.  Normative References

     [I-D.ietf-suit-manifest]
                Moran, B., Tschofenig, H., Birkholz, H., Zandberg, K., and
                O. Rønningstad, "A Concise Binary Object Representation
                (CBOR)-based Serialization Format for the Software Updates
                for Internet of Things (SUIT) Manifest", Work in Progress,
                Internet-Draft, draft-ietf-suit-manifest-34, 28 May 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-suit-
                manifest-34>.




  Tschofenig, et al.        Expires 11 June 2026                 [Page 51]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     [I-D.ietf-suit-mti]
                Moran, B., Rønningstad, O., and A. Tsukamoto,
                "Cryptographic Algorithms for Internet of Things (IoT)
                Devices", Work in Progress, Internet-Draft, draft-ietf-
                suit-mti-23, 22 July 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-suit-
                mti-23>.

     [I-D.ietf-suit-trust-domains]
                Moran, B. and K. Takayama, "Software Update for the
                Internet of Things (SUIT) Manifest Extensions for Multiple
                Trust Domain", Work in Progress, Internet-Draft, draft-
                ietf-suit-trust-domains-12, 22 July 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-suit-
                trust-domains-12>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC3394]  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/rfc/rfc3394>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://www.rfc-editor.org/rfc/rfc9052>.

     [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
                August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

     [RFC9459]  Housley, R. and H. Tschofenig, "CBOR Object Signing and
                Encryption (COSE): AES-CTR and AES-CBC", RFC 9459,
                DOI 10.17487/RFC9459, September 2023,
                <https://www.rfc-editor.org/rfc/rfc9459>.

  13.2.  Informative References

     [I-D.ietf-teep-usecase-for-cc-in-network]
                Chen, M., Yang, P., Su, L., and T. Pang, "TEEP Usecase for
                Confidential Computing in Network", Work in Progress,



  Tschofenig, et al.        Expires 11 June 2026                 [Page 52]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


                Internet-Draft, draft-ietf-teep-usecase-for-cc-in-network-
                11, 30 June 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-teep-usecase-for-cc-in-network-11>.

     [iana-suit]
                Internet Assigned Numbers Authority, "IANA SUIT Manifest
                Registry", 2023, <TBD>.

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

     [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
                RFC 5652, DOI 10.17487/RFC5652, September 2009,
                <https://www.rfc-editor.org/rfc/rfc5652>.

     [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/rfc/rfc5869>.

     [RFC8937]  Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
                and C. Wood, "Randomness Improvements for Security
                Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
                <https://www.rfc-editor.org/rfc/rfc8937>.

     [RFC9019]  Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
                Firmware Update Architecture for Internet of Things",
                RFC 9019, DOI 10.17487/RFC9019, April 2021,
                <https://www.rfc-editor.org/rfc/rfc9019>.

     [RFC9124]  Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest
                Information Model for Firmware Updates in Internet of
                Things (IoT) Devices", RFC 9124, DOI 10.17487/RFC9124,
                January 2022, <https://www.rfc-editor.org/rfc/rfc9124>.

     [RFC9397]  Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
                "Trusted Execution Environment Provisioning (TEEP)
                Architecture", RFC 9397, DOI 10.17487/RFC9397, July 2023,
                <https://www.rfc-editor.org/rfc/rfc9397>.

     [ROP]      Wikipedia, "Return-Oriented Programming", March 2023,
                <https://en.wikipedia.org/wiki/Return-
                oriented_programming>.





  Tschofenig, et al.        Expires 11 June 2026                 [Page 53]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     [SP800-56] NIST, "Recommendation for Pair-Wise Key Establishment
                Schemes Using Discrete Logarithm Cryptography, NIST
                Special Publication 800-56A Revision 3", April 2018,
                <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
                NIST.SP.800-56Ar3.pdf>.

  Appendix A.  Full CDDL

     The following CDDL must be appended to the SUIT Manifest CDDL.  The
     SUIT CDDL is defined in Appendix A of [I-D.ietf-suit-manifest]

     SUIT_Encryption_Info = #6.96(COSE_Encrypt)

     $$SUIT_Parameters //= (suit-parameter-encryption-info =>
         bstr .cbor SUIT_Encryption_Info)

     suit-parameter-encryption-info = 19

  Acknowledgements

     We would like to thank Henk Birkholz for his feedback on the CDDL
     description in this document.  Additionally, we would like to thank
     Michael Richardson, Dick Brooks, Øyvind Rønningstad, Dave Thaler,
     Laurence Lundblade, Christian Amsüss, Ruud Derwig, Martin Thomson.
     Kris Kwiatkowski, Suresh Krishnan and Carsten Bormann for their
     review feedback.

     We would like to thank the IESG, in particular Deb Cooley, Éric
     Vyncke and Roman Danyliw, for their help to improve the quality of
     this document.

  Authors' Addresses

     Hannes Tschofenig
     University of Applied Sciences Bonn-Rhein-Sieg
     Email: Hannes.Tschofenig@gmx.net


     Russ Housley
     Vigil Security, LLC
     Email: housley@vigilsec.com


     Brendan Moran
     Arm Limited
     Email: Brendan.Moran@arm.com





  Tschofenig, et al.        Expires 11 June 2026                 [Page 54]


  Internet-Draft    Encrypted Payloads in SUIT Manifests     December 2025


     David Brown
     Linaro
     Email: david.brown@linaro.org


     Ken Takayama
     SECOM CO., LTD.
     Email: ken.takayama.ietf@gmail.com











































  Tschofenig, et al.        Expires 11 June 2026                 [Page 55]


name: draft-ietf-tls-deprecate-obsolete-kex
rev: 08
title: Deprecating Obsolete Key Exchange Methods in (D)TLS 1.2
time: 2026-01-23T18:29:16Z
group_uri: /api/v1/group/group/1326/
expires: 2026-07-16T17:28:09Z
ad: /api/v1/person/person/112723/
shepherd: /api/v1/person/email/joe@salowey.net/
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.895960+00:00
source: ietf
abstract:
  For (D)TLS 1.2, this document deprecates the use of two key
     exchanges, namely Diffie-Hellman over a finite field and RSA, and it
     discourages the use of static elliptic curve Diffie-Hellman cipher
     suites.

     These prescriptions apply only to (D)TLS 1.2 since (D)TLS 1.0 and TLS
     1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the
     affected algorithms or does not share the relevant configuration
     options.  (There is no DTLS version 1.1.)

     This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288,
     6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905, to
     deprecate or discourage - i.e., change to MUST NOT or SHOULD NOT, as
     listed in Section 5.3, Section 5.2, Section 5.3, Section 5.4, and
     Section 5.5 - the use of cipher suites using the above key exchange
     methods in (D)TLS 1.2 connections.

states:
  ["/api/v1/doc/state/1/", "/api/v1/doc/state/108/", "/api/v1/doc/state/115/", "/api/v1/doc/state/17/", "/api/v1/doc/state/117/", "/api/v1/doc/state/44/"]

full_text:
  TLS Working Group                                              N. Aviram
  Internet-Draft                                           12 January 2026
  Updates: 9325, 4346, 5246, 4162, 6347, 5932,                            
           5288, 6209, 6367, 8422, 5289, 5469,                            
           4785, 4279, 5487, 6655, 7905 (if                               
           approved)                                                      
  Intended status: Standards Track                                        
  Expires: 16 July 2026


          Deprecating Obsolete Key Exchange Methods in (D)TLS 1.2
                  draft-ietf-tls-deprecate-obsolete-kex-08

  Abstract

     For (D)TLS 1.2, this document deprecates the use of two key
     exchanges, namely Diffie-Hellman over a finite field and RSA, and it
     discourages the use of static elliptic curve Diffie-Hellman cipher
     suites.

     These prescriptions apply only to (D)TLS 1.2 since (D)TLS 1.0 and TLS
     1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the
     affected algorithms or does not share the relevant configuration
     options.  (There is no DTLS version 1.1.)

     This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288,
     6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905, to
     deprecate or discourage - i.e., change to MUST NOT or SHOULD NOT, as
     listed in Section 5.3, Section 5.2, Section 5.3, Section 5.4, and
     Section 5.5 - the use of cipher suites using the above key exchange
     methods in (D)TLS 1.2 connections.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 16 July 2026.



  Aviram                    Expires 16 July 2026                  [Page 1]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


  Copyright Notice

     Copyright (c) 2026 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, as 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 are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Non-Ephemeral Diffie-Hellman  . . . . . . . . . . . . . . . .   5
     3.  Ephemeral Finite Field Diffie-Hellman . . . . . . . . . . . .   5
     4.  RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.  Updates to Cipher Suites and TLS ClientCertificateType
             Identifiers . . . . . . . . . . . . . . . . . . . . . . .   5
       5.1.  DH Cipher Suites Deprecated by This Document  . . . . . .   5
       5.2.  ECDH Cipher Suites Whose Use Is Discouraged by This
             Document  . . . . . . . . . . . . . . . . . . . . . . . .   8
       5.3.  DHE Cipher Suites deprecated by This Document . . . . . .  10
       5.4.  RSA Cipher Suites Deprecated by This Document . . . . . .  13
       5.5.  TLS ClientCertificateType Identifiers Deprecated by This
             Document  . . . . . . . . . . . . . . . . . . . . . . . .  16
     6.  Updating RFC 9325 . . . . . . . . . . . . . . . . . . . . . .  16
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
     9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  19
       10.2.  Informative References . . . . . . . . . . . . . . . . .  21
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

  1.  Introduction

     (D)TLS 1.2 supports a variety of key exchange algorithms, including
     RSA, Diffie-Hellman over a finite field, and elliptic curve Diffie-
     Hellman (ECDH).

     Diffie-Hellman key exchange, over any group, comes in ephemeral and
     non-ephemeral varieties.  Non-ephemeral DH algorithms use static DH
     public keys included in the authenticating peer's certificate; see



  Aviram                    Expires 16 July 2026                  [Page 2]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


     [RFC4492] for discussion.  In contrast, ephemeral DH algorithms use
     ephemeral DH public keys sent in the handshake and authenticated by
     the peer's certificate.  Ephemeral and non-ephemeral finite field DH
     algorithms are called DHE and DH (or FFDHE and FFDH), respectively,
     and ephemeral and non-ephemeral elliptic curve DH algorithms are
     called ECDHE and ECDH, respectively [RFC4492].

     In general, non-ephemeral cipher suites are not recommended due to
     their lack of forward secrecy.  Moreover, as demonstrated by the
     [Raccoon] attack on finite-field DH, public key reuse, either via
     non-ephemeral cipher suites or reused keys with ephemeral cipher
     suites, can lead to timing side channels that may leak connection
     secrets.  For elliptic curve DH, invalid curve attacks similarly
     exploit secret reuse in order to break security [ICA], further
     demonstrating the risk of reusing public keys.  While both side
     channels can be avoided in implementations, experience shows that in
     practice, implementations may fail to thwart such attacks due to the
     complexity and number of the required mitigations.

     Additionally, RSA key exchange suffers from security problems that
     are independent of implementation choices as well as problems that
     stem purely from the difficulty of implementing security
     countermeasures correctly.

     At a rough glance, the problems affecting FFDHE in (D)TLS 1.2 are as
     follows:

     1.  FFDHE suffers from interoperability problems because there is no
         mechanism for negotiating the group, and some implementations
         only support small group sizes (see [RFC7919], Section 1).

     2.  FFDHE groups may have small subgroups, which enables several
         attacks [subgroups].  When presented with a custom, non-
         standardized FFDHE group, a handshaking client cannot practically
         verify that the group chosen by the server does not suffer from
         this problem.  There is also no mechanism for such handshakes to
         fall back to other key exchange parameters that are acceptable to
         the client.  Custom FFDHE groups are widespread (as a result of
         advice based on [weak-dh]).  Therefore, clients cannot simply
         reject handshakes that present custom, and thus potentially
         dangerous, groups.

     3.  In practice, some operators use 1024-bit FFDHE groups since this
         is the maximum size that ensures wide support (see [RFC7919],
         Section 1).  This size leaves only a small security margin vs.
         the current discrete log record, which stands at 795 bits
         [DLOG795].




  Aviram                    Expires 16 July 2026                  [Page 3]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


     4.  Expanding on the previous point, just a handful of very large
         computations allow an attacker to cheaply decrypt a relatively
         large fraction of FFDHE traffic (namely, traffic encrypted using
         particular standardized groups) [weak-dh].

     5.  When secrets are not fully ephemeral, FFDHE suffers from the
         [Raccoon] side channel attack.  (Note that FFDH is inherently
         vulnerable to the Raccoon attack unless constant-time mitigations
         are employed.)

     The problems affecting RSA key exchange in (D)TLS 1.2 are as follows:

     1.  RSA key exchange offers no forward secrecy, by construction.

     2.  RSA key exchange may be vulnerable to Bleichenbacher's attack
         [BLEI].  Experience shows that variants of this attack arise
         every few years because implementing the relevant countermeasure
         correctly is difficult (see [ROBOT], [NEW-BLEI], [DROWN]).

     3.  In addition to the above point, there is no convenient mechanism
         in (D)TLS 1.2 for the domain separation of keys.  Therefore, a
         single endpoint that is vulnerable to Bleichenbacher's attack
         would affect all endpoints sharing the same RSA key (see [XPROT],
         [DROWN]).

     This document updates [RFC9325], [RFC4346], [RFC5246], [RFC4162],
     [RFC6347], [RFC5932], [RFC5288], [RFC6209], [RFC6367], [RFC8422],
     [RFC5289], [RFC4785], [RFC4279], [RFC5487], [RFC6655], [RFC7905] and
     [RFC5469] to remediate the above problems, by deprecating and
     discouraging the use of affected cipher suites, as listed in
     Section 5.3 Section 5.2 Section 5.3 Section 5.4 Section 5.5.

     BCP 195 [RFC8996][RFC9325] contains the latest IETF recommendations
     for users of the (D)TLS protocol (and specifically, (D)TLS 1.2) and
     this document supersedes it in several points.  Section 6 details the
     exact differences.  All other recommendations of the BCP document
     remain valid.

  1.1.  Requirements

     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.






  Aviram                    Expires 16 July 2026                  [Page 4]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


  2.  Non-Ephemeral Diffie-Hellman

     Clients MUST NOT offer and servers MUST NOT select non-ephemeral FFDH
     cipher suites in (D)TLS 1.2 connections.  (Note that (D)TLS 1.0 and
     TLS 1.1 are deprecated by [RFC8996] and (D)TLS 1.3 does not support
     FFDH [I-D.ietf-tls-rfc8446bis][RFC9147].)  This includes all cipher
     suites listed in the table in Section 5.1.

     Clients SHOULD NOT offer and servers SHOULD NOT select non-ephemeral
     ECDH cipher suites in (D)TLS 1.2 connections.  (This requirement is
     already present in [RFC9325].  Note that (D)TLS 1.0 and TLS 1.1 are
     deprecated by [RFC8996] and (D)TLS 1.3 does not support ECDH
     [I-D.ietf-tls-rfc8446bis][RFC9147].)  This includes all cipher suites
     listed in the table in Section 5.2.

     In addition, to avoid the use of non-ephemeral Diffie-Hellman,
     clients SHOULD NOT use and servers SHOULD NOT accept certificates
     with fixed DH parameters.  These certificate types are rsa_fixed_dh,
     dss_fixed_dh, rsa_fixed_ecdh and ecdsa_fixed_ecdh as listed in
     Section 5.5.  These values only apply to (D)TLS versions of 1.2 and
     below.

  3.  Ephemeral Finite Field Diffie-Hellman

     Clients MUST NOT offer and servers MUST NOT select FFDHE cipher
     suites in (D)TLS 1.2 connections.  This includes all cipher suites
     listed in the table in Section 5.3.  (Note that (D)TLS 1.0 and TLS
     1.1 are deprecated by [RFC8996].)  FFDHE cipher suites in (D)TLS 1.3
     do not suffer from the problems presented in Section 1; see
     [I-D.ietf-tls-rfc8446bis] and [RFC9147].  Therefore, clients and
     servers MAY offer FFDHE cipher suites in (D)TLS 1.3 connections.

  4.  RSA

     Clients MUST NOT offer and servers MUST NOT select RSA cipher suites
     in (D)TLS 1.2 connections.  (Note that (D)TLS 1.0 and TLS 1.1 are
     deprecated by [RFC8996], and (D)TLS 1.3 does not support static RSA
     [I-D.ietf-tls-rfc8446bis][RFC9147].)  This includes all cipher suites
     listed in the table in Section 5.4.  Note that these cipher suites
     are already marked as not recommended in the "TLS Cipher Suites"
     registry [tls-registry].

  5.  Updates to Cipher Suites and TLS ClientCertificateType Identifiers

  5.1.  DH Cipher Suites Deprecated by This Document

     This document requests IANA to set the “recommended” column to “D”
     for the following entries:



  Aviram                    Expires 16 July 2026                  [Page 5]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


       +==========================================+====================+
       | Ciphersuite                              | Reference          |
       +==========================================+====================+
       | TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA     | [RFC4346]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_DES_CBC_SHA              | [RFC5469]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA         | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA     | [RFC4346]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_DES_CBC_SHA              | [RFC5469]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA         | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_EXPORT_WITH_RC4_40_MD5       | [RFC4346][RFC6347] |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_RC4_128_MD5             | [RFC5246][RFC6347] |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA    | [RFC4346]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_DES_CBC_SHA             | [RFC5469]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA        | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_AES_128_CBC_SHA          | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_AES_128_CBC_SHA          | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_AES_128_CBC_SHA         | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_AES_256_CBC_SHA          | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_AES_256_CBC_SHA          | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_AES_256_CBC_SHA         | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_AES_128_CBC_SHA256       | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_AES_128_CBC_SHA256       | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA     | [RFC5932]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA     | [RFC5932]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA    | [RFC5932]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_AES_256_CBC_SHA256       | [RFC5246]          |



  Aviram                    Expires 16 July 2026                  [Page 6]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_AES_256_CBC_SHA256       | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_AES_128_CBC_SHA256      | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_AES_256_CBC_SHA256      | [RFC5246]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA     | [RFC5932]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA     | [RFC5932]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA    | [RFC5932]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_SEED_CBC_SHA             | [RFC4162]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_SEED_CBC_SHA             | [RFC4162]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_SEED_CBC_SHA            | [RFC4162]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_AES_128_GCM_SHA256       | [RFC5288]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_AES_256_GCM_SHA384       | [RFC5288]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_AES_128_GCM_SHA256       | [RFC5288]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_AES_256_GCM_SHA384       | [RFC5288]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_AES_128_GCM_SHA256      | [RFC5288]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_AES_256_GCM_SHA384      | [RFC5288]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256  | [RFC5932]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256  | [RFC5932]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256 | [RFC5932]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256  | [RFC5932]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256  | [RFC5932]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256 | [RFC5932]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256      | [RFC6209]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384      | [RFC6209]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256      | [RFC6209]          |



  Aviram                    Expires 16 July 2026                  [Page 7]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384      | [RFC6209]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_ARIA_128_CBC_SHA256     | [RFC6209]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_ARIA_256_CBC_SHA384     | [RFC6209]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256      | [RFC6209]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384      | [RFC6209]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256      | [RFC6209]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384      | [RFC6209]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_ARIA_128_GCM_SHA256     | [RFC6209]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_ARIA_256_GCM_SHA384     | [RFC6209]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256  | [RFC6367]          |
       +------------------------------------------+--------------------+
       | TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384  | [RFC6367]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256  | [RFC6367]          |
       +------------------------------------------+--------------------+
       | TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384  | [RFC6367]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256 | [RFC6367]          |
       +------------------------------------------+--------------------+
       | TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384 | [RFC6367]          |
       +------------------------------------------+--------------------+

                                    Table 1

  5.2.  ECDH Cipher Suites Whose Use Is Discouraged by This Document

     [RFC9325] already specifies that implementations SHOULD NOT negotiate
     the following cipher suites; accordingly, they appear with
     "Recommended: N" in the IANA TLS Cipher Suites registry
     [tls-registry].  This document updates them to "Recommended: D" to
     align with [I-D.ietf-tls-rfc8447bis].  It also records the rationale
     for discouraging use of these cipher suites, and cites prior analyses
     and attacks that demonstrate the associated risks.








  Aviram                    Expires 16 July 2026                  [Page 8]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


     +=============================================+====================+
     | Ciphersuite                                 | Reference          |
     +=============================================+====================+
     | TLS_ECDH_ECDSA_WITH_NULL_SHA                | [RFC8422]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_RC4_128_SHA             | [RFC8422][RFC6347] |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA        | [RFC8422]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA         | [RFC8422]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA         | [RFC8422]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_NULL_SHA                  | [RFC8422]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_RC4_128_SHA               | [RFC8422][RFC6347] |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA          | [RFC8422]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_AES_128_CBC_SHA           | [RFC8422]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_AES_256_CBC_SHA           | [RFC8422]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_anon_WITH_NULL_SHA                 | [RFC8422]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_anon_WITH_RC4_128_SHA              | [RFC8422][RFC6347] |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA         | [RFC8422]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_anon_WITH_AES_128_CBC_SHA          | [RFC8422]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_anon_WITH_AES_256_CBC_SHA          | [RFC8422]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256      | [RFC5289]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384      | [RFC5289]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256        | [RFC5289]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384        | [RFC5289]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256      | [RFC5289]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384      | [RFC5289]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256        | [RFC5289]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384        | [RFC5289]          |



  Aviram                    Expires 16 July 2026                  [Page 9]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256     | [RFC6209]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384     | [RFC6209]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256       | [RFC6209]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384       | [RFC6209]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256     | [RFC6209]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384     | [RFC6209]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256       | [RFC6209]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384       | [RFC6209]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 | [RFC6367]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 | [RFC6367]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256   | [RFC6367]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384   | [RFC6367]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 | [RFC6367]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 | [RFC6367]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256   | [RFC6367]          |
     +---------------------------------------------+--------------------+
     | TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384   | [RFC6367]          |
     +---------------------------------------------+--------------------+

                                   Table 2

  5.3.  DHE Cipher Suites deprecated by This Document

     This document requests IANA to set the “recommended” column to “D”
     for the following entries:

      +===========================================+=====================+
      | Ciphersuite                               | Reference           |
      +===========================================+=====================+
      | TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA     | [RFC4346]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_DES_CBC_SHA              | [RFC5469] [RFC8996] |
      +-------------------------------------------+---------------------+



  Aviram                    Expires 16 July 2026                 [Page 10]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


      | TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA         | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA     | [RFC4346]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_DES_CBC_SHA              | [RFC5469] [RFC8996] |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA         | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_NULL_SHA                 | [RFC4785]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_AES_128_CBC_SHA          | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_AES_128_CBC_SHA          | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_AES_256_CBC_SHA          | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_AES_256_CBC_SHA          | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_AES_128_CBC_SHA256       | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA     | [RFC5932]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA     | [RFC5932]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256       | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_AES_256_CBC_SHA256       | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256       | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA     | [RFC5932]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA     | [RFC5932]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_RC4_128_SHA              | [RFC4279][RFC6347]  |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA         | [RFC4279]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_AES_128_CBC_SHA          | [RFC4279]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_AES_256_CBC_SHA          | [RFC4279]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_SEED_CBC_SHA             | [RFC4162]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_SEED_CBC_SHA             | [RFC4162]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256       | [RFC5288]           |
      +-------------------------------------------+---------------------+



  Aviram                    Expires 16 July 2026                 [Page 11]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


      | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384       | [RFC5288]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_AES_128_GCM_SHA256       | [RFC5288]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_AES_256_GCM_SHA384       | [RFC5288]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256       | [RFC5487]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384       | [RFC5487]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_AES_128_CBC_SHA256       | [RFC5487]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_AES_256_CBC_SHA384       | [RFC5487]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_NULL_SHA256              | [RFC5487]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_NULL_SHA384              | [RFC5487]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256  | [RFC5932]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256  | [RFC5932]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256  | [RFC5932]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256  | [RFC5932]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_ARIA_128_GCM_SHA256      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_ARIA_256_GCM_SHA384      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_ARIA_128_GCM_SHA256      | [RFC6209]           |
      +-------------------------------------------+---------------------+



  Aviram                    Expires 16 July 2026                 [Page 12]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


      | TLS_DHE_PSK_WITH_ARIA_256_GCM_SHA384      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256  | [RFC6367]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384  | [RFC6367]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_CAMELLIA_128_GCM_SHA256  | [RFC6367]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_DSS_WITH_CAMELLIA_256_GCM_SHA384  | [RFC6367]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_CAMELLIA_128_GCM_SHA256  | [RFC6367]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_CAMELLIA_256_GCM_SHA384  | [RFC6367]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256  | [RFC6367]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384  | [RFC6367]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_AES_128_CCM              | [RFC6655]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_AES_256_CCM              | [RFC6655]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_AES_128_CCM_8            | [RFC6655]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_AES_256_CCM_8            | [RFC6655]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_AES_128_CCM              | [RFC6655]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_AES_256_CCM              | [RFC6655]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | [RFC7905]           |
      +-------------------------------------------+---------------------+
      | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | [RFC7905]           |
      +-------------------------------------------+---------------------+
      | TLS_PSK_DHE_WITH_AES_128_CCM_8            | [RFC6655]           |
      +-------------------------------------------+---------------------+
      | TLS_PSK_DHE_WITH_AES_256_CCM_8            | [RFC6655]           |
      +-------------------------------------------+---------------------+

                                    Table 3

  5.4.  RSA Cipher Suites Deprecated by This Document

     This document requests IANA to set the “recommended” column to “D”
     for the following entries:






  Aviram                    Expires 16 July 2026                 [Page 13]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


      +===========================================+=====================+
      | Ciphersuite                               | Reference           |
      +===========================================+=====================+
      | TLS_RSA_WITH_NULL_MD5                     | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_NULL_SHA                     | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_EXPORT_WITH_RC4_40_MD5            | [RFC4346][RFC6347]  |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_RC4_128_MD5                  | [RFC5246][RFC6347]  |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_RC4_128_SHA                  | [RFC5246][RFC6347]  |
      +-------------------------------------------+---------------------+
      | TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5        | [RFC4346]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_IDEA_CBC_SHA                 | [RFC5469] [RFC8996] |
      +-------------------------------------------+---------------------+
      | TLS_RSA_EXPORT_WITH_DES40_CBC_SHA         | [RFC4346]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_DES_CBC_SHA                  | [RFC5469] [RFC8996] |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_3DES_EDE_CBC_SHA             | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_NULL_SHA                 | [RFC4785]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_AES_128_CBC_SHA              | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_AES_256_CBC_SHA              | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_NULL_SHA256                  | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_AES_128_CBC_SHA256           | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_AES_256_CBC_SHA256           | [RFC5246]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA         | [RFC5932]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA         | [RFC5932]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_RC4_128_SHA              | [RFC4279][RFC6347]  |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA         | [RFC4279]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_AES_128_CBC_SHA          | [RFC4279]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_AES_256_CBC_SHA          | [RFC4279]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_SEED_CBC_SHA                 | [RFC4162]           |



  Aviram                    Expires 16 July 2026                 [Page 14]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_AES_128_GCM_SHA256           | [RFC5288]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_AES_256_GCM_SHA384           | [RFC5288]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_AES_128_GCM_SHA256       | [RFC5487]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_AES_256_GCM_SHA384       | [RFC5487]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_AES_128_CBC_SHA256       | [RFC5487]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_AES_256_CBC_SHA384       | [RFC5487]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_NULL_SHA256              | [RFC5487]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_NULL_SHA384              | [RFC5487]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256      | [RFC5932]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256      | [RFC5932]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_ARIA_128_CBC_SHA256          | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_ARIA_256_CBC_SHA384          | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_ARIA_128_GCM_SHA256          | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_ARIA_256_GCM_SHA384          | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384      | [RFC6209]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256      | [RFC6367]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384      | [RFC6367]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256  | [RFC6367]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384  | [RFC6367]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256  | [RFC6367]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384  | [RFC6367]           |



  Aviram                    Expires 16 July 2026                 [Page 15]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_AES_128_CCM                  | [RFC6655]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_AES_256_CCM                  | [RFC6655]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_AES_128_CCM_8                | [RFC6655]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_WITH_AES_256_CCM_8                | [RFC6655]           |
      +-------------------------------------------+---------------------+
      | TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256 | [RFC7905]           |
      +-------------------------------------------+---------------------+

                                    Table 4

  5.5.  TLS ClientCertificateType Identifiers Deprecated by This Document

     This document requests IANA to set the “recommended” column to “D”
     for the following entries:

                     +=======================+===========+
                     | Certificate Type      | Reference |
                     +=======================+===========+
                     | rsa_fixed_dh (3)      | [RFC5246] |
                     +-----------------------+-----------+
                     | dss_fixed_dh (4)      | [RFC5246] |
                     +-----------------------+-----------+
                     | rsa_fixed_ecdh (65)   | [RFC8422] |
                     +-----------------------+-----------+
                     | ecdsa_fixed_ecdh (66) | [RFC8422] |
                     +-----------------------+-----------+

                                    Table 5

  6.  Updating RFC 9325

     This document updates [RFC9325] with respect to the use of (D)TLS
     1.2, and the table below lists the exact changes.  All changes should
     be made in Section 4.1 of [RFC9325].


     // Note to RFC Editor: please replace XXX below by the current RFC
     // number.









  Aviram                    Expires 16 July 2026                 [Page 16]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


           +============================+=============+============+
           |                            | RFC 9325    |    RFC XXX |
           +============================+=============+============+
           | Non-ephemeral FFDH         | SHOULD NOT  |   MUST NOT |
           +----------------------------+-------------+------------+
           | Non-ephemeral ECDH         | SHOULD NOT  |  No change |
           +----------------------------+-------------+------------+
           | Fixed DH certificate types | Unspecified | SHOULD NOT |
           +----------------------------+-------------+------------+
           | Ephemeral FFDH             | SHOULD NOT  |   MUST NOT |
           +----------------------------+-------------+------------+
           | Static RSA                 | SHOULD NOT  |   MUST NOT |
           +----------------------------+-------------+------------+

                                    Table 6

  7.  IANA Considerations

     This document requests IANA to mark the cipher suites from the "TLS
     Cipher Suites" registry [tls-registry], under “Transport Layer
     Security (TLS) Parameters” registry group, listed in Section 5.1,
     Section 5.2, Section 5.3, Section 5.4, and the certificate types from
     the "TLS ClientCertificateType Identifiers" registry listed in
     Section 5.5 as "D" in the "Recommended" column, see
     [I-D.ietf-tls-rfc8447bis].

     For each registry entry in Section 5.1, Section 5.2, Section 5.3,
     Section 5.4, and Section 5.5, IANA is also requested to update the
     registry entry's Reference column to refer to this document.

  8.  Security Considerations

     Non-ephemeral finite field DH cipher suites (TLS_DH_*), as well as
     ephemeral key reuse for finite field DH cipher suites, are prohibited
     due to the [Raccoon] attack.  Both are already considered bad
     practice since they do not provide forward secrecy.  However, Raccoon
     revealed that timing side channels in processing TLS premaster
     secrets may be exploited to reveal the encrypted premaster secret.

     As for non-ephemeral elliptic curve DH cipher suites (TLS_ECDH_*),
     forgoing forward secrecy not only allows retroactive decryption in
     the event of key compromise but may also enable a broad category of
     attacks where the attacker exploits key reuse to repeatedly query a
     cryptographic secret.

     This category includes, but is not necessarily limited to, the
     following examples:




  Aviram                    Expires 16 July 2026                 [Page 17]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


     1.  Invalid curve attacks, where the attacker exploits key reuse to
         repeatedly query and eventually learn the key itself.  These
         attacks have been shown to be practical against real-world TLS
         implementations [ICA].

     2.  Side channel attacks, where the attacker exploits key reuse and
         an additional side channel to learn a cryptographic secret.  As
         one example of such attacks, refer to [MAY4].

     3.  Fault attacks, where the attacker exploits key reuse and
         incorrect calculations to learn a cryptographic secret.  As one
         example of such attacks, see [PARIS256].

     Such attacks are often implementation-dependent, including the above
     examples.  However, these examples demonstrate that building a system
     that reuses keys and avoids this category of attacks is difficult in
     practice.  In contrast, avoiding key reuse not only prevents
     decryption in the event of key compromise, but also precludes this
     category of attacks altogether.  Therefore, this document discourages
     the reuse of elliptic curve DH public keys.

     As for ephemeral finite field Diffie-Hellman in (D)TLS 1.2 (TLS_DHE_*
     and TLS_PSK_DHE_*), as explained above, clients have no practical way
     to support these cipher suites while ensuring they only negotiate
     security parameters that are acceptable to them.  In (D)TLS 1.2, the
     server chooses the Diffie-Hellman group, and custom groups are
     prevalent.  Therefore, once the client includes these cipher suites
     in its handshake and the server presents a custom group, the client
     cannot complete the handshake while ensuring security.  Verifying the
     group structure is prohibitively expensive for the client.  Using a
     safelist of known-good groups is also impractical, since server
     operators were encouraged to generate their own custom group.
     Further, there is no mechanism for the handshake to fall back to
     other parameters, that are acceptable to both the client and server.

  9.  Acknowledgments

     This document includes many important contributions from Carrie
     Bartle, who wrote much of the prose, and presented it several times
     at the IETF TLS WG.

     The document was inspired by discussions on the TLS WG mailing list
     and a suggestion by Filippo Valsorda following the release of the
     [Raccoon] attack.  Thanks to Christopher A.  Wood for writing up the
     initial draft of this document.  Thanks also to Thomas Fossati, Sean
     Turner, Joe Salowey, Yaron Sheffer, Christian Buchgraber, John Preuß
     Mattsson and Manuel Pégourié-Gonnard for comments and suggestions.




  Aviram                    Expires 16 July 2026                 [Page 18]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


  10.  References

  10.1.  Normative References

     [I-D.ietf-tls-rfc8446bis]
                Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", Work in Progress, Internet-Draft, draft-
                ietf-tls-rfc8446bis-14, 13 September 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
                rfc8446bis-14>.

     [I-D.ietf-tls-rfc8447bis]
                Salowey, J. A. and S. Turner, "IANA Registry Updates for
                TLS and DTLS", Work in Progress, Internet-Draft, draft-
                ietf-tls-rfc8447bis-15, 21 July 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
                rfc8447bis-15>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC4162]  Lee, H.J., Yoon, J.H., and J.I. Lee, "Addition of SEED
                Cipher Suites to Transport Layer Security (TLS)",
                RFC 4162, DOI 10.17487/RFC4162, August 2005,
                <https://www.rfc-editor.org/rfc/rfc4162>.

     [RFC4279]  Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
                Ciphersuites for Transport Layer Security (TLS)",
                RFC 4279, DOI 10.17487/RFC4279, December 2005,
                <https://www.rfc-editor.org/rfc/rfc4279>.

     [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
                (TLS) Protocol Version 1.1", RFC 4346,
                DOI 10.17487/RFC4346, April 2006,
                <https://www.rfc-editor.org/rfc/rfc4346>.

     [RFC4785]  Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK)
                Ciphersuites with NULL Encryption for Transport Layer
                Security (TLS)", RFC 4785, DOI 10.17487/RFC4785, January
                2007, <https://www.rfc-editor.org/rfc/rfc4785>.

     [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
                (TLS) Protocol Version 1.2", RFC 5246,
                DOI 10.17487/RFC5246, August 2008,
                <https://www.rfc-editor.org/rfc/rfc5246>.




  Aviram                    Expires 16 July 2026                 [Page 19]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


     [RFC5288]  Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
                Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
                DOI 10.17487/RFC5288, August 2008,
                <https://www.rfc-editor.org/rfc/rfc5288>.

     [RFC5289]  Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
                256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
                DOI 10.17487/RFC5289, August 2008,
                <https://www.rfc-editor.org/rfc/rfc5289>.

     [RFC5469]  Eronen, P., Ed., "DES and IDEA Cipher Suites for Transport
                Layer Security (TLS)", RFC 5469, DOI 10.17487/RFC5469,
                February 2009, <https://www.rfc-editor.org/rfc/rfc5469>.

     [RFC5487]  Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA-
                256/384 and AES Galois Counter Mode", RFC 5487,
                DOI 10.17487/RFC5487, March 2009,
                <https://www.rfc-editor.org/rfc/rfc5487>.

     [RFC5932]  Kato, A., Kanda, M., and S. Kanno, "Camellia Cipher Suites
                for TLS", RFC 5932, DOI 10.17487/RFC5932, June 2010,
                <https://www.rfc-editor.org/rfc/rfc5932>.

     [RFC6209]  Kim, W., Lee, J., Park, J., and D. Kwon, "Addition of the
                ARIA Cipher Suites to Transport Layer Security (TLS)",
                RFC 6209, DOI 10.17487/RFC6209, April 2011,
                <https://www.rfc-editor.org/rfc/rfc6209>.

     [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
                Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
                January 2012, <https://www.rfc-editor.org/rfc/rfc6347>.

     [RFC6367]  Kanno, S. and M. Kanda, "Addition of the Camellia Cipher
                Suites to Transport Layer Security (TLS)", RFC 6367,
                DOI 10.17487/RFC6367, September 2011,
                <https://www.rfc-editor.org/rfc/rfc6367>.

     [RFC6655]  McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
                Transport Layer Security (TLS)", RFC 6655,
                DOI 10.17487/RFC6655, July 2012,
                <https://www.rfc-editor.org/rfc/rfc6655>.

     [RFC7905]  Langley, A., Chang, W., Mavrogiannopoulos, N.,
                Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305
                Cipher Suites for Transport Layer Security (TLS)",
                RFC 7905, DOI 10.17487/RFC7905, June 2016,
                <https://www.rfc-editor.org/rfc/rfc7905>.




  Aviram                    Expires 16 July 2026                 [Page 20]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


     [RFC7919]  Gillmor, D., "Negotiated Finite Field Diffie-Hellman
                Ephemeral Parameters for Transport Layer Security (TLS)",
                RFC 7919, DOI 10.17487/RFC7919, August 2016,
                <https://www.rfc-editor.org/rfc/rfc7919>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC8422]  Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
                Curve Cryptography (ECC) Cipher Suites for Transport Layer
                Security (TLS) Versions 1.2 and Earlier", RFC 8422,
                DOI 10.17487/RFC8422, August 2018,
                <https://www.rfc-editor.org/rfc/rfc8422>.

     [RFC8996]  Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
                1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
                <https://www.rfc-editor.org/rfc/rfc8996>.

     [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
                Datagram Transport Layer Security (DTLS) Protocol Version
                1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
                <https://www.rfc-editor.org/rfc/rfc9147>.

     [RFC9325]  Sheffer, Y., Saint-Andre, P., and T. Fossati,
                "Recommendations for Secure Use of Transport Layer
                Security (TLS) and Datagram Transport Layer Security
                (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
                2022, <https://www.rfc-editor.org/rfc/rfc9325>.

  10.2.  Informative References

     [BLEI]     Bleichenbacher, D., "Chosen Ciphertext Attacks against
                Protocols Based on RSA Encryption Standard PKCS #1",
                Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462,
                pages: 1-12 , 1998.

     [DLOG795]  Boudot, F., Gaudry, P., Guillevic, A., Heninger, N.,
                Thomé, E., and P. Zimmermann, "Comparing the difficulty of
                factorization and discrete logarithm: a 240-digit
                experiment", 17 August 2020,
                <https://eprint.iacr.org/2020/697>.









  Aviram                    Expires 16 July 2026                 [Page 21]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


     [DROWN]    Aviram, N., Schinzel, S., Somorovsky, J., Heninger, N.,
                Dankel, M., Steube, J., Valenta, L., Adrian, D.,
                Halderman, J. A., Dukhovni, V., Käsper, E., Cohney, S.,
                Engels, S., Paar, C., and Y. Shavitt, "DROWN: Breaking TLS
                using SSLv2", August 2016,
                <https://drownattack.com/drown-attack-paper.pdf>.

     [ICA]      Jager, T., Schwenk, J., and J. Somorovsky, "Practical
                invalid curve attacks on TLS-ECDH", 21 September 2015,
                <https://citeseerx.ist.psu.edu/viewdoc/
                download?doi=10.1.1.704.7932&rep=rep1&type=pdf>.

     [MAY4]     Genkin, D., Valenta, L., and Y. Yarom, "May the fourth be
                with you: A microarchitectural side channel attack on
                several real-world applications of curve25519", n.d.,
                <https://dl.acm.org/doi/pdf/10.1145/3133956.3134029>.

     [NEW-BLEI] Meyer, C., Somorovsky, J., Weiss, E., Schwenk, J.,
                Schinzel, S., and E. Tews, "Revisiting SSL/TLS
                Implementations: New Bleichenbacher Side Channels and
                Attacks", August 2014,
                <https://www.usenix.org/system/files/conference/
                usenixsecurity14/sec14-paper-meyer.pdf>.

     [PARIS256] Devlin, S. and F. Valsorda, "The PARIS256 Attack", n.d.,
                <https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-
                Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf>.

     [Raccoon]  Merget, R., Brinkmann, M., Aviram, N., Somorovsky, J.,
                Mittmann, J., and J. Schwenk, "Raccoon Attack: Finding and
                Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)", 9
                September 2020,
                <https://raccoon-attack.com/RacoonAttack.pdf>.

     [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
                Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
                for Transport Layer Security (TLS)", RFC 4492,
                DOI 10.17487/RFC4492, May 2006,
                <https://www.rfc-editor.org/rfc/rfc4492>.

     [ROBOT]    Boeck, H., Somorovsky, J., and C. Young, "Return Of
                Bleichenbacher's Oracle Threat (ROBOT)", 27th USENIX
                Security Symposium , 2018.








  Aviram                    Expires 16 July 2026                 [Page 22]


  Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


     [subgroups]
                Valenta, L., Adrian, D., Sanso, A., Cohney, S., Fried, J.,
                Hastings, M., Halderman, J. A., and N. Heninger,
                "Measuring small subgroup attacks against Diffie-Hellman",
                15 October 2016,
                <https://eprint.iacr.org/2016/995/20161017:193515>.

     [tls-registry]
                "Transport Layer Security (TLS) Parameters", n.d.,
                <https://www.iana.org/assignments/tls-parameters/tls-
                parameters.xhtml>.

     [weak-dh]  Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,
                Green, M., Halderman, J. A., Heninger, N., Springall, D.,
                Thomé, E., Valenta, L., VanderSloot, B., Wustrow, E.,
                Zanella-Béguelin, S., and P. Zimmermann, "Weak Diffie-
                Hellman and the Logjam Attack", October 2015,
                <https://weakdh.org/>.

     [XPROT]    Jager, T., Schwenk, J., and J. Somorovsky, "On the
                Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1
                v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC
                Conference on Computer and Communications Security , 2015.

  Author's Address

     Nimrod Aviram
     Email: nimrod.aviram@gmail.com























  Aviram                    Expires 16 July 2026                 [Page 23]


name: draft-ietf-emu-hybrid-pqc-eapaka
rev: 01
title: Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography
time: 2026-02-26T10:21:30Z
group_uri: /api/v1/group/group/1674/
expires: 2026-08-30T10:21:30Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.900559+00:00
source: ietf
abstract:
  Forward Secrecy for the Extensible Authentication Protocol Method for
     Authentication and Key Agreement (EAP-AKA' FS) is specified in
     [RFC9678], providing updates to [RFC9048] with an optional extension
     that offers ephemeral key exchange using the traditional Ephemeral
     Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for
     achieving perfect forward secrecy (PFS).  However, it is susceptible
     to future threats from Cryptographically Relevant Quantum Computers,
     which could potentially compromise a traditional ephemeral public
     key.  If the adversary has also obtained knowledge of the long-term
     key and ephemeral public key, it could compromise session keys
     generated as part of the authentication run in EAP-AKA'.

     This draft aims to enhance the security of EAP-AKA' FS protocol by
     leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology]
     algorithms to make it quantum-safe.

full_text:
  EMU                                                          A. Banerjee
  Internet-Draft                                                  T. Reddy
  Intended status: Standards Track                                   Nokia
  Expires: 30 August 2026                                 26 February 2026


    Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography
                    draft-ietf-emu-hybrid-pqc-eapaka-01

  Abstract

     Forward Secrecy for the Extensible Authentication Protocol Method for
     Authentication and Key Agreement (EAP-AKA' FS) is specified in
     [RFC9678], providing updates to [RFC9048] with an optional extension
     that offers ephemeral key exchange using the traditional Ephemeral
     Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for
     achieving perfect forward secrecy (PFS).  However, it is susceptible
     to future threats from Cryptographically Relevant Quantum Computers,
     which could potentially compromise a traditional ephemeral public
     key.  If the adversary has also obtained knowledge of the long-term
     key and ephemeral public key, it could compromise session keys
     generated as part of the authentication run in EAP-AKA'.

     This draft aims to enhance the security of EAP-AKA' FS protocol by
     leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology]
     algorithms to make it quantum-safe.

  About This Document

     This note is to be removed before publishing as an RFC.

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ietf-emu-hybrid-pqc-eapaka/.

     Discussion of this document takes place on the emu Working Group
     mailing list (mailto:emu@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/emu/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/emu/.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.



  Banerjee & Reddy         Expires 30 August 2026                 [Page 1]


  Internet-Draft         PQC Hybrid in EAP-AKA prime         February 2026


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 30 August 2026.

  Copyright Notice

     Copyright (c) 2026 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, as 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 are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Background on EAP-AKA' with perfect forward secrecy . . . . .   4
     5.  Hybrid Enhancements by Design . . . . . . . . . . . . . . . .   5
     6.  Message Fragmentation and Reassembly  . . . . . . . . . . . .   5
     7.  Protocol Construction . . . . . . . . . . . . . . . . . . . .   6
       7.1.  Protocol Call Flow  . . . . . . . . . . . . . . . . . . .   6
       7.2.  Key Steps in protocol construction  . . . . . . . . . . .   8
     8.  Extensions to EAP-AKA' FS . . . . . . . . . . . . . . . . . .   9
       8.1.  AT_PUB_HYBRID . . . . . . . . . . . . . . . . . . . . . .   9
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
       11.2.  Informative References . . . . . . . . . . . . . . . . .  12
     Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  13
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13










  Banerjee & Reddy         Expires 30 August 2026                 [Page 2]


  Internet-Draft         PQC Hybrid in EAP-AKA prime         February 2026


  1.  Introduction

     Forward Secrecy for the Extensible Authentication Protocol Method for
     Authentication and Key Agreement (EAP-AKA' FS) defined in [RFC9678]
     updates the improved Extensible Authentication Protocol Method for
     3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')
     specified in [RFC9048], with an optional extension providing
     ephemeral key exchange.  This prevents an attacker who has gained
     access to the long term key from obtaining session keys established
     in the past, assuming these have been properly deleted.  EAP-AKA' FS
     mitigates passive attacks (e.g., large scale pervasive monitoring)
     against future sessions.

     Nevertheless, EAP-AKA' FS uses traditional algorithms public-key
     algorithms (e.g., ECDH) which will be broken by a Cryptographically
     Relevant Quantum Computer (CRQC) using Shor's algorithm.  The
     presence of a CRQC would render state-of-the-art, traditional public-
     key algorithms deployed today obsolete and insecure, since the
     assumptions about the intractability of the mathematical problems for
     these algorithms that offer confident levels of security today no
     longer apply in the presence of a CRQC.  A CRQC could recover the
     SHARED_SECRET from the ECDHE public keys (Section 6.3 of [RFC9678]).
     If the adversary has also obtained knowledge of the long-term key, it
     could then compute CK', IK', and the SHARED_SECRET, and any derived
     output keys.  This means that the CRQC would disable the forward
     security capability provided by [RFC9678].

     The migration to PQC is unique in the history of modern digital
     cryptography in that neither the traditional algorithms nor the post-
     quantum algorithms are fully trusted to protect data for the required
     data lifetimes.  The post-quantum algorithms face uncertainty about
     the underlying mathematics, compliance issues, unknown
     vulnerabilities, hardware and software implementations that have not
     had sufficient maturing time to rule out classical cryptanalytic
     attacks and implementation bugs.  During the transition from
     traditional to post-quantum algorithms, there is a desire or a
     requirement for protocols that use both algorithm types.

     This specification defines HPKE [I-D.ietf-hpke-pq]
     [I-D.irtf-cfrg-hybrid-kems] for use with EAP-AKA' FS.  HPKE offers a
     variant of public-key encryption of arbitrary-sized plaintexts for a
     recipient public key.  HPKE works for any combination of an
     asymmetric key encapsulation mechanism (KEM), key derivation function
     (KDF), and authenticated encryption with additional data (AEAD)
     function.  HPKE can be extended to support hybrid post-quantum Key
     Encapsulation Mechanisms (KEMs) as defined in [I-D.ietf-hpke-pq].





  Banerjee & Reddy         Expires 30 August 2026                 [Page 3]


  Internet-Draft         PQC Hybrid in EAP-AKA prime         February 2026


  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  3.  Terminology

     This document makes use of the terms defined in
     [I-D.ietf-pquip-pqt-hybrid-terminology].  For the purposes of this
     document, it is helpful to be able to divide cryptographic algorithms
     into two classes:

     "Traditional Algorithm": An asymmetric cryptographic algorithm based
     on integer factorisation, finite field discrete logarithms or
     elliptic curve discrete logarithms.  In the context of JOSE, examples
     of traditional key exchange algorithms include Elliptic Curve Diffie-
     Hellman Ephemeral Static [RFC6090] [RFC8037].  In the context of
     COSE, examples of traditional key exchange algorithms include
     Ephemeral-Static (ES) DH and Static-Static (SS) DH [RFC9052].

     "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that
     is believed to be secure against attacks using quantum computers as
     well as classical computers.  Examples of PQC key exchange algorithms
     include Kyber.

     "Hybrid" key exchange, in this context, means the use of two key
     exchange algorithms based on different cryptographic assumptions,
     e.g., one traditional algorithm and one Post-Quantum algorithm, with
     the purpose of the final shared secret key being secure as long as at
     least one of the component key exchange algorithms remains unbroken.
     It is referred to as PQ/T Hybrid Scheme in
     [I-D.ietf-pquip-pqt-hybrid-terminology].

     PQ/T Hybrid Key Encapsulation Mechanism: A Key Encapsulation
     mechanism (KEM) made up of two or more component KEM algorithms where
     at least one is a post-quantum algorithm and at least one is a
     traditional algorithm.

  4.  Background on EAP-AKA' with perfect forward secrecy

     In EAP-AKA', The authentication vector (AV) contains a random part
     RAND, an authenticator part AUTN used for authenticating the network
     to the USIM, an expected result part XRES, a 128-bit session key for
     integrity check IK, and a 128-bit session key for encryption CK.




  Banerjee & Reddy         Expires 30 August 2026                 [Page 4]


  Internet-Draft         PQC Hybrid in EAP-AKA prime         February 2026


     As described in the draft [RFC9678], the server has the EAP identity
     of the peer.  The server asks the AD to run AKA algorithm to generate
     RAND, AUTN, XRES, CK and IK.  Further it also derives CK’ and IK’
     keys which are tied to a particular network name.  The server now
     generates the ephemeral key pair and sends the public key of that key
     pair and the first EAP method message to the peer.  In this EAP
     message, AT_PUB_ECDHE (carries public key) and the AT_KDF_FS(carries
     other FS related parameters).  Both of these might be ignored of USIM
     doesn’t support the Forward Secrecy extension.  The peer checks if it
     wants to have a Forward extension in EAP AKA'.  If yes, then it will
     eventually respond with AT_PUB_ECDHE and MAC.  If not, it will ignore
     AT_PUB_ECDHE.  If the peer wants to participate in FS extension, it
     will then generate its ECDH key pair, calculate a shared key based on
     its private key and server public key.  The server will receive the
     RES from peer and AT_PUB_ECDHE.  The shared key will be generated
     both in the peer and the server with key pairs exchanged, and later
     master key is also generated.

     MK_ECDHE = PRF'(IK'| CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)

  5.  Hybrid Enhancements by Design

     We suggest the following changes and enhancements:

     *  A new attribute, AT_PUB_HYBRID, is defined to carry the public
        key, which is the concatenation of traditional and PQC KEM public
        keys from the EAP server.  The AT_PUB_HYBRID attribute will carry
        the encapsulated key, which is formed by concatenating the
        encapsulated key (enc) from the traditional KEM algorithm and the
        ciphertext (ct) from the PQC KEM Encapsulation function from the
        EAP peer.

     *  The AT_KDF_FS attribute is updated to indicate the PQ/T Hybrid KEM
        in HPKE and HKDF for generating the Hybrid Master Key MK_HYBRID.

     *  Multiple AT_KDF_FS attributes is included in the EAP-Request to
        handle the EAP peer not supporting PQ/T Hybrid KEM in HPKE.

     *  The Hybrid key derivation function will be included first in the
        EAP-Request to indicate a higher priority than the traditional key
        derivation function.

  6.  Message Fragmentation and Reassembly

     The message fragmentation and reassembly will be similar to as
     outlined in [I-D.ietf-emu-pqc-eapaka].  For brevity, the authors
     would like to defer the reader to [I-D.ietf-emu-pqc-eapaka] for
     details.



  Banerjee & Reddy         Expires 30 August 2026                 [Page 5]


  Internet-Draft         PQC Hybrid in EAP-AKA prime         February 2026


  7.  Protocol Construction

     This section defines the construction for hybrid key exchange in EAP-
     AKA' FS.  Hybrid key exchange refers to using multiple key exchange
     algorithms simultaneously and combining the result with the goal of
     providing security even if all but one of the component algorithms is
     broken.  It is motivated by transition to post-quantum cryptography.

  7.1.  Protocol Call Flow

      USIM           Peer                        Server              AD
       |              |                            |                |
       |              |           EAP-Req/Identity |                |
       |              |<---------------------------+                |
       |              |                            |                |
       |              | EAP-Resp/Identity          |                |
       |              | (Privacy-Friendly)         |                |
       |              +--------------------------->|                |
       |      +-------+----------------------------+----------------+--+
       |      | Server now has an identity for the peer. The server    |
       |      | then asks the help of AD to run AKA algorithms,        |
       |      | generating RAND, AUTN, XRES, CK, IK. Typically, the    |
       |      | AD performs the first part of key derivations so that  |
       |      | the authentication server gets the CK' and IK' keys    |
       |      | already tied to a particular network name.             |
       |      +-------+----------------------------+----------------+--+
       |              |                            |                |
       |              |                            | ID, key deriv. |
       |              |                            | function,      |
       |              |                            | network name   |
       |              |                            +--------------->|
       |              |                            |                |
       |              |                            |    RAND, AUTN, |
       |              |                            | XRES, CK', IK' |
       |              |                            |<---------------+
       |      +-------+----------------------------+----------------+--+
       |      | Server now has the needed authentication vector. It    |
       |      | generates a PQC KEM key pair, an ephemeral ECDHE key   |
       |      | pair, sends the hybrid (PQC + ECDHE) public key of that|
       |      | key pair and the first EAP method message to the peer  |
       |      | In the message the AT_PUB_HYBRID attribute             |
       |      | carries the concatenation of PQC KEM and ECDHE public  |
       |      | keys and the AT_KDF_FS attribute carries other         |
       |      | FS-related parameters. Both of these are               |
       |      | skippable attributes that can be ignored if the peer   |
       |      | does not support this extension.                       |
       |      +-------+----------------------------+----------------+--+
       |              |                            |                |



  Banerjee & Reddy         Expires 30 August 2026                 [Page 6]


  Internet-Draft         PQC Hybrid in EAP-AKA prime         February 2026


       |              | EAP-Req/AKA'-Challenge (1),|                |
       |              |  EAP-Req/AKA'-Challenge (2)|                |
       |              |  AT_RAND, AT_AUTN, AT_KDF, |                |
       |              |   AT_KDF_FS, AT_KDF_INPUT, |                |
       |              |       AT_PUB_HYBRID, AT_MAC|                |
       |              |<---------------------------+                |
     +--+--------------+----------------------------+---------+     |
     | The peer checks if it wants to do the FS extension. If |     |
     | yes, it will eventually respond with AT_PUB_HYBRID and |     |
     | AT_MAC. If not, it will ignore AT_PUB_HYBRID and       |     |
     | AT_KDF_FS and base all calculations on basic EAP-AKA'  |     |
     | attributes, continuing just as in EAP-AKA' per RFC     |     |
     | 9048 rules. In any case, the peer needs to query the   |     |
     | auth parameters from the USIM card.                    |     |
     +--+--------------+----------------------------+---------+     |
       |              |                            |                |
       |   RAND, AUTN |                            |                |
       |<-------------+                            |                |
       |              |                            |                |
       | CK, IK, RES  |                            |                |
       +------------->|                            |                |
     +--+--------------+----------------------------+---------+     |
     | The peer now has everything to respond. If it wants to |     |
     | participate in the FS extension, it will then generate |     |
     | its ECDHE key pair, calculate a hybrid shared secret   |     |
     | key based on the server's PQC KEM public key, its ECDHE|     |
     | key pair and the server's ECDHE public key. Finally,   |     |
     | it proceeds to derive all EAP-AKA' key values and      |     |
     | constructs a full response.                            |     |
     +--+--------------+----------------------------+---------+     |
       |              |                            |                |
       |              | EAP-Resp/AKA'-Challenge    |                |
       |              |  EAP-Req/AKA'-Challenge (2)|                |
       |              | AT_RES, AT_PUB_HYBRID,     |                |
       |              | AT_MAC                     |                |
       |              +--------------------------->|                |
       |      +-------+----------------------------+----------------+--+
       |      | The server now has all the necessary values. It        |
       |      | generates the Hybrid shared secret and checks the RES  |
       |      | and MAC values received in AT_RES and AT_MAC,          |
       |      | respectively. Success requires both to be found        |
       |      | correct. Note that when this document is used,         |
       |      | the keys generated from EAP-AKA' are based on CK, IK,  |
       |      | and the ECDHE and PQC KEM values. Even if there was an |
       |      | attacker who held the long-term key, only an active    |
       |      | attacker could have determined the generated session   |
       |      | keys; additionally an attacker with a cryptographically|
       |      | relevant quantum computer cannot get access to the     |



  Banerjee & Reddy         Expires 30 August 2026                 [Page 7]


  Internet-Draft         PQC Hybrid in EAP-AKA prime         February 2026


       |      | server KEM private key and decrypt the data.           |
       |      +-------+----------------------------+----------------+--+
       |              |                            |                |
       |              |                EAP-Success |                |
       |              |<---------------------------+                |
       |              |                            |                |

  7.2.  Key Steps in protocol construction

     We outline the following key steps in the protocol:

     *  Server generates the PQC KEM Public key(pq_PK), private key
        (pq_SK) pair and the ECDH public key (trad_PK), private key
        (trad_SK) pair.  The server will generate and send the EAP AKA'
        Authentication Vector (AV).

     *  The server will store the expected response XRES, the ECDH private
        key trad_SK and the PQC KEM private key pq_SK.  The server will
        forward the EAP AKA' AV to peer along with pq_PK and trad_PK.

     *  The USIM will validate the AUTH received, also verifies the MAC.
        After the verification is successful and if the peer also supports
        the Forward secrecy, peer will invoke Encapsulate using
        concat(pq_PK, trad_PK) as defined in section 5.4 of
        [I-D.irtf-cfrg-hybrid-kems].

     "ct" is the concatenation of the ciphertext from PQC KEM and
     encapsulated key from ECDH whereas "ss" is hybrid shared secret key.
     Hybrid shared key ss is generated by the peer using the Encapsulate()
     ([I-D.irtf-cfrg-hybrid-kems]).

     *  The peer will send the Authentication response RES and ct to the
        server.

     *  The server will verify the RES with XRES.  The server will use the
        ct, PQC KEM private key pq_SK and ECDH private key trad_SK to
        generate shared secret.

     The generated ss from Decapsulate is the hybrid shared secret key
     derived from PQC KEM and traditional ECDH.  The peer and the server
     first generate the MK_HYBRID and subsequently generate MSK, EMSK as
     shown below:









  Banerjee & Reddy         Expires 30 August 2026                 [Page 8]


  Internet-Draft         PQC Hybrid in EAP-AKA prime         February 2026


     MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
     HYBRID_SHARED_SECRET, ct = Encapsulate(pKR)
     MK_HYBRID = PRF'(IK'|CK'| HYBRID_SHARED_SECRET,"EAP-AKA' FS"| Identity)
     K_encr = MK[0..127]
     K_aut = MK[128..383]
     K_re = MK_HYBRID [0..255]
     MSK = MK_HYBRID [256..767]
     EMSK = MK_HYBRID [768..1279]

     where, pkR is concatenation of PQC KEM and traditional public keys of
     the receiver, ct is concatenation of the ciphertext from the PQC KEM
     and encapsulated key from ECDH; the Encapsulate() function is
     perfomed by the peer only.

  8.  Extensions to EAP-AKA' FS

  8.1.  AT_PUB_HYBRID

     The format of the AT_PUB_HYBRID attribute is shown below.

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | AT_PUB_HYBRID    |   Reserved    |      Length (in bytes)     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         |                       Value (variable)                        |
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     The fields are as follows:

     AT_PUB_HYBID:

     This is set to TBA1 BY IANA.

     Reserved:

     A 1-byte field reserved for future use.  Including this field ensures
     that the fixed header (Type, Reserved, Length) is 4 bytes long,
     maintaining 4-byte alignment for the following Value field.  The
     Reserved field MUST be set to 0 on transmission and ignored on
     receipt.

     Length:






  Banerjee & Reddy         Expires 30 August 2026                 [Page 9]


  Internet-Draft         PQC Hybrid in EAP-AKA prime         February 2026


     A 2-byte unsigned integer indicating the total length of the
     attribute in bytes, including the Type, Reserved, Length, and Value
     fields, as well as any padding.  The length is expressed in multiples
     of 4 bytes.

     This differs from the attribute format used in EAP-AKA [RFC4187],
     where the Length field is 1 byte.  The modification is necessary
     because PQ/T Hybrid KEM public keys, such as X25519 and ML-KEM-768
     (e.g., X-Wing), would exceed the 1024-byte limit imposed by the
     original EAP-AKA format.

     Value:

    *  EAP-Request: It contains the public key, which is the concatenation of
       traditional and PQC KEM public keys from the EAP server.
    *  EAP-Response: It contains the encapsulated key, which is formed by
       concatenating the ciphertext (ct) from the PQC KEM Encapsulation function
       and the encapsulated key (enc) from the traditional KEM algorithm and from the
       EAP peer.

     Because the length of the attribute must be a multiple of 4 bytes,
     the sender pads the Value field with zero bytes when necessary.  To
     retain the security of the keys, the sender SHALL generate a fresh
     value for each run of the protocol.

  9.  Security Considerations

     ML-KEM is IND-CCA2 secure based on multiple analyses.  The ML-KEM
     variant and its underlying components should be selected consistently
     with the desired security level.  For further clarity on the sizes
     and security levels of ML-KEM variants, please refer to the tables in
     Sections 12 and 13 of [I-D.ietf-pquip-pqc-engineers].

     The security of the ML-KEM algorithm depends on a high-quality
     pseudo-random number generator.  For further discussion on random
     number generation, see [RFC4086].

     In general, good cryptographic practice dictates that a given ML-KEM
     key pair should be used in only one EAP session.  This practice
     mitigates the risk that compromising one EAP session will not
     compromise the security of another EAP session and is essential for
     maintaining forward security.

     For security properties of traditional ECDHE for EAP-AKA FS, see
     section 7 of [RFC9678].  The overall Hybrid scheme needs to be IND-
     CCA2 robust; i.e., atleast one of the schemes should be IND-CCA2
     secure.




  Banerjee & Reddy         Expires 30 August 2026                [Page 10]


  Internet-Draft         PQC Hybrid in EAP-AKA prime         February 2026


  10.  IANA Considerations

     Two new values (TBA2) and (TBA3) in the skippable range need to be
     assigned by IANA for AT_PUB_HYBRID (Section 8.1) in the "Attribute
     Types" registry under the "EAP-AKA and EAP-SIM Parameters" group.

     IANA is requested to update the registry "EAP-AKA' AT_KDF_FS Key
     Derivation Function Values" with the Hybrid key derivation function
     entry:

     +=========+========================================================+=====================================+
     | Value   | Description                                                        | Reference               |
     +=========+========================================================+=====================================+
     | TBA2    | QSF-KEM(ML-KEM-768,P-256)-XOF(SHAKE256)-KDF(SHA3-256)              | [TBD BY IANA: THIS RFC] |
     +=========+===============================+========================+=====================================+
     | TBA3    | KitchenSink-KEM(ML-KEM-768,X25519)-XOF(SHAKE256)-KDF(HKDF-SHA-256) | [TBD BY IANA: THIS RFC] |
     +=========+===============================+========================+=====================================+

  11.  References

  11.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC4187]  Arkko, J. and H. Haverinen, "Extensible Authentication
                Protocol Method for 3rd Generation Authentication and Key
                Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,
                January 2006, <https://www.rfc-editor.org/rfc/rfc4187>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC9048]  Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
                "Improved Extensible Authentication Protocol Method for
                3GPP Mobile Network Authentication and Key Agreement (EAP-
                AKA')", RFC 9048, DOI 10.17487/RFC9048, October 2021,
                <https://www.rfc-editor.org/rfc/rfc9048>.

     [RFC9180]  Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
                Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
                February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.






  Banerjee & Reddy         Expires 30 August 2026                [Page 11]


  Internet-Draft         PQC Hybrid in EAP-AKA prime         February 2026


     [RFC9678]  Arkko, J., Norrman, K., and J. Preuß Mattsson, "Forward
                Secrecy Extension to the Improved Extensible
                Authentication Protocol Method for Authentication and Key
                Agreement (EAP-AKA' FS)", RFC 9678, DOI 10.17487/RFC9678,
                March 2025, <https://www.rfc-editor.org/rfc/rfc9678>.

  11.2.  Informative References

     [FIPS203]  "FIPS-203: Module-Lattice-based Key-Encapsulation
                Mechanism Standard",
                <https://nvlpubs.nist.gov/nistpubs/FIPS/
                NIST.FIPS.203.pdf>.

     [I-D.ietf-emu-pqc-eapaka]
                Reddy.K, T. and A. Banerjee, "Post-Quantum Key
                Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime", Work
                in Progress, Internet-Draft, draft-ietf-emu-pqc-eapaka-01,
                26 February 2026, <https://datatracker.ietf.org/doc/html/
                draft-ietf-emu-pqc-eapaka-01>.

     [I-D.ietf-hpke-pq]
                Barnes, R. and D. Connolly, "Post-Quantum and Post-
                Quantum/Traditional Hybrid Algorithms for HPKE", Work in
                Progress, Internet-Draft, draft-ietf-hpke-pq-03, 6
                November 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-hpke-pq-03>.

     [I-D.ietf-pquip-pqc-engineers]
                Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
                T., and M. Ounsworth, "Post-Quantum Cryptography for
                Engineers", Work in Progress, Internet-Draft, draft-ietf-
                pquip-pqc-engineers-14, 25 August 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
                pqc-engineers-14>.

     [I-D.ietf-pquip-pqt-hybrid-terminology]
                D, F., P, M., and B. Hale, "Terminology for Post-Quantum
                Traditional Hybrid Schemes", Work in Progress, Internet-
                Draft, draft-ietf-pquip-pqt-hybrid-terminology-06, 10
                January 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-pquip-pqt-hybrid-terminology-06>.

     [I-D.irtf-cfrg-hybrid-kems]
                Connolly, D., Barnes, R., and P. Grubbs, "Hybrid PQ/T Key
                Encapsulation Mechanisms", Work in Progress, Internet-
                Draft, draft-irtf-cfrg-hybrid-kems-08, 27 January 2026,
                <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
                hybrid-kems-08>.



  Banerjee & Reddy         Expires 30 August 2026                [Page 12]


  Internet-Draft         PQC Hybrid in EAP-AKA prime         February 2026


     [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/rfc/rfc4086>.

     [RFC6090]  McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
                Curve Cryptography Algorithms", RFC 6090,
                DOI 10.17487/RFC6090, February 2011,
                <https://www.rfc-editor.org/rfc/rfc6090>.

     [RFC8037]  Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
                and Signatures in JSON Object Signing and Encryption
                (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
                <https://www.rfc-editor.org/rfc/rfc8037>.

     [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://www.rfc-editor.org/rfc/rfc9052>.

  Appendix A.  Acknowledgements

     This draft leverages text from [RFC9678].

  Authors' Addresses

     Aritra Banerjee
     Nokia
     London
     United Kingdom
     Email: aritra.banerjee@nokia.com


     Tirumaleswar Reddy
     Nokia
     Bangalore
     Karnataka
     India
     Email: kondtir@gmail.com












  Banerjee & Reddy         Expires 30 August 2026                [Page 13]


