# drafts

name: draft-nsiangani-authenticatedsecuredlayer
rev: 00
title: ASL Authenticated Secure Layer Protocol
time: 2026-02-11T17:04:47Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-15T17:04:47Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:09.014962+00:00
abstract:
  This document specifies ASL (Authenticated Secure Layer), a
  cryptographic
     protocol for establishing an authenticated and encrypted
  communication
     session based on a novel arithmetic primitive called phi-ns-x (also
  known
     as ns-mod). ASL provides a complete handshake and data transport
  layer
     without reliance on traditional algorithms like RSA, Diffie-Hellman,
  AES or
     SHA. Instead, it builds on the Phi-Ns cryptosystem, which defines a 
     structured quadratic relation between primes and achieves security
  through
     non-linear modular arithmetic and combinatorial complexity. 

     ASL includes an initial authentication and key exchange mechanism
  where a
     server public key (composed only of specific allowed elements such as
  a
     prime modulus and state parameters) is used by a client to establish
  shared
     secrets. The protocol uses a stateful encryption transform (phi-ns-x)
  for
     data, with each message round incorporating a public state value that
     changes unpredictably. Shared secret parameters control this state
  evolution,
     preventing man-in-the-middle and injection attacks by ensuring that
  only
     parties with knowledge of the secrets can produce valid ciphertexts.

full_text:
  Network Working Group                                P.J. Nsiangani, Ed.
  Internet-Draft                                         ACE Working Group
  Intended status: Standards Track                         9 February 2026
  Expires: 13 August 2026


                  ASL Authenticated Secure Layer Protocol
                draft-nsiangani-authenticatedsecuredlayer-00

  Abstract

     Complete ASL draft embedded below as imported text.  Replace this
     abstract with the structured version later if desired.

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







  Nsiangani                Expires 13 August 2026                 [Page 1]


  Internet-Draft                ASL Protocol                 February 2026


  Table of Contents

     1.  Imported Internet-Draft Content . . . . . . . . . . . . . . .   2
     2.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  63
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  63

  1.  Imported Internet-Draft Content

  ACE Working Group                               Author: P.J. Nsiangani Ed.
  Internet-Draft                draft-nsiangani-authenticatedsecuredlayer-00
  Intended status: Proposed Standard
  Expires: September 2026                                   09 February 2026

                    ASL Authenticated Secure Layer Protocol




  Status of this Memo

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

     This document is subject to the rights, licenses and restrictions
     contained in BCP 78 and BCP 79, and except as set forth therein,
     the authors retain all their rights.

     This document is provided under the terms of 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.

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

  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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.



  Nsiangani                Expires 13 August 2026                 [Page 2]


  Internet-Draft                ASL Protocol                 February 2026


     This Internet-Draft will expire in September 2026.

  Abstract

     This document specifies ASL (Authenticated Secure Layer), a
  cryptographic
     protocol for establishing an authenticated and encrypted
  communication
     session based on a novel arithmetic primitive called phi-ns-x (also
  known
     as ns-mod). ASL provides a complete handshake and data transport
  layer
     without reliance on traditional algorithms like RSA, Diffie-Hellman,
  AES or
     SHA. Instead, it builds on the Phi-Ns cryptosystem, which defines a
     structured quadratic relation between primes and achieves security
  through
     non-linear modular arithmetic and combinatorial complexity.

     ASL includes an initial authentication and key exchange mechanism
  where a
     server public key (composed only of specific allowed elements such as
  a
     prime modulus and state parameters) is used by a client to establish
  shared
     secrets. The protocol uses a stateful encryption transform (phi-ns-x)
  for
     data, with each message round incorporating a public state value that
     changes unpredictably. Shared secret parameters control this state
  evolution,
     preventing man-in-the-middle and injection attacks by ensuring that
  only
     parties with knowledge of the secrets can produce valid ciphertexts.


  Table of Contents

     1. Introduction ................................................... 3
     2. Terminology .................................................... 5
     3. The Phi-ns-x Cryptographic Primitive ........................... 7
        3.1. Fundamental Equations and Structure ....................... 7
        3.2. Sequential Encryption Recurrence (ns-mod) ................. 9
        3.3. Optional Layer Injection and Masking ......................
  11
        3.4. Cryptographic Properties of Phi-ns-x ......................
  12
     4. ASL Protocol Specification .....................................
  14



  Nsiangani                Expires 13 August 2026                 [Page 3]


  Internet-Draft                ASL Protocol                 February 2026


        4.1. Roles and Key Components ..................................
  14
        4.2. Session Establishment (Handshake) .........................
  15
        4.3. Round-Based Encrypted Messages ............................
  18
        4.4. Message Formats and Encoding ..............................
  20
     5. Example Use Cases ..............................................
  22
        5.1. HTTPS Without TLS (Web Security) ..........................
  22
        5.2. Blockchain Transactions ...................................
  23
        5.3. Implicit Client Identity Authentication ...................
  24
        5.4. Secure Messaging ..........................................
  25
        5.5. Encrypted Tunneling (VPN) .................................
  26
     6.Security Considerations ........................................ 27
        6.1. Man-in-the-Middle (MITM) ..................................
  27
        6.2. Collision Resistance ......................................
  28
        6.3. Secret Leakage and Oracle-Free Design .....................
  28
        6.4. Post-Quantum Resilience ...................................
  29
        6.5. Unpredictability of States ................................
  30
     7. IANA Considerations ............................................
  31
     8. References .....................................................
  32
        8.1. Normative References ......................................
  32
        8.2. Informative References ....................................
  33

  1. Introduction

     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
     RFC 2119 [RFC2119] and RFC 8174 [RFC8174] when, and only when, they
     appear in all capitals, as shown here.




  Nsiangani                Expires 13 August 2026                 [Page 4]


  Internet-Draft                ASL Protocol                 February 2026


     ASL (Authenticated Secure Layer) is a protocol that establishes an
     authenticated and encrypted channel between two parties (typically a
     client and a server) using only modular arithmetic operations for
     cryptographic security. ASL is designed as an alternative to TLS and
     similar protocols, particularly in contexts where post-quantum
  security,
     small key sizes, or avoidance of legacy primitives (RSA, ECC, AES,
  SHA)
     are desired. The protocol leverages the properties of the Phi-Ns
     cryptosystem [PhiNs] and its sequential encryption primitive (phi-
  ns-x) to
     achieve confidentiality and integrity in a novel way.

     The foundation of ASL's security is the Phi-Ns hardness assumption.
  Phi-Ns
     is an asymmetric cryptographic primitive based on the structured
     decomposition of a quadratic difference between two primes. In Phi-
  Ns,
     given two large primes p and q, the relation q^2 - p^2 = T defines a
     composite gap T (Eq0). This gap T is factored in a controlled way
  into a
     triple of secret values (a, b, R), where a and b are small exponents
  of
     2 and 3 respectively, and R is a remaining large cofactor. The tuple
     (a, b, R) is then encoded in a randomized manner. An attacker who
  only
     knows one of the primes (the public key) and a secure commitment to
  the
     encoded structure cannot feasibly recover the other prime or the
  tuple,
     because there is no oracle or structural hint to guide the search.
  The
     problem reduces to blindly guessing the correct prime and internal
  factors
     among an astronomically large set of possibilities. The Phi-Ns
  mechanism
     does not rely on integer factorization or discrete logarithm; instead
     its security arises from the ambiguity and combinatorial explosion of
     reconstructing the hidden structure from minimal public information.

     ASL uses this primitive in a session context. The protocol is
  composed
     of two phases: an **authentication and key exchange phase**
  (handshake),
     followed by a **secure data transport phase**. During the handshake,
  the
     server proves its identity and the two parties establish shared
  secret



  Nsiangani                Expires 13 August 2026                 [Page 5]


  Internet-Draft                ASL Protocol                 February 2026


     parameters that will drive the encryption of messages. The handshake
     avoids the need for any external certificate signatures or third-
  party
     trust anchors beyond a one-time publication of the server's public
  key
     (and an associated commitment value). The client authenticates the
  server
     by verifying a static masked value derived from q^2 (the servers
  hidden
     prime square), ensuring the server possesses the corresponding
  secret.
     Once authenticated, the client and server use phi-ns-x to exchange or
     derive symmetric secrets such as trajectory steps for the encryption
     state. In the data transport phase, every message is encrypted using
  a
     **sequential modular transform**: each encryption round employs the
     phi-ns-x recurrence with evolving public state values. Only the
  legitimate
     parties (having the shared secrets from the handshake) can maintain
  and
     predict the correct state sequence, making it infeasible for an
  outsider
     to inject valid messages or decipher the traffic.

     Unlike TLS which depends on PKI certificates, symmetric ciphers
  (AES), and
     hash-based HMAC for integrity, ASL achieves all these objectives
  through
     pure arithmetic. Authenticity is ensured by the possession of secret
     primes/factors and the correct derivation of state; confidentiality
  is
     provided by the non-linear encryption transform; and integrity is
     implicitly guaranteed since any modification to a ciphertext or state
  by
     an adversary results in a decryption failure (the decrypted data will
  not
     match the expected structure, and the receiver can detect this). The
     protocol is suitable for environments where conventional cryptography
  is
     hard to deploy: e.g., IoT devices with constrained resources (small
  keys
     and low processing overhead), or specialized scenarios like
  blockchain
     transactions where on-chain data must be encrypted yet verifiable.

     The remainder of this document is organized as follows. Section 2
     defines terminology used in the specification. Section 3 describes
  the



  Nsiangani                Expires 13 August 2026                 [Page 6]


  Internet-Draft                ASL Protocol                 February 2026


     phi-ns-x cryptographic primitive in detail, including its
  mathematical
     definitions (Eq0 through Eq6) and cryptographic properties (non-
  linearity,
     entropy, direct non-factorizability). Section 4 specifies the ASL
  protocol:
     the roles of client and server, the format of public keys and
  messages,
     the handshake exchange (including the use of a q^2_masked value for
  static
     signature), the concept of a rotating state in encrypted messages,
  and the
     handling of shared secrets. In Section 5, we present several use
  cases
     to illustrate how ASL can be applied: secure web communication
  without TLS,
     blockchain with encrypted payloads, implicit client identity
  verification
     via key usage, end-to-end secure messaging, and encrypted tunneling.
     Section 6 discusses security considerations, including resistance to
  MITM,
     collision and leakage analysis, post-quantum aspects, and the
  unpredictability
     of protocol state. Finally, Section 7 notes IANA considerations
  (none) and
     Section 8 provides references to relevant literature and standards.

     By introducing ASL as a formal Internet-Draft, our goal is to enable
     further scrutiny and implementation of this protocol. The design
  emphasizes
     a self-contained approach to security where all critical components
  are
     derived from a single hard problem (the phi-ns structured gap) and
  its
     associated modular arithmetic transform. This approach can complement
     ongoing efforts in post-quantum cryptography by providing a session-
  layer
     construction that is not only resistant to known quantum attacks but
  also
     efficient and compact.

  2. Terminology

     This section defines terms and notation used throughout this
  document.
     All definitions are normative for the ASL protocol and the underlying
     phi-ns cryptographic primitive.




  Nsiangani                Expires 13 August 2026                 [Page 7]


  Internet-Draft                ASL Protocol                 February 2026


     **Prime**: A positive integer greater than 1 whose only divisors are
  1 and itself.

     **p**: A secret prime in the Phi-Ns cryptosystem. In the PK-q mode of
  operation
     (public key = q), p is the private key. In the PK-p mode (public key
  = p),
     p is public while q is kept private. p participates in the core
  equation q^2 - p^2 = T.

     **q**: A prime associated with p in the Phi-Ns system. In PK-q mode,
  q is the public
     key; in PK-p mode, q is private. q is chosen such that q^2 - p^2 = T
  for some composite T.

     **T**: The quadratic gap defined by T = q^2 - p^2 (Eq0). T is a
  strictly positive composite
     integer resulting from the difference of the two prime squares. By
  construction, T is
     divisible by 4 (since q^2 - p^2 = (q - p)*(q + p), and q and p are
  either both odd or both even;
     for primes >2, both are odd, so q-p and q+p are even, making T
  divisible by 4).

     **a**: The exponent of 2 in the factorization of T. Specifically, a
  is the largest non-negative
     integer such that 2^a divides T, but 2^(a+1) does not. The value `a`
  is part of the secret
     tuple and is not revealed publicly.

     **b**: The exponent of 3 in the factorization of T (after removing
  the 2^a factor). Specifically,
     b is the largest non-negative integer such that 3^b divides T / 2^a,
  but 3^(b+1) does not. This
     value is also secret (part of the tuple) and not revealed. (Note: In
  the context of the encryption
     recurrence, the symbol b_i will be used to denote a different concept
  "door" values for injection
     which is unrelated to this exponent b. The usage will be clear from
  context.)

     **R**: The remaining composite factor of T after extracting 2^a *
  3^b. That is, R = T / (2^a * 3^b).
     R is an odd composite (not divisible by 2 or 3) and may consist of
  one or several prime factors.
     R is secret.

     **abR**: The structured decomposition of T into the tuple (a, b, R).



  Nsiangani                Expires 13 August 2026                 [Page 8]


  Internet-Draft                ASL Protocol                 February 2026


  This triple encapsulates all
     secret factors derived from the quadratic gap. Knowledge of abR
  (along with whichever prime was
     kept private) is equivalent to knowing the full private key.

     **Serialized abR**: A randomized encoding of the (a, b, R) tuple. In
  Phi-Ns key generation, the atoms
     (prime factors) comprising R are first partially factored (e.g.,
  small factors extracted), then all
     resulting factors ("atoms") are permuted in a pseudorandom order and
  grouped into blocks. The final
     encoded form includes the values a, b, a salt, the number of blocks,
  and the concatenated blocks of
     atoms in permuted order. This serialized abR is committed (e.g., via
  a hash or a public checksum)
     to serve as a validation of the key without revealing structure.

     **Recursive decomposition**: An optional process in Phi-Ns where the
  secret prime p itself is
     recursively defined by a smaller instance of the problem. For
  example, p^2 = p2^2 + T2, with its
     own (a2, b2, R2) decomposition. Recursion can be applied multiple
  times, each time increasing the
     entropy of the private key without increasing public key size. If
  recursion is used, the abR tuple
     implicitly contains nested layers of factors. ASL and phi-ns-x
  operate at the top level; recursion
     mainly affects key generation and security strength.

     **PK-q**: A public key exposure mode in which q is the public key and
  p (along with abR) is kept
     private. Attackers see q and a commitment to the serialized abR. They
  must attempt to guess the
     correct p (and structure) that yields that commitment. This is the
  "standard" mode analogous to
     most public-key systems where the public key is used for encryption.

     **PK-p**: A public key exposure mode where p is public and q (with
  abR) is private. Attackers see p
     and the commitment, but have no direct information about q or T. This
  mode offers higher security
     because the attacker does not even know the magnitude or sign of T =
  q^2 - p^2; q could be slightly
     larger than p or vastly larger, introducing more uncertainty.
  However, since encryption operations
     usually require knowledge of q (as an anchor for computations), PK-p
  mode in ASL is supported by
     providing alternate public parameters (such as q^2_masked and related



  Nsiangani                Expires 13 August 2026                 [Page 9]


  Internet-Draft                ASL Protocol                 February 2026


  values) that allow encryption
     without revealing q.

     **M**: A large prime modulus under which phi-ns-x sequential
  encryption operations are performed.
     All arithmetic for message encryption in ASL takes place in the
  finite field Z_M. M is chosen such
     that it is large enough to accommodate message space and security
  requirements (often on the order
     of 2^N for some N, or a safe prime). M is public and is one of the
  parameters included in the
     server's public key profile.

     **g**: A generator of the multiplicative group Z_M^*. The value g is
  used to advance public states
     in a cyclic manner. Typically, g is a primitive root modulo M. g is a
  public parameter.

     **u_k**: The public round state for round k. This is an element of
  Z_M^* (i.e., 1 <= u_k < M). In each
     round of encryption, a fresh u_k is used. The sequence {u_k} is
  deterministic for those who know the
     secret trajectory parameters (like step sizes), but appears
  pseudorandom to others. The initial state
     u_0 (for round 1) is provided by the server during the handshake.
  Subsequent u_k are either transmitted
     with each message or recomputed by each side using the shared secret
  state update rule.

     **a_k**: The public phase for round k, derived from u_k. It is
  computed as
     a_k = (u_k + inv(u_k)) * inv2 (mod M) (Eq2), where inv(x) denotes the
  modular inverse of x in Z_M,
     and inv2 is the modular inverse of 2 mod M. The value a_k lies in Z_M
  and is used in the encryption
     transform. The pair (u_k, a_k) can be viewed as public state
  parameters for the encryption of that
     round's message. Note that given u_k, anyone can compute a_k easily
  (so it may not always need to be
     explicitly transmitted if u_k is known).

     **step_u**: A secret trajectory parameter controlling how the public
  state u evolves each round. For
     example, a simple state update rule is u_{k+1} = u_k * g^{step_u}
  (mod M). The integer step_u (which
     may itself be randomly chosen or derived from the private key
  structure) is known to both client and
     server after the handshake but is never revealed publicly. Without



  Nsiangani                Expires 13 August 2026                [Page 10]


  Internet-Draft                ASL Protocol                 February 2026


  knowledge of step_u, an attacker
     cannot predict future states from past ones.

     **door values (b_i)**: Optional per-layer additive constants injected
  into the encryption recurrence
     to enforce a particular secret structure or order. In some profiles,
  each layer i of the multi-layer
     encryption uses an added term b_i (mod M) derived from the secret
  decomposition (for example, from
     factors of R or their permutation). These values are kept secret
  (shared only between sender and
     receiver) and if used, they modify the encryption formula. The term
  "door" implies that these values
     act as additional one-way doors; without knowing the correct b_i
  sequence, an attacker cannot properly
     encrypt or decrypt. (This use of b_i is distinct from the exponent b
  in the abR structure.)

     **stars**: A conceptual term referring to internal atomic factors or
  values derived from the secret
     structure which may be used to randomize encryption. For instance,
  the prime factors of R (after some
     processing) can be thought of as "stars". Star values might be used
  to derive door values or to vary
     certain steps of the encryption (such as choosing different q-related
  multipliers per layer). Some
     deployments publish *star projections*, which are transformations of
  these secret star values (e.g.,
     g^(star) mod M), in a shuffled order. The actual usage and ordering
  of stars in the encryption process
     remains secret (determined by parameters like star index and
  rotation), so an adversary may see a set
     of possible contributions but cannot know which were applied when.

     **rotation**: In the context of ASL, rotation refers to a secret
  offset or scheduling parameter that
     determines how internal factors (stars or others) are rotated or
  selected across encryption layers or
     rounds. For example, a rotation parameter `rot0` might set an initial
  starting index into a list of star
     factors, and with each layer or message, the index shifts according
  to another secret step (step_star).
     Rotation ensures that even if multiple internal factors are known in
  aggregate (e.g., via published star
     projections), the sequence in which they influence the encryption is
  unpredictable to an attacker. The
     rotation parameters are shared secrets between client and server.




  Nsiangani                Expires 13 August 2026                [Page 11]


  Internet-Draft                ASL Protocol                 February 2026


     **round**: A single encryption and transmission event in an ASL
  session. Each round k uses a unique
     u_k (and corresponding a_k) and results in a ciphertext (or set of
  ciphertext blocks) that constitutes
     one message. A session will have an ongoing round counter. Rounds may
  increment for every message
     sent in one direction, or they may alternate between parties
  (depending on the implementation, e.g.,
     client-to-server messages could use odd rounds and server-to-client
  even rounds). In any case, both
     sides keep track of round numbers and associated state to remain in
  sync.

     **q^2_masked**: A public value included in the server's key profile
  which serves as an *authenticated
     commitment to the value of q^2*, without revealing q. This value acts
  like a static signature or
     identity binding for the server's hidden prime. For example,
  q^2_masked might be computed as a certain
     residue or combination: such as q^2 modulo some large public number,
  or q^2 with certain parts obscured
     by secret factors. The design of q^2_masked is such that an attacker
  cannot derive q from it, but a
     legitimate client (who has obtained the correct public key parameters
  out-of-band or from a trusted
     directory) can use it to verify that the server's provided parameters
  are consistent with the genuine q.
     In ASL, q^2_masked is used during the handshake to prevent man-in-
  the-middle impersonation: it MUST
     match the expected value for the server's identity, or else the
  client aborts the connection.

     **ASL session**: A run of the protocol between a client and a server,
  from the initial handshake through
     the exchange of data rounds, terminating either by explicit closure
  or timeout. An ASL session yields
     a set of shared secrets (trajectory parameters, etc.) and an evolving
  state, which are used to encrypt
     and decrypt messages between the parties.

  3. The Phi-ns-x Cryptographic Primitive

     Phi-ns-x (also referred to as the ns-mod transform) is the sequential
  encryption core used by ASL.
     It operates in a multiplicative group of integers modulo a prime M.
  This section describes the
     mathematics of phi-ns-x in detail, including the derivation of its
  equations (Eq0 through Eq6) and



  Nsiangani                Expires 13 August 2026                [Page 12]


  Internet-Draft                ASL Protocol                 February 2026


     an explanation of its cryptographic properties.

     At a high level, phi-ns-x can be seen as a keyed non-linear
  transformation that takes an element
     (representing a plaintext or intermediate state) and produces another
  element (ciphertext or next
     state) such that reversing this transform is infeasible without
  knowledge of a secret (the prime
     p or equivalent internal parameters). Each transformation can be
  iterated (layered) to amplify
     confusion and hide any algebraic relationship between input and
  output. The design is inherently
     modular and does not rely on any polynomial or linear structures that
  could be exploited by an
     attacker.

  3.1. Fundamental Equations and Structure

     We begin with the fundamental equation defining the relationship
  between the two primes p and q,
     and the composite value T:

     **(Eq0)**: q^2 - p^2 = T

     This equation is the cornerstone of the Phi-Ns cryptosystem. T must
  be non-zero, positive, and composite.
     Given Eq0, one can express T as a difference of squares: T = (q -
  p)*(q + p). However, simply knowing T
     (if it were published) would trivially leak information about p and q
  (since one could attempt to factor
     T or solve the equations for p and q). Therefore, T itself is never
  revealed. Instead, the structure of
     T is hidden through factorization and encoding.

     The first step in handling T is to factor out small prime powers 2^a
  and 3^b:

     **(Eq1)**: T = 2^a * 3^b * R

     where `a` = ord_2(T) (the exponent of 2 in T), and `b` = ord_3(T /
  2^a) (the exponent of 3 after removing
     the 2-power). After extracting these, R = T / (2^a * 3^b) is the
  remaining factor. By definition of a and b,
     R is not divisible by 2 or 3. R could be prime or composite; if
  composite, it may have several prime factors
     which are typically of varying sizes.

     The tuple (a, b, R) is the raw "structured secret" derived from T.



  Nsiangani                Expires 13 August 2026                [Page 13]


  Internet-Draft                ASL Protocol                 February 2026


  All parts of this tuple are kept secret
     in Phi-Ns. In practice, the values a and b are relatively small (they
  count small factors), while R carries
     most of the cryptographic weight (bits of entropy).

     Next, Phi-Ns employs a **randomized serialization** of (a, b, R) to
  ensure that no structure of R or the
     order of factors leaks. This process can be summarized as:

     - Partially factor R (not revealing full factorization if R is large,
  but extracting small factors up
       to a certain bound). Each factor (whether prime or an unfactored
  cofactor) is considered an "atom".
     - Generate a random seed and salt for this key.
     - Permute the list of atoms using a pseudorandom permutation derived
  from the seed.
     - Partition the permuted atoms into a certain number of blocks (the
  number of blocks may itself be derived
       from a pseudorandom function of the seed or salt).
     - Construct the serialized encoding as: [a, b, salt, block_count,
  (block1 || block2 || ... || blockN)],
       where || denotes concatenation of the binary representation of each
  block. Each block might be delimited
       by length or another indicator so that the parsing is unambiguous.

     The serialization is deterministic given the seed, but appears random
  to anyone without the seed. Even if
     an attacker could factor R (which might be extremely large or
  structured to resist factoring), the permutation
     and block partitioning mean the attacker cannot tell which factors
  correspond to which positions in the original
     T structure. In essence, many different tuples (a, b, R) could result
  in the same multiset of factors, and the
     serialization further obscures the arrangement. The total number of
  possible encodings of the same T (due to
     permutations and partitions) is combinatorially large, adding another
  layer of difficulty to any brute force attack.

     In implementations, the final serialized abR is typically committed
  via a cryptographic hash (e.g., a SHA-256
     digest) or another one-way function, and that commitment is published
  as part of the public key. In ASL, we
     avoid external hash functions as a core dependency (per the design
  goal of pure arithmetic security), so an
     alternative approach is used: the q^2_masked value and possibly other
  arithmetic check values serve to commit
     to this structure. Still, conceptually, one can imagine that the
  client is assured of the integrity of abR



  Nsiangani                Expires 13 August 2026                [Page 14]


  Internet-Draft                ASL Protocol                 February 2026


     through these mechanisms, meaning the server cannot change its
  internal structure without detection once the
     public key is set.

     To summarize, the public key information made available (depending on
  mode) is:
     - Either p or q (one prime, not both).
     - A commitment to the serialized abR (through q^2_masked or similar
  means).
     - Possibly, parameters like M, g, and some initial state or other
  auxiliary public values.
     The attacker is missing one prime and the entire abR tuple. The
  security assumption is that finding the missing
     values is infeasible.

  3.2. Sequential Encryption Recurrence (ns-mod)

     Phi-ns-x defines how a message is encrypted in a sequential (layered)
  fashion using the public state parameters
     (u_k, a_k) and the secret prime (with its abR structure). All
  operations take place in the finite field Z_M.

     Let us consider a single round k of encryption (for a given session
  state). We have:
     - Public inputs: u_k in Z_M^*, and a_k computed as a_k = (u_k +
  inv(u_k)) * inv2 (mod M). (We restate Eq2 here.)
     - A plaintext message represented as an integer m in the range [0,
  M-1] (if m is larger or is a byte sequence,
       it can be parsed into one or multiple integers mod M or handled
  with padding; for now assume m fits in Z_M).
     - The encryption will be applied in L layers (iterations) to increase
  non-linearity. L may be a fixed parameter
       or derived from the private key (for instance, it could correlate
  with the depth of factorization or be a
       security parameter indicating how many times to apply the
  recurrence).

     We denote p_0 = m (the plaintext as the initial state for
  encryption). Then for each layer i from 1 to L, we compute:

     - **(Eq3)**: y_i = (p_{i-1} + a_k) mod M.

     This is a simple shift of the previous state by the phase a_k. Note
  that if p_{i-1} = -a_k (mod M), then y_i = 0;
     in general encryption we must ensure y_i != 0 (mod M) because we will
  require a modular inverse of y_i in the next step.
     If y_i does turn out to be 0, this indicates a degenerate case for
  this round (a collision between -a_k and the state);



  Nsiangani                Expires 13 August 2026                [Page 15]


  Internet-Draft                ASL Protocol                 February 2026


     the specification dictates that in such a case the encryptor SHOULD
  abandon this round and either increment to the next
     round (i.e., update u and a to new values) or apply an agreed-upon
  remediation (such as adding a small nonce to m and
     trying again). This situation is extremely unlikely for random a_k
  and p_{i-1} unless an attacker deliberately crafts
     m = -a_k, but we mention it for completeness.

     Given y_i (which is non-zero mod M), define inv(y_i) as the
  multiplicative inverse of y_i modulo M. The core
     encryption transform for layer i is then:

     - **(Eq4)**:
       ```
       p_i = ( (y_i^2 - y_i) + (p_{i-1} * a_k) ) * inv(y_i)  (mod M).
       ```

     Expanding and simplifying Eq4, we can see the transformation more
  clearly:

       p_i = [y_i^2 - y_i + p_{i-1} * a_k] * y_i^{-1} (mod M).

     This can be interpreted as a quadratic recurrence. If we substitute
  y_i = p_{i-1} + a_k, then:
     y_i^2 - y_i = (p_{i-1} + a_k)^2 - (p_{i-1} + a_k) = p_{i-1}^2 +
  2*p_{i-1}*a_k + a_k^2 - p_{i-1} - a_k.
     So the numerator in Eq4 becomes: p_{i-1}^2 + 2*p_{i-1}*a_k + a_k^2 -
  p_{i-1} - a_k + p_{i-1} * a_k.
     Simplifying: = p_{i-1}^2 + (2*a_k + a_k)*p_{i-1} + a_k^2 - p_{i-1} -
  a_k.
     = p_{i-1}^2 + 3*a_k * p_{i-1} + a_k^2 - p_{i-1} - a_k.

     However, this expansion is not particularly illuminating for
  cryptanalysis; what matters is that the update
     from p_{i-1} to p_i is highly non-linear (it involves a quadratic
  term p_{i-1}^2 and cross-term p_{i-1} * a_k,
     all under modular arithmetic). The division by y_i (which itself
  depends on p_{i-1}) further entwines the terms.

     After L layers, we obtain p_L, which we denote as X (the result after
  encryption layers). If L=1, we have a single
     application of the transform; typically L might be on the order of 2
  to 5 for practical parameters, but it can be
     larger if needed. The final value X = p_L is the output of the
  sequential encryption for this round.

     It's important to note that the encryptor, to compute this, only
  needs to know:



  Nsiangani                Expires 13 August 2026                [Page 16]


  Internet-Draft                ASL Protocol                 February 2026


     - a_k (publicly computable from u_k).
     - The value u_k (public, but not directly used in formula except to
  get a_k).
     - The plaintext m (as p_0).
     - The number of layers L and if any other per-layer parameters are
  fixed by protocol.

     The encryptor does **not** need to know p, q, or any of the secret
  decomposition (those are only needed for key
     generation and possibly for the receiver to verify or derive some
  things). This is intentional: it means anyone
     with the public parameters and current state can encrypt a message.
  In ASL, however, not just anyone should be
     allowed to encrypt data that the server will accept; we mitigate
  unauthorized encryption through the use of
     shared secret parameters (like door values or required structure in
  the ciphertext) described later. But
     mathematically, the transform itself is public.

     On the decryptor side, if one has the secret prime p (and knowledge
  of a_k and X), recovering p_{L-1} (and eventually
     m = p_0) is possible by inverting the recurrence using p and the
  internal key structure. The inversion is non-trivial
     for an outsider but straightforward for someone with the correct key:
  essentially, the decryptor will run a process
     to find which candidate p_{L-1} could produce X under the transform,
  guided by the secret knowledge (like knowing q
     or certain invariants). This process is beyond the scope of this
  section, but suffice to say it exists and is efficient
     for the legitimate party. For an attacker, trying to invert without p
  is akin to solving a random quadratic equation
     in a large finite field with no contextual cluesa problem believed to
  be infeasible for cryptographically chosen sizes.

     For completeness, we note that some algebraic rearrangement can
  express Eq4 in alternative forms. For example, one can
     multiply out the division to get:
  p_i * y_i  y_i^2 - y_i + p_{i-1} * a_k   (mod M),
  or:
  p_i * (p_{i-1} + a_k)  (p_{i-1} + a_k)^2 - (p_{i-1} + a_k) + p_{i-1} *
  a_k   (mod M).
  Simplifying that:
  p_i * (p_{i-1} + a_k)  p_{i-1}^2 + a_k^2 + 2*p_{i-1}*a_k - p_{i-1} - a_k
  + p_{i-1}*a_k   (mod M),
  which reduces to:
  p_i * (p_{i-1} + a_k)  p_{i-1}^2 + 3*p_{i-1}*a_k + a_k^2 - p_{i-1} - a_k
  (mod M).
  There is no obvious further simplification or factorization here; this



  Nsiangani                Expires 13 August 2026                [Page 17]


  Internet-Draft                ASL Protocol                 February 2026


  is a purposely irreducible-looking relation
  mod M, which is good for security.

  In summary, the sequential encryption recurrence (Eq3 and Eq4) takes an
  input p_{i-1} and produces p_i under control
  of "keyed" value a_k. For a full encryption round of a message, we
  iterate this L times (using the same a_k each layer
  in a given round k).

  **After L layers**, the final output X = p_L is either used directly as
  the ciphertext of round k or undergoes a final
  post-processing to bind it to the identity parameters (see below). For
  many scenarios, X itself is transmitted as the
  ciphertext.

  If we make an analogy, one can think of phi-ns-x as a sort of "stream
  cipher" or "state cipher" where a public state
  (u_k, a_k) acts somewhat like an IV (initialization vector) and the
  secret prime p and its hidden structure act
  like the key that allows decryption. However, unlike a conventional
  stream cipher IV, here the IV (state) changes
  in a correlated way each round under secret control (step parameters),
  and unlike a normal block cipher, the
  transformation is heavily non-linear with a trapdoor.

  3.3. Optional Layer Injection and Masking

  The base transform described by Eq3 and Eq4 is already non-linear.
  However, to further thwart any attempt at
  cryptanalysis, some deployments of phi-ns-x introduce additional secret
  inputs per layer. We refer to this as
  "door injection" because it introduces extra secret "doors" that one
  must know to successfully navigate the encryption
  path.

  Concretely, if we have secret door values b_i for layer i (with 1 <= i
  <= L), the encryption recurrence can be
  modified to:

  - **(Eq5)**:
    ```
    p_i = ( (y_i^2 - y_i + p_{i-1} * a_k) * inv(y_i) + b_i )  (mod M).
    ```

  Compare Eq5 with Eq4: we simply add b_i (mod M) to the result of the
  core transform. The value b_i is chosen in some
  deterministic but secret way, possibly derived from the abR structure.
  For example, if R has multiple prime factors,



  Nsiangani                Expires 13 August 2026                [Page 18]


  Internet-Draft                ASL Protocol                 February 2026


  each layer's b_i could be linked to one of those factors or some
  function of it. Another approach is to derive all b_i
  from a pseudorandom generator seeded with some secret (like t0 in the
  blockchain example, which might be a random or
  chosen starting value).

  If door values are used, the precise method by which they are generated
  and applied MUST be agreed upon as part of
  the protocol profile. This document specifies the extension point but
  not the exact derivation, as it can differ
  based on use case:
  - In one profile, b_i might all be zero (meaning no injection, which
  defaults to Eq4 behavior).
  - In another, b_i might cycle through a small set of constants derived
  from the secret key.
  - In an advanced usage, b_i might be tied to "star factors": e.g., if R
  had factors r1, r2, r3..., we might define
    a series where b_1 = f(r_{idx0}), b_2 = f(r_{idx0+1 mod n}), etc.,
  effectively rotating through factors with some
    function f (like taking a reduced residue). The `rot0` and `step_star`
  parameters (see Terminology) would control
    how the index through star factors advances with each layer or round.

  The effect of Eq5 is that even if an attacker somehow deduced the
  functional form of Eq4, they would still be missing
  an additive piece in each layer. Without knowing b_i, an attackers
  attempt to guess p_i from p_{i-1} and a_k would
  systematically fail, as they'd always be off by this unknown offset.
  Only the true receiver, who can either compute
  or brute-force check the correct b_i (knowing the key, there might be
  only one value that makes the decrypted plaintext
  intelligible or fits the key structure), can properly invert the
  equation.

  For interoperability, ASL defines that by default no layer injection is
  used (b_i = 0 for all i) unless a specific
  profile explicitly incorporates it. This keeps the core specification
  simpler. However, implementations SHOULD support
  at least the possibility of one non-zero door value (e.g., a constant
  offset or a simple pattern) to be future-proof
  or to integrate with extended profiles that enhance security via this
  mechanism.

  Additionally, beyond per-layer injection, one may consider a final
  masking of the ciphertext. One such method,
  inspired by the Phi-Ns identity binding, is to incorporate q (or T) into
  the output. For instance:




  Nsiangani                Expires 13 August 2026                [Page 19]


  Internet-Draft                ASL Protocol                 February 2026


  - **(Eq6)**:
    ```
    C = (X + q)^2 - T * a_k^2,
    ```
    where X = p_L is the output after L layers. In this construction, the
  transmitted ciphertext C is a quadratic
    residue that depends on q and T. The receiver, knowing T (since they
  know p and q), can compute (X + q)^2 = C + T * a_k^2,
    and since they know q, they can solve for X (because (X+q)^2 is known,
  taking square root yields two options (X+q),
    but one of those will be consistent with the expected sign or range of
  X+q, etc.). This effectively uses the knowledge
    of T as an extra key: an attacker who intercepts C cannot recover X
  without solving the equation involving T (which
    is secret). If M and the size of q are large enough, even trying to
  brute force q from q^2 (mod something) would be
    infeasible, especially since a_k^2 * T is subtracted which acts as a
  blinding factor for outsiders.

  The Eq6 example is just one possible "ciphertext projection". ASL may
  employ simpler approaches for final output as well,
  such as transmitting X as-is, or X plus some constant mask. The choice
  can be left to profile definitions. The goal of any
  such masking is to tie the ciphertext to the static key in a way that
  doesn't affect legitimate decryption but makes
  cryptanalysis harder.

  3.4. Cryptographic Properties of Phi-ns-x

  The phi-ns-x transform possesses several properties that underpin the
  security of ASL:

  - **Non-linearity**: The core equations (Eq3Eq5) are non-linear
  (quadratic) in the plaintext/state variable. Unlike
    linear transformations (which could be solved or inverted with linear
  algebra or by observing linear relations),
    phi-ns-x produces outputs that are quadratic residues of input
  combinations. The presence of terms like p_{i-1}^2
    and p_{i-1} * a_k inside a modulus means the transformation does not
  have a simple algebraic inverse without knowing
    secret parameters. Cryptanalytic attacks that rely on linearity, such
  as certain forms of differential or linear
    cryptanalysis, find no straightforward linear approximation here.

  - **High Entropy Mixing**: Each layer of transformation mixes the
  previous state with the phase a_k and (if used) door
    value b_i. Even if the plaintext has a structure or the attacker can
  choose plaintexts, the output after one layer is



  Nsiangani                Expires 13 August 2026                [Page 20]


  Internet-Draft                ASL Protocol                 February 2026


    significantly de-correlated from the input. After L layers, the output
  is effectively psuedo-random from the attacker's
    perspective (assuming a_k is not under attacker controlwhich it isn't,
  since it's derived from a secret-driven state
    u_k). The introduction of multiple layers and optional per-layer
  secrets ensures that even a single round of encryption
    in ASL provides a high-entropy ciphertext.

  - **Combinatorial State Space**: If an attacker attempts to guess the
  secret (whether it's p or the abR structure or the
    door values), they face a combinatorial explosion. For example,
  consider the problem of forging a valid ciphertext
    without knowing the secrets. The attacker would have to guess the
  correct p_{0} (plaintext) that, under the unknown
    transform, yields a meaningful result, guess the unknown b_i for each
  layer if any, and produce an output that the
    receiver will accept. Because any wrong guess is effectively
  undetectable to the attacker (there is no oracle giving
    feedback if a guess is "close" or partially correct), the attacker is
  left with an all-or-nothing brute force. This
    is akin to the situation with the underlying Phi-Ns key: an attacker
  guessing p gets no feedback that helps refine
    the next guess.

  - **No Direct Factorizability**: The encryption transform does not lend
  itself to being "factored" or decomposed into
    independent sub-problems. In some ciphers, an attacker can break the
  problem into parts (for instance, attacking
    rounds one by one, or separating a key into two halves via meet-in-
  the-middle). In phi-ns-x, the structure is such that
    any partial knowledge (say an attacker hypothetically guesses part of
  the state or one layer's output) does not linearly
    reduce the complexity of determining the rest. The presence of non-
  linearity and modulus coupling means that solving
    for any unknown inherently requires solving the whole set of
  equations. This holistic complexity is by design; it's
    analogous to the way that in Phi-Ns key recovery, one must guess
  everything (p and full abR) to verify a solution, with
    no way to systematically solve piecewise.

  - **Entropy Amplification via Recursion**: If recursive decomposition is
  used in key generation, the effect on security
    is an exponential increase in search space for an attacker. For the
  legitimate participants, recursion is mostly
    transparent (they just have a larger key to work with, but
  encryption/decryption operations remain the same top-level
    ones). For an attacker, however, recursion means that even if they
  tried to brute force something like p or q, that



  Nsiangani                Expires 13 August 2026                [Page 21]


  Internet-Draft                ASL Protocol                 February 2026


    would not be sufficientthey would face another hidden layer of
  structure inside p itself, and so on. The security of
    ASL with recursively structured keys thus compounds with each layer of
  recursion.

  - **Post-Quantum Resistance**: There are no known quantum algorithms
  that can solve the Phi-Ns inversion problem in
    polynomial time. Shor's algorithm, which breaks RSA and ECC, is
  ineffective here because it requires working with a
    known composite or performing an order-finding in a group derived from
  known primesPhi-Ns reveals no such composite
    and no such group structure to the attacker. The best one could do
  with a quantum computer is apply Grover's algorithm
    to brute force search for the secret, which gives a quadratic speedup.
  However, because the search space (the set of
    possible p and abR combinations consistent with the public info) grows
  combinatorially with key size (especially due
    to randomization and recursion), even Grover's quadratic speedup is
  insufficient to threaten realistic parameter sizes.
    For example, if the classical brute force space is 2^256, Grover might
  reduce that to 2^128 steps, which is still
    computationally infeasible.

  - **No Partial Disclosure or Oracle**: The design of ASL and phi-ns-x
  ensures that an attacker cannot gain partial
    information that leads to a snowball effect. The protocol never
  discloses T, the exact abR ordering, or any one-way
    function output that could be inverted. There is also no encryption or
  decryption oracle accessible to attackers:
    during handshake, if an attacker tries to impersonate or send
  incorrect values, the protocol will simply fail (the
    client or server will abort), without giving the attacker clues as to
  which part was wrong. During data transmission,
    an attacker cannot query the decryptor in any useful wayif they send a
  bogus ciphertext, the receiver will either
    drop it (if authenticity checks fail) or decrypt to nonsense. This "no
  oracle" principle is inherited from Phi-Ns and
    is preserved in ASL. It is crucial for preventing adaptive attacks; an
  adversary cannot, for instance, tweak a ciphertext
    slightly and ask "did that decrypt correctly?" as a means to learn
  about the key.

  In summary, the phi-ns-x primitive provides a robust cryptographic core
  for ASL. It ensures that without the private
  key material (p and abR, plus any shared trajectory secrets), an
  attacker faces a cryptographically hard problem to
  either decrypt messages or forge new ones. The combination of structural
  secrecy (from Phi-Ns) and dynamic state secrecy



  Nsiangani                Expires 13 August 2026                [Page 22]


  Internet-Draft                ASL Protocol                 February 2026


  (from phi-ns-x's state evolution) makes ASL a moving target,
  cryptanalytically speaking.

  4. ASL Protocol Specification

  In this section we describe the ASL protocol in detail. We start with
  the roles and the components that each party
  holds, then delineate the handshake (session establishment phase),
  followed by the ongoing message encryption process,
  and the exact format and encoding of messages.

  4.1. Roles and Key Components

  ASL involves two primary roles: the **client** and the **server**.
  Typically, the server is the party that has a long-term
  key pair (the Phi-Ns key) and provides a service (like a website, an API
  endpoint, or a blockchain node), and the client
  is the party initiating the secure session, who may or may not have its
  own long-term key. This asymmetry mirrors usage
  patterns of TLS (servers present certificates, clients initiate
  handshake). However, ASL can be used in a peer-to-peer
  context as well, where both parties have keys and either can act as
  "server" for initiating a connection.

  **Server Key Materials**: The server possesses:
  - A key pair (p, q) along with the secret decomposition (a, b, R).
  Depending on the chosen mode:
    - In PK-q mode: q is the public key, and p with abR is private.
    - In PK-p mode: p is public, and q with abR is private.
  - A set of public parameters associated with the key:
    - The prime modulus M used for phi-ns-x operations.
    - The generator g for Z_M^*.
    - Possibly one or more recommended profiles or parameter sets (like
  the typical size or number of layers L).
  - A commitment to the secret structure:
    - Either a cryptographic hash of the serialized abR, or in our design,
  a numeric value that serves the same purpose (q^2_masked).
  - Optionally, a set of *auxiliary public values* that assist in
  encryption without revealing secrets:
    - For PK-p mode: values derived from q or R that allow the client to
  perform encryption. For example, **q_anchor** (an "anchor" value related
  to q, such as q mod M or q mod some smaller base) and **star
  projections** (a list of g^f mod M for some secret factors f). These
  were illustrated in the blockchain use-case as `q_anchor` and a list of
  star projections. In a general protocol context, these might or might
  not be transmitted, but if used, they are included in the server's
  initial handshake message.
  - Policy information: e.g., how often the key is refreshed (the Phi-Ns



  Nsiangani                Expires 13 August 2026                [Page 23]


  Internet-Draft                ASL Protocol                 February 2026


  key can be re-randomized via abR re-serialization without changing p or
  q), supported modes (PK-p or PK-q or both), and supported use of
  advanced features like door injection.

  The server's **public key profile** can thus be summarized as a
  structure containing: { mode, p_or_q, M, g, [q^2_masked], [q_anchor],
  [star_projections], [others...] }. This profile would be published or
  made available to clients via some secure channel (like DNS, a
  blockchain, or an offline distribution), similar to how a TLS server has
  a certificate.

  **Client Key Materials**: In many scenarios, the client may operate
  without a long-term key pair (just as most web clients do not have a
  certificate). ASL can accommodate a client with no long-term keys; the
  client will simply generate some ephemeral values during the handshake
  (like a random session secret to send to server). However, ASL also
  allows mutual authentication: a client could have its own Phi-Ns key
  pair and authenticate itself to the server in a similar way (this would
  be analogous to client certificates in mutual TLS, but achieved via the
  same mechanism as the servers authentication). For brevity, we focus on
  the typical case of server-authenticated, client-unauthenticated
  sessions, but we will note where a client key could come into play.

  Regardless of having a long-term key, the client will generate some
  **ephemeral secrets** during the handshake:
  - A random session secret `K_s` (for example, 256 bits) that will be
  used to derive shared parameters (like step_u, step_star, etc.). Instead
  of directly using this as a symmetric key as in RSA-based TLS, ASL can
  incorporate this secret into the phi-ns-x encryption so that only the
  server (with its private key) can recover it.
  - Potentially an ephemeral Phi-Ns key pair for forward secrecy: The
  client might generate a fresh small Phi-Ns instance (p_e, q_e) just for
  this session and provide q_e in the handshake (with a commitment to
  ensure authenticity). The server could then combine keys in some manner
  or simply switch roles and encrypt something back to the client using
  the client's ephemeral public key. This is an advanced option and not
  required; forward secrecy can also be achieved by discarding the session
  secrets after use.

  After the handshake, both client and server will share:
  - The trajectory parameters for state updates: e.g., step_u (for u
  sequence), step_star (for star rotation), rot0 (initial rotation),
  star_idx0 (starting index for star usage), L (number of layers for phi-
  ns-x), etc. These are either negotiated or derived from the exchanged
  secret.
  - The current state values: u_0 (initial state for round1, provided by
  server), and consequently a_0 (which client can compute).
  - Any symmetric key material needed for additional encryption or



  Nsiangani                Expires 13 August 2026                [Page 24]


  Internet-Draft                ASL Protocol                 February 2026


  authentication (if we overlay a MAC or use symmetric encryption for
  payload, but ASL's design tries to avoid separate MAC by making
  ciphertext self-authenticatingstill, a session might derive a key to,
  say, authenticate certain out-of-band signals or to mix into application
  protocols).
  - Optionally, if client authentication was performed, the server
  similarly learns some shared secret that confirms the client's identity.

  In summary, the server is the holder of the master key (Phi-Ns key) and
  provides public parameters; the client initiates communication and
  contributes randomness to create unique session keys. The protocol
  ensures that after the handshake, both sides have identical sets of
  secret parameters which they will use to synchronize the stateful
  encryption.

  4.2. Session Establishment (Handshake)

  The ASL handshake is the process by which the client and server
  establish a secure context. The handshake achieves:
  1. Server Authentication: The client gains confidence that it is
  communicating with the legitimate server (not an impersonator), via the
  server demonstrating knowledge of its secret key (p, q) in a non-
  forgeable way (using q^2_masked and successful decryption of a test
  secret).
  2. Establishment of Shared Secrets: The client and server arrive at
  common values (the "session keys" or parameters) that will be used for
  encrypting and decrypting application data. Only the two parties learn
  these values.
  3. (Optional) Client Authentication: If required, the server can also
  authenticate the client, either via a similar mechanism or by verifying
  that the client knows a pre-shared secret. In many applications this
  step is omitted, or handled at the application layer (e.g., via a login
  after the secure channel is up).

  The handshake can be described as a sequence of message exchanges. We
  define the messages in an abstract format here:

  - **ClientHello**: This is the first message sent by the client to the
  server. It may include:
    - A protocol version identifier (to handle future versions or backward
  compatibility).
    - A list of cipher suite preferences or capabilities (in ASL's
  context, this could indicate whether the client supports certain
  profiles, e.g., injection or recursion or PK-p vs PK-q mode
  preferences).
    - A random nonce or session identifier (client_random) for the
  handshake, to ensure freshness.
    - Optionally, an ephemeral public key of the client if doing mutual



  Nsiangani                Expires 13 August 2026                [Page 25]


  Internet-Draft                ASL Protocol                 February 2026


  key exchange (e.g., the client could include q_e (ephemeral) and a
  commitment of its own, but this is optional).
    - Optionally, any cookie or anti-DoS token if a prior stateless
  negotiation mechanism is used (similar to DTLS or IKE cookies; this is
  an operational detail not core to cryptography).
    - The ClientHello in ASL can actually be minimal if the protocol
  doesnt need negotiation: in the simplest case, it might just be a packet
  indicating "I want to start ASL handshake" plus a random.

  - **ServerHello (ServerParams)**: The server responds with its
  parameters. This is a critical message containing:
    - The selection of protocol version and profile (if any negotiation;
  likely just mirrors what client said if supported).
    - The server's public key information:
      - `mode` (PK-p or PK-q).
      - `p_public` (if mode is PK-p) or `q_public` (if mode is PK-q).
  We'll use p_public to denote whichever prime is being revealed as
  public.
      - `M` (modulus for encryption).
      - `g` (generator for state updates).
      - `q^2_masked` (the masked commitment to q^2, as defined in
  Terminology).
      - If mode is PK-p (so q is secret), then **auxiliary encryption
  parameters** must be provided so the client can perform encryption. This
  could include:
        - `q_anchor`: a value that serves as a temporary anchor for
  encryption calculations. For example, the server might provide q mod M
  as q_anchor. Since p is public, q mod M alone might not give away q if M
  is much smaller than q or if multiple possible q yield the same mod M
  (which can happen if q > M).
        - A set of `star_projections`: e.g., a shuffled list of g^(factor)
  mod M for factors of R or related values. This effectively gives the
  client a pool of values that relate to secret components, one of which
  might need to be used in encryption layers, but the attacker doesn't
  know which or how.
        - The rationale is that with p_public known, the client can
  compute T mod M if it had q mod M (because T = q^2 - p^2, so T mod M =
  (q mod M)^2 - (p mod M)^2 mod M). If M is large and not a factor of T or
  anything, this by itself may not leak too much. Anyway, the specifics of
  q_anchor usage would be profile-defined. The point is the server
  supplies whatever is necessary for the client to execute phi-ns-x
  encryption.
      - If mode is PK-q (so q is public), then providing q itself is
  enough for encryption; auxiliary parameters might not be needed, though
  the server could still provide some precomputed values or
  recommendations (like how many layers to use).
    - The server's initial state:
      - `u_0` (or u_1 depending on indexing) for the first round of



  Nsiangani                Expires 13 August 2026                [Page 26]


  Internet-Draft                ASL Protocol                 February 2026


  encryption after the handshake.
      - The server might also supply `a_0` for convenience, but since a_0
  can be derived from u_0, this is optional. However, including a_0 allows
  the client to double-check calculation.
      - A round number or session ID if needed. For example, round=0 might
  be implicit for handshake phase.
    - A server_random nonce and possibly a session ID (to pair with
  client_random for key derivation and to avoid replay).
    - Optionally, a signature or proof over all these parameters. In
  classical TLS, the server would now send a Certificate and a signed
  ServerKeyExchange to prove possession of the private key corresponding
  to the certificate's public key. In ASL, we achieve this proof not by an
  external signature algorithm but inherently:
        * The inclusion of q^2_masked is one form of static proof (the
  client will verify this matches the known value for this server
  identity).
        * Additionally, the server will prove its private key knowledge by
  being able to decrypt the client's next message correctly. If the server
  were fake and didn't have the key, it would fail to respond properly in
  the next step, which the client would detect.
        * However, there is a potential for a subtle MITM if we aren't
  careful: an attacker could relay messages between client and real server
  without knowing the key. To prevent that, some binding of handshake
  messages is needed, similar to the Finished message in TLS. We will
  address that with a final handshake verification.
    - (If client authentication is desired) a request for client key or
  info, akin to a CertificateRequest in TLS. In ASL, that could be an
  indication like "please prove who you are by sending an encrypted blob I
  can verify," but we'll not elaborate here.

  - **ClientKeyExchange (ClientEncryptedSecret)**: After receiving the
  server's parameters, the client verifies:
    - The server's `p_public` or `q_public` matches the expected identity
  (for example, the user might have the server's p or q fingerprint
  configured, or in a web scenario, this would be checked against some
  known value or a trust on first use store).
    - The `q^2_masked` matches the known commitment for that server (this
  might be published through DNS or a public ledger or given out-of-band).
  If this check fails, the client MUST abort the handshake (since it
  indicates the server's parameters are not consistent with the legitimate
  key).
    - If the check passes, the client proceeds to encrypt a secret for the
  server. The client generates the random session secret `K_s`. This can
  be, for instance, 32 bytes of cryptographically secure random data. The
  client then encrypts `K_s` using the phi-ns-x transform under the
  provided state and parameters:
      * The client takes the plaintext m = an encoding of `K_s` (if `K_s`
  is 256 bits, interpret it as a number modulo M; if its larger, it might



  Nsiangani                Expires 13 August 2026                [Page 27]


  Internet-Draft                ASL Protocol                 February 2026


  be split across multiple messages or handled by chunking).
      * The client uses the round state provided (`u_0, a_0`). Let's call
  this round "handshake round" or round 0. It will apply the recurrence
  Eq3 and Eq4 (and Eq5 if doors are used) L_h times, where L_h might be
  fixed or chosen by servers profile. The output will be X_secret.
      * If PK-p mode is used and the server supplied auxiliary parameters
  like star projections, the client will incorporate them as specified.
  For example, if a door value b_i is derived from a star factor and the
  server gave a list of star projections, the client might not know which
  to use. However, the safest approach for handshake is not to require the
  client to guess any secret injection. So the server could specify that
  for the handshake round, no injection is used (or a fixed simple
  pattern) just to convey the secret. Alternatively, the server could
  supply an explicit hint: e.g., an index or one of the star projection
  values that the client should use for encryption in this handshake. To
  keep things straightforward, assume that the handshake uses a profile
  with no injection (or the server picks parameters such that b_i=0 for
  this round). The primary goal is to get `K_s` across.
      * The client sends **ClientEncryptedSecret** = X_secret (the
  ciphertext). Additionally, the client may send computed verification
  data:
        - It can compute a hash or MAC of the handshake messages
  (ClientHello + ServerHello + X_secret) using `K_s` and include this as
  well (similar to how TLS's Finished message is a MAC over all prior
  handshake messages using the new keys). This serves as a strong
  confirmation that the handshake hasn't been tampered with. This can be
  done by, say, taking `HMAC(K_s, handshake_transcript)` or a
  straightforward hash since we want to minimize external primitives. If
  we avoid hash functions entirely, we could use phi-ns-x itself in a
  specialized way to produce a tag (e.g., encrypting a constant with a
  known pattern using `K_s` as input could produce a tag). But including a
  small SHA-256 here purely as a handshake integrity check is not against
  the spirit of ASL, since it's not used for core security, but let's
  assume we want to avoid even that. Another way is: The server, when it
  decrypts `K_s`, could produce a known response that implicitly confirms
  the handshake integrity.
        - To keep the initial specification free of additional primitives,
  we will proceed without an explicit Finished MAC, but note that this is
  a point where a profile could add one for enhanced security.

  - **ServerFinish (Handshake Completion)**: Once the server receives the
  ClientEncryptedSecret, it attempts to decrypt it:
    - The server knows p (or q in PK-q mode) and the full secret key, so
  it can run the inverse of phi-ns-x on X_secret using the same round
  state (u_0, a_0) and (if applicable) the known door values. This yields
  a candidate plaintext which should be `K_s`.
    - If the server fails to decrypt properly (e.g., because the attacker
  tampered with X_secret or it was encrypted under wrong assumptions), the



  Nsiangani                Expires 13 August 2026                [Page 28]


  Internet-Draft                ASL Protocol                 February 2026


  result will be gibberish. The server can detect failure perhaps by
  format (if `K_s` has some structure or length). If decryption fails, the
  server MUST abort the connection.
    - If decryption succeeds and yields a plausible `K_s`, the server now
  has the shared session secret.
    - At this point, both sides have `K_s`. They can derive from it the
  internal parameters needed for the ongoing encrypted session. A simple
  derivation could be:
      * step_u = H1(K_s, client_random, server_random) mod (some range)
  where H1 is a hash or KDF function. But again, to avoid hash, they might
  directly treat `K_s` bits as comprising these values. For example, split
  `K_s` into two halves: first half as step_u, second half as step_star
  (just as bits of an integer). If `K_s` is uniformly random, each half is
  random. Or derive rot0 from a subset of bits, etc. The exact method
  should be agreed: the point is, `K_s` is now the master secret for the
  session from which all needed shared secrets are determined.
      * For instance: interpret `K_s` as a 256-bit number. Break it into:
  step_u (e.g., 128-bit), step_star (64-bit), rot0 (16-bit), and an
  authentication token (48-bit)  these bit lengths are arbitrary examples.
  The values may be reduced modulo appropriate ranges (like if step_u must
  be taken mod (M-1) maybe, since it might effectively act as an
  exponent).
      * Both client and server do the same derivation, so they have
  identical parameters.
    - The server should now send a final confirmation. If we had not
  included a Finished MAC from client, the server will include something
  to assure the client that it too derived the same keys and that the
  handshake wasn't tampered with. The simplest way:
      * The server sends a **ServerFinish** message encrypted with the
  newly established session keys. For example, the server can compose a
  message "HS_DONE" (handshake done indicator) and encrypt it as the first
  ASL data round (round 1).
      * Concretely, server sets round=1, computes new u_1 from u_0 (with
  secret step_u), computes a_1, encrypts a known ASCII string or
  structured data (like a constant or perhaps the handshake transcript
  hash) using phi-ns-x with L layers under a_1 (and door values etc. now
  known to both from K_s), producing X_verify, and sends it along with
  u_1, a_1.
      * The client, upon receiving this, will decrypt using its copy of
  the secrets. If the plaintext matches the expected value (e.g.,
  "HS_DONE" or matches a hash of handshake messages), then the client
  knows the server was indeed present in the handshake and that the shared
  secrets match. At this point the handshake is complete and the channel
  is secure and authenticated.
      * If the decryption fails or the value is incorrect, the client must
  terminate the session because it indicates something went wrong (keys
  mismatch or MITM).
    - If we wanted to avoid even one round trip for finish, the clients



  Nsiangani                Expires 13 August 2026                [Page 29]


  Internet-Draft                ASL Protocol                 February 2026


  previous message could have included something that server would echo
  back. But it's cleaner and more symmetric to have this final step.

  - After these exchanges, the handshake is complete. The protocol
  transitions to the data transfer phase.

  **Summary of Handshake Flow**:
  Client -> Server: ClientHello (random_C, cipher_suites, maybe
  client_ephemeral_pub)
  Server -> Client: ServerHello (p_public or q_public, M, g, q^2_masked,
  u_0, [q_anchor, stars...], random_S)
  Client -> Server: ClientEncryptedSecret (X_secret = Enc(m=K_s), maybe
  Finished MAC)
  Server -> Client: ServerFinish (Encrypted confirmation with round 1
  state)
  (Messages could be combined or split differently in implementations, but
  this is the logical content.)

  Throughout this process, no out-of-band trust is needed except that the
  client must have an authentic reference for
  the server's identity (particularly the expected q^2_masked or the
  servers public key itself). This could be obtained
  via a one-time secure channel or a trusted directory. If that is not
  available (trust on first use scenario), the
  protocol still encrypts the traffic, but a MITM could impersonate the
  server on the first connection. However, because
  q^2_masked would change if they later see the real server's key, a
  client could detect it on subsequent connections
  (similar to SSH's known host keys). This is a deployment consideration.

  For clarity, let's tie back to the earlier blockchain example terms:
  - `p_public` in handshake corresponds to that p_public.
  - `q_anchor` and `q^2_masked` were given in "genesis" in that example;
  here ServerHello carries them.
  - The shared off-chain secrets like step_u, step_star, rot0 are
  essentially derived from K_s in our handshake.
  - The round state (u_k, a_k) in each transaction corresponds to our per-
  message state below.

  4.3. Round-Based Encrypted Messages

  Once the handshake has completed, client and server enter the secure
  data phase. The key aspect of ASL's data encryption
  is that it is stateful: each message is tied to a round index and the
  public state (u_k, a_k) for that round.

  The participants now share:
  - The secret trajectory parameters: step_u, step_star, etc., derived



  Nsiangani                Expires 13 August 2026                [Page 30]


  Internet-Draft                ASL Protocol                 February 2026


  from K_s.
  - The starting state: let's call it (u_1, a_1) which should have been
  either provided in the ServerFinish or computed
    by each side. Actually, in the handshake above, the server already
  sent u_0 for the handshake encryption. After using
    u_0, both sides can compute u_1 = u_0 * g^step_u (mod M). If the
  server already did this and sent something with u_1,
    then the client upon verifying ServerFinish knows u_1 and a_1.
    Alternatively, some might prefer that the server doesnt send u_1 but
  that both sides compute it independently from
    u_0 and step_u. However, if any message was lost or if one side
  increments and the other doesn't, there could be desync.
    Its safer to include u_k in each message to avoid synchronization
  issues. This is slightly less efficient (sends some
    extra bytes), but ensures robustness.
  - The internal secret factors scheduling (like the sequence of door
  values b_i if used, or star usage pattern): these are
    agreed or known from handshake secrets.

  Data is sent in **records** or **messages**. Each record is self-
  contained in the sense that it carries the information
  needed for the receiver to process it (or the receiver can derive that
  info if in sync).

  For each message the following occurs (assuming a message is one
  protocol data unit to be encrypted and sent; if a
  higher-level application message is large, it could be fragmented into
  multiple ASL messages, each with its own round):
  1. The sender (could be client or server) determines the next round
  number and computes/obtains the corresponding
     state (u_k, a_k).
     - If the sender was the one who sent the last message (i.e., we might
  not alternate; consider an HTTP response with
       multiple packets), then the sender would have already incremented
  the state internally after sending. Typically,
       we can define that every message increments the round number by 1,
  regardless of who sends it. This means both
       sides advance a shared counter even on their own send. That is
  unusual (because normally each side would increment
       their own sequence), but since state is shared, it is more like an
  alternating sequence in lockstep.
     - Another approach: maintain two independent sequences, one for each
  direction (like TLS has independent sequence
       numbers per direction). We could do that: a client_send_state and
  server_send_state each with their own step parameters.
       That would require deriving separate step_u_client and
  step_u_server from K_s. This might be more elegant to avoid
       issues of one side not sending for a while and the other wanting to



  Nsiangani                Expires 13 August 2026                [Page 31]


  Internet-Draft                ASL Protocol                 February 2026


  send many messages (like a server pushing data
       unidirectionally). Yes, it's probably practical to have separate
  state threads so that one side sending many messages
       doesn't starve the sequence for the other.
     - Let's assume we have separate sequences: one keyed for client
  transmissions, one for server transmissions. In that
       case, we derive step_u_C and step_u_S from K_s. The initial u_C1
  and u_S1 can both start at some common value or be
       derived differently (maybe the server provided u_1 in handshake
  which was for first server message, and for client
       initial state maybe the client picks or both could use same u but
  different step yields divergence).
     - To avoid complicating, though, we can also stick to a single
  sequence used by both: in a request-response scenario
       it naturally alternates. But consider asynchronous messaging, a
  single sequence is simpler because it globally orders
       messages. This is akin to a half-duplex or synchronized full-duplex
  channel. There is a risk if both try to send at
       the exact same round number simultaneously. That could be resolved
  by one of them detecting a collision and adjusting
       (e.g., if two messages come with same round from both sides, the
  higher party ID wins and the other can resend with
       increment). This is too complex; separate sequences is easier for
  practicality.
     - For specification clarity, let's define:
       * Each side maintains a send sequence (with its own u_k evolving
  via step_u known to that side).
       * Actually, step_u is shared, so if both used it they'd produce the
  same u sequence which is not what we want if
         they are sending concurrently because they'd collide. If we want
  separate, we could have step_u_C = step_u (from K_s)
         and step_u_S = -step_u or another independent value. Perhaps we
  could derive two seeds from K_s so that one
         sequence might use g^step_u, the other uses g^step_u2 or maybe
  g^(-step_u) to differentiate.
       * For simplicity in this version, we assume a synchronous
  communication: client sends a request (round 1), server
         responds (round 2), client next (round 3), etc. This fits
  scenarios like request-response or blockchain where
         transactions are sequential by design. If a use case needs
  simultaneous asynchronous sending, the protocol can
         be extended to label messages with which sequence they belong to
  (C or S) and each with its own state update rule.

  2. The sender prepares the plaintext for encryption:
     - This plaintext could be a JSON, a binary blob, etc. It may be
  necessary to encode a length or ensure it's smaller
       than M. Usually M would be chosen large enough to send a reasonable



  Nsiangani                Expires 13 August 2026                [Page 32]


  Internet-Draft                ASL Protocol                 February 2026


  chunk or a symmetric cipher key. But for streaming,
       if data is larger than M can handle at once, one would chunk it.
  ASL can either treat each chunk as an independent
       message or incorporate a chaining at the phi-ns-x level (the latter
  is not typical; easier to chunk).
     - If needed, the plaintext is padded to a certain length (maybe to
  nearest multiple of some bytes) to avoid leaking
       exact lengths. But that's application specific. Not mandated here,
  though adding padding for security (to not reveal
       message length patterns) is recommended.

  3. The sender encrypts using phi-ns-x:
     - They know the current rounds a_k. They set p_0 = plaintext
  (converted to int mod M by some agreed reversible scheme,
       e.g., big-endian byte interpretation).
     - They run the recurrence for L layers (in normal data, L might be
  set to a value possibly different from handshake L).
     - If door values (b_i) are being used for data encryption, the sender
  applies them as per Eq5. Both sides know the sequence
       of b_i to use. If b_i sequence is static for all rounds, fine.
  Possibly, the b_i sequence could actually depend on the
       round number, e.g., using different segments of the star list for
  different rounds. That could be orchestrated by using
       rot0 and step_star: e.g., at round k, start injecting factors from
  index = (rot0 + k*step_star) mod N. This is a plausible
       design. It means each round's multi-layer encryption uses a
  different subset of Rs factors, making patterns between rounds
       even less correlated.
     - After computing X = p_L, the sender may apply final masking if the
  profile calls for it. However, typically for sending
       data, we might choose to not use an additional mask (or if we do,
  both sides must know how to remove it). If something like
       Eq6 was used, the receiver would need to know it and apply inverse.
  For now, assume the ciphertext is X (mod M).

  4. The sender transmits the message which includes:
     - The round identifier (k). If we strictly alternate, k might be
  implicit (each side expects the next number). In unpredictable
       async, better to include it explicitly.
     - The public state values for that round: u_k and/or a_k. (One of
  these could be derived from the other. Possibly sending only
       u_k is enough since a_k can be recomputed. But sending both could
  be a nice integrity check: since a_k = (u_k + inv(u_k))*inv2 mod M,
       the receiver can recompute and verify the given a_k matches given
  u_k. This could catch any corruption or tampering in transit.
       An attacker who tries to change u_k would also have to adjust a_k
  consistently to avoid detection.)
     - The ciphertext X (or C if masked form).



  Nsiangani                Expires 13 August 2026                [Page 33]


  Internet-Draft                ASL Protocol                 February 2026


     - Any additional metadata, e.g., a flag for last message, or an
  application-level content type if needed (like TLS records have type).

  5. The receiver on receiving a message:
     - Checks the round number (if out-of-order or repeats, might indicate
  replay or loss).
     - Verifies the state consistency: e.g., if a_k is provided, check a_k
  ?= (u_k + inv(u_k))*inv2 mod M. If it doesn't match, the message
       is invalid and should be dropped.
     - If the protocol expects sequential rounds and the round number is
  not the expected next (and not yet seen), it might indicate either
       reordering or an attack. Depending on design, might queue out-of-
  order or just close connection due to suspicion.
     - Using the locally stored secrets:
       * The receiver knows step_u (or two if separate directions, then
  picks appropriate one).
       * If the receiver has been computing states on its own (for its
  sending), it might also compute what u_k should be for the peer's
  message if in sync.
         If they are using separate sequences, the receiver can compute
  expected u for a given round if it knows how the other side's step
  works. Actually, if
         separate, maybe the receiver isn't computing the other side's
  states on its own, instead it relies on what's in the message. And then
  it updates some
         record of "last seen u from that side".
       * In either case, since u_k is included, the receiver doesn't
  strictly need to pre-compute it, but it can verify the progression if it
  has memory of
         previous u from that sender. For example, if last server message
  had u_x, the client can verify that u_k = u_x * g^{step_u_S}^{(k-x)} mod
  M (i.e.,
         check it fits the expected sequence progression). If not, either
  messages were lost or altered. If lost, maybe we can still accept if
  within a window
         and adjust? But let's not complicate; ideally no loss or the
  protocol might drop out-of-sync.
     - The receiver then computes a_k from u_k (if not already given or to
  cross-check).
     - It sets up the decryption recurrence. Now, decryption of phi-ns-x
  is not simply running the inverse function easily because we don't have
  a straightforward
       algebraic inverse. But the receiver has the secret p and possibly
  other private key info. They need to solve p_L = X for p_0.
       * One approach: Because the legitimate receiver has full knowledge
  of p (the secret prime) and the internal structure, it could simulate
  the encryption
         forward to see if it matches X, but that would require guess of



  Nsiangani                Expires 13 August 2026                [Page 34]


  Internet-Draft                ASL Protocol                 February 2026


  plaintext. Instead, likely the receiver uses a more direct method. For
  phi-ns-x, given
         X = p_L, one can iterate backwards:
           - There is a relation linking p_L and p_{L-1}: from Eq4
  rearranged, knowing p_L (and therefore presumably knowing y_L since y_L
  = something with p_{L-1}),
             it's tricky to go backward directly without knowing p_{L-1}.
  However, in the context of the full key, the secret prime p might allow
  computing some
             invariant that helps invert layer by layer. This part is
  complex; presumably, the design of phi-ns-x ensures decryptability by an
  algorithm that leverages
             p and abR. For example, there might be a way to detect the
  correct y_i at each step by using the fact that the output must align
  with the prime's identity
             structure (something like p_i must be a quadratic residue
  related to p or q in a known way).
           - In any case, since phi-ns-x was introduced as an "encryption"
  transform with the statement that decryptor possesses p and trajectory
  parameters to decrypt,
             we trust that a decryption algorithm exists. Perhaps the
  decryptor tries all possible factors as candidate b_i inverses if door
  used, etc. Or maybe since it
             knows q, it can compute what y_i should be: e.g., maybe q
  acts like an eigen or fixed point parameter such that at final layer L,
  (X + q*a_k)^? yields something
             that reveals p_{L-1}. Hypothetically, if we plug p_i = q
  (just thinking), then Eq4 would simplify. Actually, maybe the trick: The
  server can test candidates
             for p_{L-1} by solving the quadratic equation given p_L and
  known a_k and known b_L if any. That quadratic is:
             `p_L * y_L  y_L^2 - y_L + p_{L-1}*a_k - b_L (if b used)`
  which is essentially `p_L * (p_{L-1}+a_k)  (p_{L-1}+a_k)^2 -
  (p_{L-1}+a_k) + p_{L-1}*a_k - b_L`.
             This can be rearranged to a polynomial in p_{L-1}. Likely a
  quadratic in p_{L-1} as well. The decryptor can solve that quadratic
  (which might have 0,1, or 2 solutions mod M).
             One of those solutions should be the correct p_{L-1}. How to
  choose the right one? Possibly because only one will continue to yield a
  valid plaintext in subsequent backward steps or
             within range of message size. Then it can continue
  iteratively. This is plausible as a decryption method.
       * We do not need to detail the algorithm in the specification; it's
  enough to state that the receiver uses its private key to invert the
  phi-ns-x layers and recover plaintext.
         This may involve brute-forcing a small number of possibilities at
  each layer (since the equation to invert is quadratic, at most 2
  solutions, maybe more with door values considered,



  Nsiangani                Expires 13 August 2026                [Page 35]


  Internet-Draft                ASL Protocol                 February 2026


         but if star injection made ambiguous, the correct combination
  must be found).
       * We guarantee that given the design of abR and injection, the
  correct plaintext yields a coherent solution chain that matches the
  private key structure, whereas a wrong guess quickly
         leads to a contradiction (like an impossible factor or mismatched
  q^2 when check against q).
     - After obtaining p_0 (plaintext as an integer), the receiver
  converts it back to the original message format (removing padding if
  added).
     - The receiver then uses the plaintext or passes it up to the
  application.

  6. State update: After processing a message, both sender and receiver
  update their expected state for that sequence:
     - If using one global sequence, they both increment the round
  counter.
     - If separate, the sender obviously updated its own state when
  sending. The receiver upon successfully decrypting might recompute what
  the next expected u for that sender would be (though it can also just
  wait to receive it in the next message).
     - Additionally, if star rotation is used across rounds, both sides
  update the star index (e.g., star_idx = star_idx0 + round * step_star
  mod N, or some such formula), so that the next message will use a
  different starting point in the star list for door values.

  Notably, there is no separate "MAC" in each record as one would see in
  TLS (prior to TLS 1.3) because the encryption itself combined with state
  verification suffices. If an attacker modifies bits in the ciphertext X,
  the probability it decrypts to something valid (like meaningful
  plaintext with correct structure) is negligible; even if it did, the
  protocol's state check (u_k and a_k sequence) would likely fail or the
  content would be nonsense to the application and could be detected with
  application-level sanity checks. The inclusion of state values provides
  an implicit integrity check: an attacker cannot easily alter X without
  also altering a_k and u_k in a consistent way, which would require
  breaking the encryption anyway.

  In practice, an implementation might still want to include an explicit
  checksum or MAC over the ciphertext and perhaps part of the header (u_k,
  a_k) using the session symmetric secrets, to guard against any
  theoretical weaknesses in the transform as an authenticity mechanism.
  However, we leave this as optional, given the design goals.

  4.4. Message Formats and Encoding

  We now specify the format of the handshake and data messages in a more
  concrete manner. These formats are described conceptually;



  Nsiangani                Expires 13 August 2026                [Page 36]


  Internet-Draft                ASL Protocol                 February 2026


  actual implementations may serialize fields in network byte order, etc.
  We assume a transport where messages can be delineated
  (e.g., a TCP stream with length prefixes or a datagram protocol with
  message boundaries).

  **ClientHello Message:**
  struct {
  uint8 protocol_version_major;
  uint8 protocol_version_minor;
  uint16 cipher_suites_supported;   // e.g., a bitmask or ID indicating
  profile support
  opaque client_random[32];        // 256-bit random nonce
  // Optional fields
  uint8 have_ephemeral_key;        // 0 or 1
  if (have_ephemeral_key == 1) {
  uint16 ephemeral_key_length;
  opaque client_ephemeral_key[ephemeral_key_length];  // e.g., a
  serialized phi-ns public key or other
  opaque client_ephemeral_commitment[??];            // maybe a q^2_masked
  for the clients ephemeral q, if needed
  }
  } ClientHello;
  This is an example. In many cases, cipher_suites_supported might just be
  a single profile ID if ASL is simple (for instance, 0 = base, 1 =
  withDoors, 2 = PK-p mode only, etc.). The client_random ensures the
  handshake has entropy from client side as well.

  **ServerHello (ServerParams) Message:**
  struct {
  uint8 protocol_version_major;
  uint8 protocol_version_minor;
  uint16 cipher_suite_chosen;
  opaque server_random[32];
  uint8 key_mode;     // 0 = PK-q (server public = q), 1 = PK-p (server
  public = p)
  opaque server_public_key<1..+>; // If key_mode=0, this contains q (big-
  endian integer). If key_mode=1, contains p.
  opaque q2_masked_value<...>;       // A fixed-length encoding of
  q^2_masked. For example, same length as M or other standard (must be
  defined by profile).
  uint16 modulus_length;
  opaque modulus_M[modulus_length];
  opaque generator_g[modulus_length];  // same length as modulus to hold
  value
  opaque initial_u[modulus_length];
  // if key_mode = 1 (PK-p), include auxiliary data for q hiding:
  if (key_mode == 1) {
  opaque q_anchor[modulus_length];   // possibly q mod M or some



  Nsiangani                Expires 13 August 2026                [Page 37]


  Internet-Draft                ASL Protocol                 February 2026


  representative
  uint16 star_count;
  opaque star_projections[star_count][modulus_length]; // array of
  star_count elements, each modulus_length bytes
  // (star_count could be implicitly determined from length too)
  }
  } ServerHello;
  Note: We treat p, q, M, g, u as big-endian byte arrays with a known
  length (modulus_length could be, e.g., 32 bytes for a 256-bit prime M).
  The star_projections array is an example of optional data; its content
  and use must be specified by the profile (the client needs to know what
  to do with them, which might be documented in an application profile
  spec rather than the core).

  **ClientEncryptedSecret Message:**
  struct {
  opaque encrypted_secret_value<1..+>;  // The ciphertext X (or C) from
  encrypting the clients secret.
  // Optionally:
  opaque handshake_verify_tag[32];       // e.g., a 256-bit tag for
  handshake verification (if implemented).
  } ClientEncryptedSecret;
  The encrypted_secret_value length should equal the length of modulus M
  (as ciphertext is an element of Z_M). If the secret is slightly bigger
  than M bits, multiple such structures could be sent or it could be
  split, but typically we'll choose M to be big enough.

  **ServerFinish Message:**
  struct {
  opaque next_u[modulus_length];
  opaque next_a[modulus_length];
  opaque verification_ciphertext[modulus_length];
  } ServerFinish;
  In this, next_u and next_a are state for round 1 (if not already known;
  if we assume handshake round was 0, then round 1 is first data round
  possibly carrying this verification). The verification_ciphertext is the
  encryption of a known value (like all zeroes or some hash of transcript)
  using round 1's state. The client will decrypt it and check. If separate
  sequences are used, then perhaps the server's finish would use server's
  sending state sequence's first value. But let's not digress; the format
  stands.

  After the handshake:
  **Data Message Format (general for any subsequent round):**
  struct {
  uint32 round_number;
  opaque u_value[modulus_length];
  // a_value might be omitted if receiver can compute it:



  Nsiangani                Expires 13 August 2026                [Page 38]


  Internet-Draft                ASL Protocol                 February 2026


  // but including for completeness
  opaque a_value[modulus_length];
  uint16 ciphertext_length;
  opaque ciphertext[ciphertext_length];
  } ASLRecord;
  Here, `ciphertext_length` might equal `modulus_length` if a single
  field, or could be a multiple if the plaintext was chunked into multiple
  modulus-size blocks (like if plaintext is very large, one might do
  multiple phi-ns-x transforms sequentially or in parallelthough more
  likely you'd just send multiple records).

  If we treat each message to be max one modulus worth of data,
  ciphertext_length can be fixed to modulus_length except possibly the
  last block of a file transfer (but since phi-ns-x isn't a streaming
  cipher, better to break each application message separately).

  The `round_number` is 32-bit allowing for a large number of messages. In
  some contexts (like blockchain), the round might correspond to a block
  or tx number.

  All multi-byte fields are in network byte order (big-endian) by
  convention.

  For encoding integers (like p, q, M, u, a):
  - They should be in big-endian byte arrays of a fixed length (preferably
  the length of M for consistency, padded with leading zeros if needed).
  - The prime p or q in server_public_key can be shorter than M (e.g., if
  p is 160 bits and M is 256 bits). In that case it can be left-padded
  with zeros to some fixed length or encoded with a length prefix. Above
  we allow it to be a variable length field with a prefix for length
  (`server_public_key<1..+>` means a variable-length vector as per TLS
  syntax).

  Notably, these structures closely mirror TLS handshake messages albeit
  simpler since there's no certificate chain, no separate signature (the
  encrypted secret and q^2_masked serve that purpose).

  The protocol's normative requirements:
  - The client and server MUST verify each other's values as described
  (e.g., q^2_masked and handshake decrypt).
  - If any verification fails or an unexpected message is received, the
  implementation MUST abort the connection.
  - All numeric fields are unsigned and non-negative.
  - The primes p and q in the key must satisfy all conditions from section
  3 (e.g., T composite, etc.) otherwise the protocol's security
  assumptions break.

  Finally, it's possible to compress some messages in an optimized



  Nsiangani                Expires 13 August 2026                [Page 39]


  Internet-Draft                ASL Protocol                 February 2026


  implementation:
  - For example, if the cipher suite is fixed and known, ClientHello could
  be omitted and the server could start first (like in some PSK modes).
  But the full handshake as described is the default.

  With the message formats defined, an implementation can
  marshal/unmarshal these structures and perform the cryptographic
  operations accordingly. This textual specification should be sufficient
  to guide interoperable implementations.

  5. Example Use Cases

  In this section, we discuss how ASL can be applied in various scenarios,
  highlighting the benefits and any special considerations for each.

  5.1. HTTPS Without TLS (Web Security)

  ASL can be used as a drop-in replacement for TLS to secure HTTP
  connections (hence "HTTPS without TLS"). In this use case, a web server
  would have an ASL server key (Phi-Ns based) instead of an X.509
  certificate with an RSA/ECDSA key. The browser (client) would either
  have the server's public key (p or q and q^2_masked) pre-loaded (through
  some out-of-band means like DNS records, .well-known endpoints, or built
  into the application) or would use a trust-on-first-use approach
  (similar to how SSH handles host keys).

  **Establishment**: When the browser connects to the server, it performs
  the ASL handshake:
  - The server proves its identity by its ability to decrypt the
  ClientEncryptedSecret and by having a q^2_masked matching a published
  value. No certificate chain is needed; the trust is directly in the
  server's public key. This simplifies the handshake (fewer round trips
  than a full TLS handshake with certificate verification) and avoids
  reliance on certificate authorities.
  - The handshake, as designed, can be as low as 2 round trips
  (ClientHello -> ServerHello -> ClientSecret -> ServerFinish), similar to
  TLS 1.2 with no client auth. With some optimization (or early data
  concept), it could even be reduced, but let's assume 2 RT for fairness
  with TLS 1.3 which uses 1 RT but needs certificate in that RT.

  **During Data Transfer**: The HTTP requests and responses are sent
  encrypted as ASL records:
  - The client would send a GET request as plaintext into an ASLRecord
  payload. The server decrypts it, processes it, and sends back the
  response in one or more ASLRecords.
  - The stateful nature of ASL means each request/response increment the
  state. In HTTP (which is mostly request-response sequential on a given
  connection, at least in HTTP/1.1 or HTTP/2 streams), this aligns well.



  Nsiangani                Expires 13 August 2026                [Page 40]


  Internet-Draft                ASL Protocol                 February 2026


  Each HTTP message corresponds to one or more ASL rounds. If pipelining
  or multiplexing (like HTTP/2), separate logical streams could either use
  separate ASL sequences or be serialized within one sequence - a
  multiplexer would handle ordering. Simpler approach: one ASL session per
  HTTP/2 stream to avoid head-of-line blocking; but that might be
  overkill. It's easier to treat the whole connection as one sequence and
  trust ordering at transport.

  **Benefits**:
  - No reliance on specific cryptosystems that might be broken by quantum
  computers (RSA/ECDH). ASL is built on a new assumption believed to be
  quantum-resistant.
  - Compact public keys: A Phi-Ns key with, say, 192-bit p and q plus
  structure can be far smaller than an RSA 2048-bit modulus. It could be
  comparable in size to ECC keys, but with PQ security.
  - The handshake does not transmit certificates, meaning less data
  transferred (helpful for IoT or constrained networks), and avoids the
  need for verifying certificate chains (saving computational cost on
  clients).
  - Privacy: Because no certificates are sent, there's less risk of an
  eavesdropper collecting certificate info to track servers. The server's
  public key might be well-known via other means, but at least it's not
  transmitting a whole identity chain every time.
  - Implicit authentication: If the public key is obtained through DNSSEC
  or some secure channel, the user agent can authenticate the site
  similarly to how it would with a certificate.

  **Considerations**:
  - Bootstrapping trust: Without the CA system, how does the client know
  the server's key is legitimate? This could be solved by a one-time CA-
  like attestation (maybe the domain publishes its ASL key in a
  certificate-like format signed by a CA, or uses DANE via DNSSEC). This
  is a deployment rather than protocol issue.
  - Performance: The encryption and decryption operations (involving
  modular arithmetic and possibly searching through quadratic solutions)
  must be efficient. For web traffic, throughput is important. Profile M
  or L from Phi-Ns is appropriate (128-256 bit primes, recursion if
  needed). Those should be efficient on modern CPUs. Preliminary estimates
  show Phi-Ns operations can be done in microseconds, comparable to RSA or
  DH in many cases, but this should be validated.
  - Session resumption: As with TLS, one might want to resume a session
  without full handshake (to avoid repeating heavy ops). ASL could
  implement resumption by having the server issue a session ticket
  (encrypted blob containing the shared secrets or a reference) that the
  client can present next time. Since ASL is symmetric once established,
  resumption is straightforward: it's essentially storing step_u and
  current state etc. Implementation of session resumption is an added
  layer; the base protocol doesnt preclude it.



  Nsiangani                Expires 13 August 2026                [Page 41]


  Internet-Draft                ASL Protocol                 February 2026


  Overall, ASL could provide a secure channel for HTTPS traffic with
  potentially simpler mechanics and post-quantum security built-in. The
  normative behavior in this use case is exactly as described by the
  protocol; the main difference is in how keys are distributed and
  managed.

  5.2. Blockchain Transactions

  In some blockchain systems (particularly permissioned or consortium
  chains), there is a need to encrypt transaction payloads on-chain such
  that only authorized participants can read them, while others can still
  validate some aspects (like knowing it was a valid encryption under a
  known key and state).

  ASL can be adapted to this scenario, as was partially demonstrated in
  the "Rapport" simulation:
  - The blockchain network can have a static public key associated with
  the chain or with each participant. For example, each participant (node)
  might have an ASL key pair. If a transaction is intended for a specific
  group, those members share an ASL channel (with shared secret).
  - The "Genesis block" or chain configuration would publish relevant
  parameters: M, g, and perhaps a common key if one key pair is used
  system-wide for encryption (or each participant's public keys if
  multiple).
  - In the simulation, they had: `Genesis publishes M, g, p_public,
  q_anchor, q2_masked + star projections`. This is essentially the network
  announcing, "here's the public key (p_public) and associated data you'll
  need to encrypt transactions to us; trust is established by q2_masked
  etc."
  - Each transaction included `(u_k, a_k, C_final)`:
    * `u_k, a_k` correspond to the public state of that round of
  encryption.
    * `C_final` is the ciphertext (potentially using an Eq6-like
  projection as shown: `C_final = (X + q)^2 - T * a_k^2` in their logs).
  - Miners/validators who are not privy to the secret cannot decrypt the
  payload, but they can verify that the transaction is well-formed in
  terms of state linkage:
    * They can check that the `u_k, a_k` values are correctly derived (a_k
  = (u_k + inv(u_k))/2 mod M, which anyone can do).
    * They can check that `u_k, a_k` follow the previous state's
  progression if the chain enforces an order (the logs show each tx had a
  round number and they likely ensured u_{k} was derived from u_{k-1} by
  the shared step).
    * They can store the new state (so that the next transaction from that
  channel can be verified against it).
    * If `C_final` uses a construction like Eq6, perhaps the validators
  can verify that for the given `C_final` and known public values
  (q^2_masked might help here), there's a consistency: actually, without



  Nsiangani                Expires 13 August 2026                [Page 42]


  Internet-Draft                ASL Protocol                 February 2026


  knowing T, they can't directly verify (X + q)^2 piece. But if they trust
  that any invalid ciphertext would not be producible without secrets,
  they might just assume a valid-looking state means it's fine.
  Alternatively, they might require the sender to later reveal plaintext
  and then verify by re-encrypting (commit-reveal scheme, which was
  mentioned in the notes).
  - The participants who hold the secret (the ones authorized to decrypt)
  will retrieve the transaction, use their private key to decrypt and read
  the message. They can later reveal the plaintext if needed for dispute
  resolution, and anyone can recompute `C_final` to confirm it matches (as
  shown by the log lines: they did a REVEAL verify by recomputing C_final
  from plaintext and it matched).

  ASL fits this because:
  - It provides a way to have evolving state (so you don't reuse the same
  key for every transaction, which is good for security and
  unlinkability).
  - Only those with secret (p, q, etc.) can create valid ciphertexts,
  which means unauthorized parties cannot forge a transaction that would
  be accepted into the chain (unless they somehow guess the correct state
  and produce a valid encryption by chance, which is astronomically
  unlikely). This gives implicit access control at the encryption level.
  - If a participant leaves or is to be excluded, the key can be rotated
  (generate new p, q or just re-randomize abR to effectively create a new
  key that yields a new q2_masked, etc.). Future transactions would then
  use the new key, and old ones remain encrypted under the old key which
  the leaving participant may still have, but new data they can't access.
  This is more of an operational procedure.

  For a public blockchain scenario where anyone can be a reader, ASL isn't
  needed because data is public. But for consortium where privacy is
  needed, ASL could run on top of the blockchain as an application layer
  or integrated with consensus so that only intended parties see content.

  One must also consider performance: blockchain blocks may contain many
  transactions, so encryption and decryption should be efficient. ASLs
  small key sizes and avoidance of heavy operations per message (just
  modular multiplications and one inversion per layer) are beneficial.
  Also, the on-chain footprint of each encrypted tx is just a few numbers
  (u, a, C) which are all reasonably small (the size of M, e.g., 32 bytes
  each for 256-bit security). That's much smaller than storing, say, an
  RSA encrypted blob of symmetric key plus the cipher.

  The demonstration logs correspond to an ASL channel where multiple
  parties (Alice, Bob, Carol) were sharing state (they all had the keys to
  update u and could each encrypt messages). That shows ASL supports
  multi-sender scenarios if they coordinate state (like in a group, you
  need to ensure only one uses a given round or they need to coordinate



  Nsiangani                Expires 13 August 2026                [Page 43]


  Internet-Draft                ASL Protocol                 February 2026


  incrementing state). Perhaps in that demo they all share step and doors,
  and they just pick next round sequentially when they send a message.

  In implementation, to avoid collisions, a group might require a leader
  to assign round numbers or have each include the round in transaction
  (which they did) and miners ensure no duplicates and order by that.

  **Benefits**:
  - **Confidentiality**: Sensitive transaction data (like financial
  details, private messages, etc. in a block) remain confidential to
  authorized parties. The chain still provides integrity and order.
  - **Authenticity**: Only someone with the groups shared secret can
  produce a valid ciphertext for the next state, preventing outsiders from
  injecting transactions that would later decrypt to something. It acts
  like a group signature in some way (only group members can "sign" valid
  ciphertexts).
  - **Post-quantum group security**: Many current blockchain privacy
  techniques use ECC (for addresses or for encryption in certain layer-2
  solutions). ASL offers a different hardness assumption which might be
  safer if ECC is compromised by quantum computers.

  **Considerations**:
  - Key distribution: Initially, how do group members get the secret key?
  That's outside ASL's scope (could be done in person, or using another
  secure channel).
  - State synchronization: In a distributed setting, ensuring everyone has
  the same current state is important. The blockchain itself helps because
  the latest block contains the last transaction and thus the last state
  (so even if a node was offline, by reading the chain they can catch up
  on u_k).
  - If the chain allows parallel channels (like multiple disjoint sets of
  participants each with their own state), each such channel would have
  its own ASL context identified by something like a channel ID, and state
  tracked per channel. This is achievable as well.

  5.3. Implicit Client Identity Authentication

  Traditional protocols often authenticate a client by an explicit
  credential (username/password, token, or client certificate). With ASL,
  especially in a closed ecosystem (corporate network, IoT deployment), a
  client's identity can be tied to possession of a secret key, and the
  handshake itself reveals which key (and thus which identity) is being
  used, without needing a separate authentication step.

  For example, consider an enterprise where each device or user is issued
  a unique ASL key pair (or at least a unique secret derived from a master
  key). The server (or gateway) maintains a list of authorized public keys
  (or their commitments). When a client initiates ASL:



  Nsiangani                Expires 13 August 2026                [Page 44]


  Internet-Draft                ASL Protocol                 February 2026


  - The client might include an identifier of which key it's using (or
  this could be implicit if the server can try each known public key to
  see which matches the q^2_masked provided, but it's easier if client
  sends an ID).
  - The server receives the handshake with, say, clients p_public and
  q^2_masked. If it finds a match in its database, it knows which client
  this is. It then proceeds to complete handshake and now all messages are
  encrypted.
  - If an attacker attempts to impersonate a client, they won't have the
  client's secret key, and thus cannot complete the handshake properly
  (they'd fail to decrypt or fail to prove knowledge of q by producing
  correct q^2_masked).
  - Thus, possession of the key is the identity proof. No password or
  token needed at session time.

  This "implicit identity" is analogous to how SSH key-based auth works:
  if you can produce the correct signature with your private key, you are
  that user. Here, if you can produce a valid handshake with the key, you
  are the authorized device.

  Another angle: Suppose the servers ASL key is public for all, but the
  shared secret derived in handshake is based on something the client
  knows. Actually, that is more like password-authenticated key exchange,
  which ASL by itself isn't doing. However, we could incorporate a client
  secret in handshake by having the clients encrypted message depend on a
  password somehow (e.g., plaintext includes a password that the server
  knows and can verify after decrypting K_s). But that is a custom
  protocol on top of ASL handshake, not inherent.

  Better to just give each client a key:
  - It could be a full Phi-Ns key pair or perhaps just a symmetric key
  pre-shared to derive something for handshake. For instance, the client
  and server could share a long-term secret and use that to generate the
  handshake's K_s (like a PSK mode). The client could encrypt something
  that includes evidence of the PSK. However, describing that fully is
  beyond scope; suffice to say ASL could be extended for PSK (pre-shared
  key) mode by mixing a known secret into K_s derivation or verifying a
  tag.

  In pure public-key mode:
  - The server might not want to store all clients' private keys
  obviously, it just stores their public half and maybe q^2_masked to
  verify integrity.
  - Each client effectively has a "certificate" by virtue of their public
  key being recognized. The difference is they don't need a separate
  signing step; the act of handshake doubles as the signing because only
  the real client could produce that encrypted pre-master secret that
  results in a meaningful shared key.



  Nsiangani                Expires 13 August 2026                [Page 45]


  Internet-Draft                ASL Protocol                 February 2026


  **Use cases**:
  - **IoT**: Each device has an ASL key burned in. The central server uses
  ASL to communicate, and it immediately knows which device it is talking
  to by the key. If a device is compromised, the admin can remove its
  public key from allowed list (revocation).
  - **VPN**: Users could authenticate to a VPN server by ASL key (instead
  of username/password). The connection establishment (like IKE or TLS in
  OpenVPN) could be replaced by ASL handshake using the user's key. If
  successful, the server associates that session with the user identity of
  that key. This is certificate-like but without X.509 overhead.
  - **Client certificates alternative**: In web, mutual TLS is rarely used
  because it's cumbersome. With ASL, if a client has a key, they can prove
  identity seamlessly as part of the handshake without complicated
  certificate UI. Of course, the client still needs to have the key pair
  available (maybe in OS keystore).

  **Security**:
  - The strength is that the client key is as hard to forge as breaking
  Phi-Ns. There's no online dictionary attack vector since there's no
  password, it's public-key crypto.
  - The server must protect its list of allowed keys and any mapping to
  user accounts.

  **Privacy**:
  - If clients present a persistent public key, that can be used to track
  them across sessions. In some contexts that's fine (enterprise), in
  others maybe not (web). There are ways to mitigate tracking by rotating
  keys or having the server assign ephemeral identities. But that's deeper
  into privacy design.
  - The handshake itself reveals which key (hence which client) is
  connecting (because p or q^2_masked is essentially an identifier). If
  anonymity is needed (like in some protocols), one might not want that.
  However, this is similar to client certificates anyway.

  5.4. Secure Messaging

  Consider an end-to-end encrypted messaging application (like a chat
  app). Typically, such apps use protocols like Signal, which involve
  Diffie-Hellman key exchanges, X3DH, double ratchets, etc., to ensure
  forward secrecy and authentication. ASL could serve as an alternative
  core for some of those steps, or even the entire session.

  Scenario:
  - Alice wants to send an encrypted message to Bob. She knows Bob's ASL
  public key (obtained from Bob's profile or directory).
  - They could perform an ASL handshake to establish a shared secret and
  then send messages. But if they are not online at the same time for a
  handshake, you could do an offline setup:



  Nsiangani                Expires 13 August 2026                [Page 46]


  Internet-Draft                ASL Protocol                 February 2026


    * Possibly one party can precompute a handshake message and the other
  completes it when they come online. This is tricky because ASL as
  described is interactive. But maybe Alice can send "ClientHello +
  ClientEncryptedSecret" to Bob (through the server) while Bob is offline.
  Bob when coming online can process it and send "ServerHello +
  ServerFinish"? The ordering would differ because normally server goes
  second. Alternatively, they'd just wait until both are online.
  - More straightforward, if asynchronous: treat each message as its own
  ASL "handshake+data" maybe, or use pre-shared static keys with ratchets
  on top.
  - However, if interactivity is allowed (both online concurrently, like
  voice call or live chat session), they can do a full ASL handshake
  directly peer-to-peer and then chat with messages as ASL records.

  In such a chat:
  - Both peers likely have devices with their key pairs (like each user
  has a long-term key).
  - Mutual authentication can occur by each verifying the other's
  q^2_masked through a fingerprint exchange (like scanning a QR code of
  the key fingerprint out-of-band, similar to how Signal verifies
  identities).
  - Once they have a session, each message is encrypted with evolving
  state. This inherently provides **forward secrecy** across messages: an
  attacker who compromises a key after some messages were sent cannot
  decrypt the earlier messages if those messages involved state that isn't
  reproducible from just the static key. Actually, careful: if an attacker
  gets p and abR, can they decrypt old messages? They still need the per-
  session shared secret K_s or at least the states. If those states were
  derived from K_s which was ephemeral and not stored, then yes, forward
  secrecy holds. So to ensure FS, one or both must contribute an ephemeral
  in handshake (like ephemeral Diffie-Hellman in TLS). ASL handshake as
  given uses the static server key and an ephemeral client secret K_s. But
  the static server key by itself means if server key is compromised, the
  handshake could be decrypted because the attacker can simulate it?
  Actually, they'd need the transcript. If someone logs all handshake
  messages and later the server key gets stolen, could they derive the
  session keys? Possibly yes, because with p, q they could decrypt
  ClientEncryptedSecret (X_secret). So without an ephemeral server key, a
  long-term key compromise does compromise past sessions. So strictly, the
  current ASL handshake is not forward-secret if the server's (or main key
  holder's) static key is compromised. Its like RSA TLS: break RSA key,
  you can decrypt old pre-master secrets.
  - So for messaging, they likely want forward secrecy. That can be
  achieved by having both parties use ephemeral keys in an ASL handshake
  (like I mentioned, each could generate an ephemeral phi-ns pair,
  exchange them in the handshake and derive secrets combined). Or simpler,
  just do a fresh handshake with ephemeral keys for each message or each
  session, but that might be too slow if frequent.



  Nsiangani                Expires 13 August 2026                [Page 47]


  Internet-Draft                ASL Protocol                 February 2026


  - Alternatively, ASL could be integrated into a double ratchet scheme:
  for each message, the state update acts like a ratchet step since it
  changes the keys. Provided that the state updates are not reversible
  without the prior key, then even if one message key is compromised,
  previous keys are safe. But if the static key is compromised, all might
  be at risk.
  - Possibly combine static identity keys (for authentication) and
  ephemeral session keys (for encryption). This is akin to how
  Axolotl/Signal does it: you have identity keys and ephemeral one-time
  keys. One could design an "X3ASL" handshake: exchange static keys
  signed, plus ephemeral keys in an ASL style.

  The details can get complex. The main point: ASL provides a structure
  that can do the heavy lifting of encryption with evolving keys, but one
  might still need to incorporate ephemeral keys for full perfect forward
  secrecy if desired.

  If forward secrecy is less a concern (say within a short live chat
  session), and key compromise is unlikely in real-time, ASL as is may be
  fine.

  **Benefits** for messaging:
  - Small messages overhead: each message only needs to carry a small
  state and ciphertext. Compare to, e.g., sending a whole new RSA-
  encrypted symmetric key per message (which some naive systems do), ASL
  is more efficient.
  - No need for additional MAC each message if relying on state.
  - The same library that does handshake sets up continuous encryption,
  simpler architecture.

  **Group chats**:
  - If multiple parties in a group chat, they can share one ASL channel
  (like the blockchain example, but now interactive).
  - Alternatively, pairwise channels or using group keys (beyond our
  scope).
  - ASL's design with hidden factors could be exploited in creative ways
  for group: e.g., each group member could hold a piece of R such that
  only if they cooperate can they decrypt? That's speculative and not
  standard ASL usage.

  5.5. Encrypted Tunneling (VPN)

  A VPN or any encrypted tunnel (like an IPsec replacement, or a simple
  point-to-point tunnel between networks) can use ASL to establish a
  secure link.

  Typically, IPsec has IKE for key exchange then uses symmetric ciphers
  for bulk data. TLS-based VPNs (like OpenVPN) do similar with TLS



  Nsiangani                Expires 13 August 2026                [Page 48]


  Internet-Draft                ASL Protocol                 February 2026


  handshake then symmetric cipher (AES) for data.

  With ASL, we can unify that: the handshake and the data encryption use
  the same primitives and keys:
  - The gateway and client perform an ASL handshake to authenticate (the
  gateway proves identity via q^2_masked, client perhaps via PSK or
  certificate equivalent).
  - They derive a shared secret and trajectory parameters.
  - Then they start forwarding IP packets or frames through the ASL
  channel. Each packet is encapsulated in an ASLRecord.
  - Because of stateful encryption, this looks similar to a stream cipher
  in usage: packets go in order. If out-of-order delivery is needed (like
  multiple parallel packet flows), one might consider independent channels
  for each or accept the sequential requirement (which might add latency
  if one packet is lost, subsequent can't be decrypted correctly until
  maybe that state is recovered or skipped).
  - Perhaps treat each packet independently by resetting state if you
  don't want head-of-line issues. But that loses the benefit of evolving
  state (though you could still do a quick re-handshake or treat each as
  separate message with small state changes).

  For a reliable transport or for link encryption where ordering is
  ensured, ASL is fine.

  **Post-quantum benefit**:
  - Many current VPNs would need to switch to PQ algorithms; ASL is a
  candidate with unique properties.
  - As a pure arithmetic algorithm, it might be easier to implement in
  embedded routers without special hardware (and not be subject to certain
  side-channel issues if careful, though side-channel protection would be
  needed as always).
  - The overhead per packet is just a few bytes plus the computational
  overhead which should be manageable (maybe on the order of a few hundred
  multiplications per packet, which on hardware can be optimized).

  **Integration**:
  - ASL could be a new protocol at either layer 4 (like a custom reliable
  protocol carrying encrypted data) or layer 2/3 (like how IPsec ESP
  works).
  - One could even embed ASL within existing protocols by using reserved
  bits (for example, encode u and a in an IP option header - not realistic
  publicly, but in a closed system who knows).

  **Security**:
  - MITM is prevented because the handshake authenticates the server (and
  possibly client). Attackers on the path cannot decrypt or inject because
  they can't predict the state or produce valid ciphertext.
  - Even if one packet is captured, without the key they can't glean



  Nsiangani                Expires 13 August 2026                [Page 49]


  Internet-Draft                ASL Protocol                 February 2026


  anything. And if one tries to replay a packet, the state will have moved
  on so the receiver would find the round number out of date and drop it,
  thus providing replay protection.

  **Comparison**:
  - Compared to IPsec's use of AES-GCM (which provides confidentiality and
  integrity with an IV and counter per packet), ASL provides a somewhat
  analogous function: the evolving state is like a counter/IV, but with
  secret evolution making it unpredictable to outsiders (whereas in AES-
  GCM the counter is usually not secret but just a nonce).
  - ASL inherently authenticates the data because forging requires the
  key. AES-GCM similarly prevents forgery due to the tag. ASL's approach
  might lack an explicit tag, but the non-linearity could serve similarly.
  Still, one might consider adding an explicit lightweight tag if
  paranoid.
  - Throughput: AES is faster with hardware support. ASL is software-
  based, but if its operations can be vectorized or offloaded (like
  modular multiplication can be done with big integer libraries, maybe not
  as fast as AES-NI instructions though). For moderate speeds (e.g., <1
  Gbps) ASL should be fine in software on modern CPUs. At very high
  speeds, one might explore hardware acceleration (maybe FPGAs could
  accelerate mod M operations, or a custom ASL co-processor).
  - The benefit is not needing separate systems for key exchange and
  encryption - it's unified.

  6.
  4.x Encryptor Operation and Knowledge Model

  This section specifies precisely the role, capabilities, and limitations
  of the encrypting party in the Authenticated Secured Layer protocol
  using
  Phi-NS.

  The encryptor does NOT possess the private root p, the value q, nor the
  quadratic gap T = q^2  p^2. The encryptor is not required to know any
  secret factorization, atom ordering, or private trajectory parameters.

  The encryptor operates exclusively on public, evolving state values.

  For each encryption round k, the encryptor is provided with a public
  state value u_k  Z_M*.

  From this public state, the phase value a_k is deterministically derived
  as:

      a_k = (u_k + u_k^{-1})  inv2 mod M

  where inv2 = 2^{-1} mod M.



  Nsiangani                Expires 13 August 2026                [Page 50]


  Internet-Draft                ASL Protocol                 February 2026


  The encryptor then applies the sequential Phi-NS transformation to the
  message.

  Let the plaintext message be represented as an integer m  Z_M.

  The encryption recurrence is defined as follows:

      p_0 = m

      For i = 1 ... L:

          y_i = (p_{i1} + a_k) mod M

          p_i =
              ((y_i^2  y_i + p_{i1}  a_k)  y_i^{-1}) mod M

  where y_i^{-1} denotes the modular inverse of y_i in Z_M.

  The ciphertext output of the encryption process is defined as:

      C = p_L

  Optionally, the ciphertext MAY be further bound to the quadratic
  structure by applying a quadratic projection, as defined elsewhere in
  this document.

  At no point does the encryptor require knowledge of p, q, T, or any
  private atom or star structure. The encryption process is entirely
  public and deterministic with respect to the public state u_k.

  The security of the scheme relies on the infeasibility of reconstructing
  the inverse trajectory without possession of the private parameters and
  the correct internal ordering of transformations.


  Security Considerations

  This section analyzes various security aspects of ASL, reiterating some
  points from earlier sections in a concise manner, and adding any
  additional considerations. ASL is designed to provide confidentiality,
  integrity, and authenticity in the presence of active adversaries, and
  to resist both classical and quantum cryptanalytic attacks. However, as
  with any cryptographic protocol, correct implementation and parameter
  choices are critical.

  6.1. Man-in-the-Middle (MITM)

  ASL explicitly addresses MITM attacks through its handshake design. An



  Nsiangani                Expires 13 August 2026                [Page 51]


  Internet-Draft                ASL Protocol                 February 2026


  MITM is an attacker who intercepts communications and attempts to
  impersonate each party to the other. In the ASL handshake:
  - The server authentication is based on possession of the secret prime
  (or its factors). The client verifies the server by checking the
  `q^2_masked` value against a trusted reference and by ensuring the
  server can decrypt the client's secret message. An attacker in the
  middle who does not have the server's private key cannot satisfy both
  conditions. They might forward messages to the real server (attempting a
  relay attack), but the handshake verification (e.g., the final encrypted
  verify message with state binding) will fail unless the MITM lets the
  actual server complete the handshake, in which case the MITM isn't
  actually decrypting anything (just tunneling).
  - If the MITM tries to use their own key pair to talk to the client, the
  `q^2_masked` check will fail (client won't recognize this rogue server's
  identity as legitimate). If they try to use their key with the real
  server, the server will similarly not recognize the client if client
  authentication is expected, or the server will complete handshake but
  then the MITM can't use the session because the client side didn't
  complete it with them properly.
  - Thus, as long as the client has a correct trusted copy of the server's
  public-key identifier (and the server is not compromised), a MITM cannot
  pretend to be the server. This is equivalent to saying ASL, like TLS,
  assumes an authenticated server public key distribution. If that initial
  distribution is via a secure channel (like a known fingerprint, or DANE,
  or a CA-signed object), MITM is thwarted. If it's not (like no
  verification, just take whatever comes first), then a MITM during first
  contact could trick the client into trusting a fake key (TOFU scenario).
  That is not a protocol flaw but a bootstrapping issue.
  - For client authentication (if used), a MITM similarly cannot
  masquerade as the legitimate client to the server because they cannot
  produce a valid handshake under the client's public key if they don't
  have the private components. The server will either not accept the
  unknown key or, if the MITM tries a known client's ID but doesn't have
  key, it will fail at handshake verification.

  ASL also binds handshake and record layer tightly via the evolving
  state. After handshake, a MITM who didn't fully participate (and succeed
  in impersonation, which we argue they can't if checks are done) cannot
  inject data later:
  - Suppose a MITM recorded some ciphertext and tries to replay or inject
  it. If they don't know the current correct state or key, the receiver
  will find the `u_k` is not the expected next state (replay detection) or
  will fail to decrypt properly. Because the state transition is one-way
  and secret-driven, the MITM cannot guess a future valid state to inject
  fake ciphertext.
  - Meet-in-the-middle attacks in key search (where attacker tries to
  split a key into two parts and compromise one part at a time) do not
  apply to ASL's core because the key isn't used in a way that halves the



  Nsiangani                Expires 13 August 2026                [Page 52]


  Internet-Draft                ASL Protocol                 February 2026


  problem. The entire structure has to be guessed as a whole (see section
  3.4 on no partial disclosure).
  - A specific MITM concern is protocol downgrade: if there were multiple
  cipher suites or versions, an attacker could try to force the use of a
  weaker one by dropping messages. ASL's ClientHello/ServerHello version
  negotiation should be done with care (like TLS, the client should abort
  if server picks something not actually offered). We assume any alternate
  modes (like turning off injection or using smaller keys) are either not
  present or if present, chosen in a way that a MITM cannot cause
  insecurity (by always using secure defaults or requiring client
  consent).

  In summary, if ASL is executed correctly with authenticated keys, MITM
  is effectively mitigated. Implementers MUST ensure to perform the
  verification of `q^2_masked` and handshake results. Skipping those
  checks or ignoring authentication (for convenience or performance) would
  open a door to MITM, just as not checking a TLS certificate would.

  6.2. Collision Resistance

  "Collisions" in this context can mean a few things:
  - Two different keys yielding the same public parameters (commit
  collisions).
  - Two different plaintexts yielding the same ciphertext under different
  keys or states (encryption collisions).
  - Collisions in the sense of cryptographic hash (if we used any).

  **Key/Public Parameter Collisions**:
  - Could there be two distinct secret tuples (p, a, b, R) and (p', a',
  b', R') that produce the same public outputs (either same q or same
  commit)?
  - Having the same q would mean either p = p' or a scenario like p and p'
  both associated with the same q (which from q^2 - p^2 = q^2 - p'^2
  implies p = p', so either p = p' or p = -p' mod something but since
  these are integers, basically p equal or just sign difference irrelevant
  here because primes are positive).
  - So no two different p values should yield the same q.
  - Could two different abR structures yield the same serialized commit?
  The design of serialization and commitment (assuming an ideal hash or a
  well-chosen masked scheme) should make collisions computationally
  infeasible. We rely on that as a design assumption: e.g., if q^2_masked
  is chosen as say q^2 mod N for some number N, an attacker might try to
  find a different q' that yields same q^2 mod N, but that would require
  solving q^2  q'^2 (mod N), which often has the trivial solutions q'  q
  (mod N). If N is large (like a 512-bit number) and not specially
  structured, the chance of a random different q colliding is negligible.
  If an attacker found a colliding key that produces the same masked
  commit as a target, they could impersonate that target's identity. To



  Nsiangani                Expires 13 August 2026                [Page 53]


  Internet-Draft                ASL Protocol                 February 2026


  guard against that, one should choose the commit function to be
  collision-resistant (like a cryptographic hash or sufficiently large
  modulus to make solving that congruence as hard as guessing q).
  - We consider that aspect in design: it's RECOMMENDED to use a proven
  collision-resistant method for the commitment. Using a hash like SHA-256
  of the serialized abR would be safest (practically no collisions). Our
  avoidance of SHA in core was philosophical, but one might reintroduce a
  hash just for identity safety. If not, the masked approach used must be
  analyzed for collision risk.
  - In practice, the chance of two legitimate users picking keys that
  collide in commit is astronomically low if done right. The bigger risk
  is an attacker deliberately computing a colliding key pair if any
  weakness is found in commit. That's a niche attack; presumably as hard
  as breaking the scheme itself if commit is well-designed.

  **Ciphertext Collisions**:
  - Could two different plaintexts produce the same ciphertext under the
  same key and state? Ideally not, as that would violate invertibility for
  the legitimate decryptor (they wouldn't know which plaintext was
  intended). Given phi-ns-x is a permutation on Z_M for fixed a_k (except
  the small chance of hitting the y_i = 0 case), it should be one-to-one
  (maybe not strictly a permutation on the entire space if y=0 is
  excluded, but on the domain of allowed inputs it should be injective).
  - The transform looks invertible if you have the secret; it's likely
  that for each possible X there is exactly one plaintext that would
  produce it (or at most a small constant number given the quadratic
  nature, but the decryptor can figure out the correct one via key).
  - So collisions in this sense are not expected; each encryption mapping
  is unique per message. There's no known smaller subspace that two
  different messages would converge to the same X because that would imply
  solving p_L = constant for two different p_0 given the parameters  a
  difficult equation with no reason to have two solutions except trivial
  symmetric cases, which the key structure would break.
  - If optional masking like Eq6 is used, that formula is still injective
  given secret info; but an attacker might see multiple ciphertexts that
  numerically collide (e.g., if a certain pattern made two different X
  yield same C, they'd be indistinguishable to attacker, but decryptor
  would not confuse them because they'd decrypt differently). However, one
  must ensure that doesn't lead to a chosen-ciphertext vulnerability
  (shouldn't, because attacker can't control X without key anyway).
  - Also, sequence numbers (round) effectively make even identical
  plaintext encrypted at different times yield different ciphertext
  because a_k (hence the transform) changes each round. This provides
  semantic security (no pattern leak if same message repeated, unlike a
  deterministic cipher).

  **Hash Collisions**:
  - If any hashes (like for commit or handshake verify) are used,



  Nsiangani                Expires 13 August 2026                [Page 54]


  Internet-Draft                ASL Protocol                 February 2026


  collision resistance of those is required to avoid impersonation or
  tampering. Standard hashes like SHA-256 are fine. If an attacker found a
  hash collision in, say, the commit function, they could potentially
  produce a different abR that yields same commit, undermining key
  authenticity. This is theoretical (depending on commit scheme).
  - Or if using hash for handshake transcript, collisions are not a big
  worry unless an attacker could craft two different transcripts that
  produce same hash and trick one party, but that seems remote and anyway
  if handshake was manipulated that far, likely other parts would break.

  Overall, collisions are not seen as a practical threat in ASL when
  parameters and algorithms are chosen appropriately. Nevertheless:
  - **MUST**: The commit function for key identity must be collision-
  resistant (to at least 128-bit security). Using a secure hash function
  is recommended unless a purely arithmetic method with equivalent
  hardness is in place.
  - **MUST**: The encryption function should never be intentionally used
  in a way that non-injective behavior could occur. For instance, avoid
  using an M that is too small such that the plaintext space is much
  larger than M (which could cause wrap-around collisions).
  - **MUST**: Each encryption round use a unique state to avoid trivial
  collisions (like encrypting two messages with same state would produce
  same ciphertext if plaintexts equal; but state reuse must be prevented
  like IV reuse in any cipher).

  6.3. Secret Leakage and Oracle-Free Design

  One of the core security principles of Phi-Ns and ASL is the absence of
  any "oracle" that leaks information about the secret key or intermediate
  states:
  - During handshake, the server does not disclose anything that
  correlates directly with its secret. The `q^2_masked` value is a one-way
  function of q. The encryption/decryption process either succeeds or
  fails but does not reveal partial info: if an attacker guesses a wrong p
  and tries to decrypt something, they either get a wrong result or no
  result, with no indication of how far off they were.
  - The protocol does not use branch conditions or different responses
  that depend on secret values (at the spec level). Implementations should
  ensure to follow this: e.g., a naive implementation might accidentally
  take a different amount of time to decrypt based on how factors align,
  or return distinct error messages for different failure reasons. That
  could leak info via side-channels or behavior. An implementation
  **SHOULD** use constant-time arithmetic where feasible and treat all
  failures uniformly (just "handshake failed" without saying why).
  - In the data phase, an attacker cannot query the decryptor with
  arbitrary ciphertexts to get hints. If they send a malformed ciphertext,
  the receiver will drop it or potentially respond with a generic error or
  de-sync. There is no decrypt-oracle giving success/failure on a per-



  Nsiangani                Expires 13 August 2026                [Page 55]


  Internet-Draft                ASL Protocol                 February 2026


  packet basis in a useful way; at best, an attacker could flood with
  random ciphertexts and see if the receiver at some point processes one
  (meaning it was valid). But the odds of guessing a valid ciphertext and
  state is essentially zero. The receiver might also have anti-replay and
  anti-desynchronization logic (like not resetting state on a bad message,
  etc.) to avoid giving even timing clues. In short, forging a valid
  ciphertext is as hard as breaking the crypto, so no oracle helps.
  - The public values u_k and a_k leak no secret info by design. `a_k` is
  related to `u_k` by a simple formula with no secret. `u_k` evolves by
  multiplication with g^step_u. Now, one might worry: if an attacker sees
  two successive u values, can they solve for step_u? This is essentially
  solving g^step_u = u_{k+1} * inv(u_k) mod M. That's a discrete log
  problem. If M is large enough (e.g., 2048-bit prime), discrete log is
  infeasible classically and also by known sub-exponential algorithms. But
  note: discrete log is not NP-hard in general, it's sub-exponential (like
  128-bit security might require 3072-bit modulus). But also note: a
  quantum attacker could solve discrete log mod M in polynomial time
  (Shor's algorithm) if they had a quantum computer.
  - Does that mean if someone had a quantum computer, could they find
  step_u and then predict future states? Yes, if M was a standard prime
  field, Shor would find step_u from a single state pair. That would let
  them predict all future u/a. But would that let them decrypt content?
  Not directly, because they still don't have p or the door values. They
  could mimic the state sequence and attempt to encrypt their own messages
  or maybe mount some known plaintext attack if they guess content.
  However, just knowing state might help them attempt to brute force p by
  having more structured equations. But arguably, even with known u
  sequence, the core phi-ns problem remains (they have q possibly if
  server is PK-q, they have p if PK-p). Actually, if PK-q mode and
  attacker gets step from states, they know how u evolves. They could then
  generate u and a for future, but still can't decrypt without p. They
  could however attempt to send messages (since encryptor only needs a and
  public anchor q). Uh oh: if attacker knows step_u and has q (which is
  public in PK-q), they could now encrypt messages that the server would
  accept because they can predict the state and they know q. That breaks
  authenticity in PK-q mode if step is exposed. This is why leaking step_u
  is dangerous. So we must rely on discrete log hardness for adversaries.
  - Therefore, to avoid that, one might choose M to be a safe prime and g
  a generator, making discrete log as hard as possible for given size. For
  PQ safety, though, discrete log is vulnerable to quantum. But the idea
  is the attacker still couldn't decrypt past messages, but they could
  inject future ones if they break step. This suggests an interesting
  point: in a post-quantum scenario, even if phi-ns core is safe from
  quantum (no known algorithm to recover p from q easily), the use of a
  standard finite field for state might be a weakness because of Shor's
  algorithm. If a quantum adversary can derive step_u quickly, they can
  impersonate a client or server in sending data (though they'd still need
  to forge the proper door values if used).



  Nsiangani                Expires 13 August 2026                [Page 56]


  Internet-Draft                ASL Protocol                 February 2026


  - Potential mitigation: one could use a different group where discrete
  log is also thought PQ-hard (like a large non-abelian group or some
  lattice structure) for the state sequence. That becomes complex.
  Alternatively, ensure door values (stars) are used, because even if
  attacker predicts a and tries to encrypt, if they don't know b_i
  sequence, their ciphertext will be wrong. So the secret injection saves
  the day: it means even with knowledge of step and q, attacker can't
  create valid ciphertext because they'd miss the b_i.
  - So it's important: **If quantum adversary is a concern, use door
  injection or another secret element in encryption beyond just a and q**.
  This way, predicting the public state isn't enough to forge messages.
  - Also, after quantum, discrete log mod a large classical prime might
  become easy, so step would be known. However, recovering p from q (the
  phi-ns problem) might still be hard (super-exponential). So
  confidentiality might hold, but authenticity could suffer without the
  extra secret in each encryption. Therefore, for long-term PQ robustness,
  it's RECOMMENDED to enable the layer injection feature with secret
  values (stars/doors) when using ASL if one expects adversaries with
  quantum capabilities that could target the state update.

  **Side-channel leaks**:
  - While not explicitly in protocol, implementers must watch for timing,
  cache, and other side-channels. For example, big integer operations may
  vary in time based on operands (leading zeros, etc.), which can
  sometimes leak bits of secrets. If a side-channel attacker on the same
  machine could observe decryption time variations, they might glean info
  about p or R. It's a complex analysis for phi-ns, but general best
  practice: use constant-time arithmetic for key ops, avoid secret-
  dependent branches or memory access.
  - Storing of secrets: The private key (p, a, b, R, and seeds) should be
  protected in memory. After use, if a session key K_s is derived, it
  should be zeroed out after use or when session ends. Similarly, if
  recursion adds additional secrets, treat them carefully.
  - Randomness: The handshake relies on random `K_s`. If the clients
  random generation were poor, an attacker might guess K_s and break that
  session. Also, the servers seed for key generation must be truly random,
  else the key structure might have hidden correlations. So a robust
  CSPRNG is needed for keys and nonces.
  - The protocol has no dependence on any external random oracle at
  runtime besides those nonces and ephemeral secrets.

  In summary, ASL's design avoids deliberate information leakage.
  Implementers must maintain that property by following cryptographic
  coding standards. The protocol is safe against chosen-message attacks
  since an attacker cannot cause the legitimate parties to output
  something that reveals the key (there's no encryption oracle giving out
  something like plaintext bits or error messages keyed on secret). The
  worst an attacker can do is send junk and get disconnected.



  Nsiangani                Expires 13 August 2026                [Page 57]


  Internet-Draft                ASL Protocol                 February 2026


  6.4. Post-Quantum Resilience

  The cryptographic strength of ASL in a post-quantum setting is a key
  motivation for its design:
  - The Phi-Ns problem (recovering p given q and commit) has no known
  quantum sub-exponential attack. Grover's algorithm gives at best a sqrt
  speedup to brute force, which is negligible if the key space is super-
  exponential. The abR structure can be made large enough that even a
  quadratic reduction is insufficient.
  - To contrast: RSA or ECC fall to Shor's algorithm easily. Lattice-based
  schemes have better PQ standing but often larger keys and uncertain new
  problems. Phi-Ns offers another independent hardness assumption.
  - That said, one must consider *all* parts of the protocol under quantum
  threat:
    * As mentioned, the discrete log in Z_M could be a weak link (since
  thats traditional math). If a sufficiently large quantum computer
  existed and M was standard size (like 2048 bits), an attacker could find
  step_u, step_star etc. If they also have q (in PK-q mode), they could
  then attempt to impersonate as discussed. If in PK-p mode (q secret),
  knowing step doesn't directly give them ability to decrypt or send,
  since they still lack q and the injection secrets. So PK-p plus
  injection seems robust even against that quantum capability, because
  they'd still face the main phi-ns puzzle or have to solve for q.
    * If for some reason we used a known hash function for commit (like
  SHA-256), note that Grover could find preimages in 2^128 rather than
  2^256, which is still fine. Collision-finding doesn't benefit as much
  (quantum collision algorithms get 2^(n/3) complexity for n-bit hash, so
  SHA-256 would have 2^85, which is borderline, but then again one could
  switch to SHA-384 or SHA-512 in future or rely on the difficulty of
  forging a full key that matches a commit).
  - So, in a scenario where both sides anticipate quantum eavesdroppers,
  some adjustments can strengthen ASL:
    * Use larger M (size such that even quantum discrete log is hard;
  unfortunately, quantum DLP is polynomial, so any finite field is
  breakable at large scale).
    * Or use double encryption: one could combine phi-ns-x with a one-time
  pad or symmetric cipher as a fail-safe. For instance, after handshake,
  derive a symmetric key and use a quantum-resistant symmetric cipher
  (like AES) to encrypt data, and use phi-ns-x mainly for key exchange and
  authentication. This hybridity might be overkill but it's a path.
    * More straightforward: rely on the fact that to break ASL fully, the
  attacker needs to break phi-ns (to get the actual content) or at least
  the door secrets to forge data. We assume phi-ns stands firm against
  quantum, so confidentiality remains. For authenticity, ensure some
  secret piece remains unknown even if states are known. That we have done
  via door values.

  We emphasize that as of writing, quantum computers large enough to



  Nsiangani                Expires 13 August 2026                [Page 58]


  Internet-Draft                ASL Protocol                 February 2026


  attack 2048-bit discrete log do not exist, but they might within a
  couple decades. Meanwhile, phi-ns claims resistance due to no known
  algorithm. It's newer, so it warrants scrutiny from cryptographers to
  solidify that claim.

  One also should consider **data longevity**: If someone records ASL-
  encrypted traffic now and stores it, and in 20 years gets a quantum
  computer, could they decrypt it?
  - They would have q (if PK-q) or p (if PK-p) and M, etc. They might
  break the state progression (trivial with quantum as said) and then
  they'd know all a_k, but still they'd face the challenge of deciphering
  each message without p or q. If by then algorithms to invert phi-ns
  appear (quantum or even classical improvements), then confidentiality
  would be lost. So, if extremely long-term secrecy (decades) is needed,
  one might prefer to combine ASL with another PQ algorithm (hybrid
  encryption) just in case. However, if one believes in the strength of
  the combinatorial assumption, storing exabytes of classical cipher data
  might remain safe.

  **One more angle: lattice or code-based integration**: Could phi-ns keys
  be used in a lattice-like structure to update state instead of discrete
  exponent? Possibly future research. For now, we keep to classical groups
  but note the caveat.

  In summary, ASL is designed to be post-quantum secure to the best of
  current knowledge, but like all schemes, that depends on unproven
  hardness assumptions. We have identified potential quantum weaknesses
  (like state DLP) and provided mitigations (like secret injection). It is
  the responsibility of implementers targeting PQ security to enable those
  features and choose parameters accordingly (e.g., at least Profile L:
  256-bit p, q and perhaps deeper recursion or bigger R to frustrate any
  unknown quantum strategies).

  6.5. Unpredictability of States

  A crucial security aspect of ASL is that the public values broadcast
  with each message (the state: u_k and a_k) do not allow an adversary to
  predict future states or deduce past secrets. This unpredictability
  ensures **forward secrecy of state** and also contributes to
  authenticity (an attacker can't inject a valid future message because
  they can't guess the correct state and ciphertext combo).

  - The sequence u_k is essentially a pseudo-random sequence from the
  attackers viewpoint. Without knowing step_u, the best the attacker can
  do is see it as some random elements in Z_M. Even if they collect many
  pairs (u_k, u_{k+1}), it doesn't help them extrapolate unless they solve
  the discrete log problem to get step_u. As discussed, classically that's
  essentially impossible for large M, and even quantumly it's the one weak



  Nsiangani                Expires 13 August 2026                [Page 59]


  Internet-Draft                ASL Protocol                 February 2026


  link but mitigated with injection or an alternate approach.
  - Because of this, the **probability of an attacker correctly guessing
  the next valid u_{k+1}, a_{k+1} pair is 1/(M * something)** basically
  extremely small (like picking a random 2048-bit number correctly).
  - Likewise, if an attacker tries to replay an old message, the state
  (round number or u value) will likely not match the expected next state,
  and the receiver will detect that. So state sequence provides a built-in
  anti-replay mechanism. To be safe, implementations should:
    * Track the last seen round or state from each sender.
    * Reject any message that does not have round > last_round (or if
  round numbers reset, use another mechanism, perhaps window).
    * If round numbers are not explicit and just inferred by order, then
  any out-of-order arrival should be either ignored or cause a reset.
  Using explicit numbering is safer to detect replays.

  - **Non-deducibility of states** also means even if some state gets
  revealed (imagine an insider or side-channel reveals the current u_k),
  the attacker still cannot compute backwards to prior states without step
  (discrete log again). So backward secrecy is also there: observing a
  current state doesn't tell you what previous states were used (although
  an attacker might have seen them anyway if they are public, but if they
  missed some, they can't derive them from later ones easily).
  - If an attacker could somehow find a pattern or relation in the
  sequence (like a linear relation), that would break unpredictability.
  But ASL's usage of multiplicative group means it's essentially a power
  sequence (u_k = u_0 * g^{k*step_u}). This is exponential progression mod
  M, known to be a sequence with maximal period if g is generator and
  step_u not a multiple of the order. It's as unpredictible as discrete
  log assumption. There's no linear relation like LFSRs. So it's solid.
  - The inclusion of optional star rotation can make the state not just
  one sequence but a more complex one: if we modulate or sometimes replace
  u progression with another factor injection, to an external observer the
  sequence might look even more random (not just a single exponentiation
  pattern). However, from a pure unpredictability perspective, a single
  exponent sequence is already cryptographically random if DLP is hard.

  - **No partial prediction**: If an attacker sees u_k and u_{k+2} but
  misses u_{k+1}, can they compute it? That would require solving
  something like u_{k+2}/u_k = g^{2*step_u}, thus g^{step_u} would be a
  square root of that ratio, which is another discrete log essentially
  (two-step gap doesn't help; it might even give them a slight advantage
  like they know g^{2*step} now; in some cases they could attempt to take
  square root if group structure allowed multiple solutions, but since mod
  prime, taking sqrt is also non-trivial relative to DLP if step is odd
  etc).
  - It's theoretically possible if step_u was small, an attacker could
  brute force it by checking successive powers. Therefore, step_u should
  be a large random integer mod (M-1). If one naively set step_u to 1 or a



  Nsiangani                Expires 13 August 2026                [Page 60]


  Internet-Draft                ASL Protocol                 February 2026


  small number, an attacker could just try those. The specification says
  step_u is a shared secret and not published, but we should also ensure
  it's not too small or guessable. Essentially treat step_u as ~|M| bits
  of entropy.
  - Also if M-1 has small factors and step fell into a subgroup of small
  order, u might cycle in a shorter loop. That's an edge case: one should
  choose M (like a safe prime where M-1 = 2q, q prime, or at least with a
  large prime factor) and choose step not a multiple of any small factors
  to ensure full period. Possibly define that step must result in u having
  large order (maybe even exactly the largest prime factor of M-1).
  - If u cycles quickly, predictability might not be easier (still need
  log, but repetition could allow some statistical detection). Anyway, use
  large subgroup if not full group.

  - During an ongoing session, compromise of secrets provides at most
  future state knowledge but cannot retroactively decrypt earlier messages
  due to forward secrecy of ephemeral secrets, if ephemeral were used.
  Without ephemeral, compromising static key allows decrypting recorded
  past sessions.

  Another aspect: if an attacker can't predict states, they also can't
  perform any kind of chosen-plaintext correlation attack. For example, in
  some stream ciphers, if state/IV reuse happens, attackers exploit that.
  Here, state reuse should never happen as long as step isn't zero mod
  order or such. There is no key reuse per message because it's always
  evolving.

  Summing up:
  - The state sequence must be treated as a critical part of security.
  It's public but pseudo-random. Breaking its unpredictability reduces ASL
  to a simpler form that might be attackable.
  - Implementers must use strong parameters for the state evolution to
  maintain unpredictability. They must also enforce the protocol rules (no
  state reuse, detect replays).
  - If those are in place, an adversary gains nothing useful from
  observing states besides synchronization info.

  One might wonder if the public nature of a and u could ever leak info
  about the secret key (p or q). According to the design, they should not:
  p and q are only present in the encryption transform internally on
  receiver side. The values u and a are independent of p (they depend on
  step and g, which are unrelated to p; step is derived from K_s which
  might indirectly be influenced by p only if something like we derive
  step from private structure in a fancy implementation, but typically
  step is handshake ephemeral or from K_s).
  If an implementer foolishly derived step_u directly from p or R (like
  making step = some function of secret key), then u sequence could leak
  something about the key if someone solved DLP. That is not recommended.



  Nsiangani                Expires 13 August 2026                [Page 61]


  Internet-Draft                ASL Protocol                 February 2026


  step should be truly random from handshake secret, not deterministic
  from key. Keep the key and state mechanism separate except the key is
  needed to decrypt.

  This ends the security analysis. Overall, ASL appears to achieve its
  goals under standard and new hardness assumptions. Nevertheless, it
  should undergo extensive analysis by the community. As any new
  cryptosystems, it requires scrutiny, and while we have outlined reasons
  for its strength, only time and effort will validate them. Users of ASL
  in critical systems should follow developments and be ready to adapt
  parameters or schemes if any weaknesses are found.

  7. IANA Considerations

  This document does not require any actions from IANA. No new protocol
  numbers, ports, or registries are defined here.

  (If ASL were to be assigned a standard port or content type, that could
  be addressed in a future document. As of now, it operates at an
  application or session layer with no centralized coordination needed.)

  8. References

  8.1. Normative References

  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
  Requirement Levels",
             BCP 14, RFC 2119, March 1997.

  [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
  Key Words",
             BCP 14, RFC 8174, May 2017.

  [PhiNs]    Nsiangani, P. J., "Phi-Ns Cryptosystem: Structured Quadratic
  Gap Hardness for Public-Key Cryptography",
             draft-nsiangani-phi-ns-01 (work in progress), February 2026.

  8. References

  8.1. Normative References

  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

  [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
             Key Words", BCP 14, RFC 8174, May 2017.





  Nsiangani                Expires 13 August 2026                [Page 62]


  Internet-Draft                ASL Protocol                 February 2026


  8.2. Informative References


  [NISTPQC]  National Institute of Standards and Technology, "Post-Quantum
             Cryptography Standardization Project", 2016-2025.

  [ANSSI]    Agence Nationale de la Securite des Systemes d'Information,
             "RGS v2.0  Rfrentiel Gnral de Scurit", 2020.

  [NCSC]     National Cyber Security Centre, "Cryptographic
             Recommendations for TLS, VPNs, and Messaging", 2022.

  [Lamport]  Lamport, L., "Constructing Digital Signatures from a One Way
             Function", October 1979.

  [SHA256]   Dobbertin, H., Bosselaers, A., and Preneel, B., "The Hash
             Functions MD5, SHA-1 and RIPEMD", 1996.

  [PhiNs]    Nsangani, J., "Phi-Ns: Quadratic Structured Decomposition
             for Asymmetric Cryptography", Patent Pending, 2025.



  Author's Address

     Parfait Junior Nsiangani (Editor)
     Email: jnsiangani@gmail.com

               Figure 1: Original draft content (imported)

  2.  References

  Author's Address

     P.J. Nsiangani (editor)
     ACE Working Group















  Nsiangani                Expires 13 August 2026                [Page 63]


name: draft-ietf-lamps-est-renewal-info
rev: 00
title: Certificate Renewal Recommendations for Enrollment over Secure Transport
time: 2026-02-12T17:10:42Z
group_uri: /api/v1/group/group/2164/
expires: 2026-08-16T17:00:28Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014965+00:00
abstract:
  This document describes an extension to RFC7030, Enrollment over
     Secure Transport to give an indication to a end-entity device when it
     should start attempting to renew its certificates.

     Prior art is that client decides, with a typical recommmendation to
     start when the remaining lifetime of the certificate is at the 50%
     point.  As typical certificate lifetimes are reduced from years to
     fractions of a year, the 50% may be far too early, and this document
     provides a way to give alternate advice.

full_text:
  LAMPS Working Group                                       R. Shekh-Yusef
  Internet-Draft                                                     Ciena
  Intended status: Standards Track                           M. Richardson
  Expires: 16 August 2026                         Sandelman Software Works
                                                              M. Ounsworth
                                                           Entrust Limited
                                                          12 February 2026


  Certificate Renewal Recommendations for Enrollment over Secure Transport
                    draft-ietf-lamps-est-renewal-info-00

  Abstract

     This document describes an extension to RFC7030, Enrollment over
     Secure Transport to give an indication to a end-entity device when it
     should start attempting to renew its certificates.

     Prior art is that client decides, with a typical recommmendation to
     start when the remaining lifetime of the certificate is at the 50%
     point.  As typical certificate lifetimes are reduced from years to
     fractions of a year, the 50% may be far too early, and this document
     provides a way to give alternate advice.

  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-lamps-est-renewal-info/.

     Discussion of this document takes place on the lamps Working Group
     mailing list (mailto:spasm@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/spasm/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/spasm/.

     Source for this draft and an issue tracker can be found at
     https://github.com/lamps-wg/lamps-est-renewal-info.

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



  Shekh-Yusef, et al.      Expires 16 August 2026                 [Page 1]


  Internet-Draft                  est-renew                  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 16 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.  Renewal Information Request . . . . . . . . . . . . . . .   3
       3.2.  Renewal Information Response  . . . . . . . . . . . . . .   4
         3.2.1.  Base64 Not Used . . . . . . . . . . . . . . . . . . .   4
     4.  Renewal Operations  . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Fetching Schedule . . . . . . . . . . . . . . . . . . . .   5
     5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
     9.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
       10.2.  Informative References . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     [RFC9773], Section 1 explains why certificate lifetimes and renewal
     times need more deterministic control in the ACME [RFC8555]
     ecosystem.  Similar arguments apply to the [RFC7030] ecosystem.





  Shekh-Yusef, et al.      Expires 16 August 2026                 [Page 2]


  Internet-Draft                  est-renew                  February 2026


     This document extends [RFC7030] to add support for renewal
     information, by adding a new entry to the HTTP URIs for Control list
     defined in [RFC7030], Section 3.2.2

     This mechanism enables EST servers to provide suggested detailed
     renewal operations to EST clients.

     The /renewal-info URI is added, as an OPTIONAL operation, to the
     table in figure 5 in section 3.2.2 of [RFC7030].

  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.  Protocol Details

  3.1.  Renewal Information Request

     To retrieve the renewal information, the EST client uses the
     following HTTP request-line:

     GET /.well-known/est/renewal-info/<certificate-id>;

     The request includes a unique identifier for the certificate in
     question.  The unique identifier is constructed by concatenating the
     base64url encoding [RFC4648] of the keyIdentifier field of the
     certificate's Authority Key Identifier (AKI) [RFC5280] extension, the
     period character ".", and the base64url encoding of the DER-encoded
     Serial Number field (without the tag and length bytes).  All trailing
     "=" characters MUST be stripped from both parts of the unique
     identifier.

     Thus, the full request URL is constructed as follows (split onto
     multiple lines for readability), where the "||" operator indicates
     string concatenation:

         url = /.well-known/est/renewal-info
           || '/'
           || base64url(AKI keyIdentifier)
           || '.'
           || base64url(Serial)






  Shekh-Yusef, et al.      Expires 16 August 2026                 [Page 3]


  Internet-Draft                  est-renew                  February 2026


  3.2.  Renewal Information Response

     The structure the EST RenewalInfo object is as follows:

     suggestedWindow (object, required): A JSON object with two keys,
     "start" and "end", whose values are timestamps, encoded in the format
     specified in [RFC3339], which bound the window of time in which the
     CA recommends renewing the certificate.

     For example:

         HTTP/1.1 200 OK
         Content-Type: application/json
         Retry-After: 21600

         {
           "suggestedWindow": {
             "start": "2025-01-02T04:00:00Z",
             "end": "2025-01-03T04:00:00Z"
           }
         }

  3.2.1.  Base64 Not Used

     [RFC7030] mistakenly declared that all content would be base64
     encoded.  [RFC8951] clarifies that the content is to be base64
     encoded, whether or not there is a Content-Transfer-Encoding header
     present.  It further clarifies that future extensions (such as this
     document) will not use base64 encoding.  The response detailed above
     is not base64 encoded.

  4.  Renewal Operations

     Clients MUST attempt renewal at a time of their choosing based on the
     suggested renewal window, obtained in the previous step.

     The following algorithm is RECOMMENDED for choosing a renewal time:

     1.  Select a uniform random time within the suggested window.

     2.  If the selected time is in the past, attempt renewal immediately.

     3.  Otherwise, if the client can schedule itself to attempt renewal
         at exactly the selected time, do so.

     4.  Otherwise, if the selected time is before the next time that the
         client would wake up normally, attempt renewal immediately.




  Shekh-Yusef, et al.      Expires 16 August 2026                 [Page 4]


  Internet-Draft                  est-renew                  February 2026


     5.  Otherwise, sleep until the time indicated by the Retry-After
         header and return to Step 1.

     In all cases, renewal attempts are subject to the client's existing
     error backoff and retry intervals.

     A RenewalInfo object in which the end timestamp equals or precedes
     the start timestamp is invalid.  Servers MUST NOT serve such a
     response, and clients MUST treat one as though they failed to receive
     any response from the server (e.g., retry at an appropriate interval,
     renew on a fallback schedule, etc.).

  4.1.  Fetching Schedule

     The advice in [RFC9773], Section 4.3 applies:

     Clients SHOULD fetch a certificate's RenewalInfo immediately after
     issuance.

     During the lifetime of a certificate, the renewal information needs
     to be fetched frequently enough that clients learn about changes in
     the suggested window quickly, but without overwhelming the server.
     This protocol uses the Retry-After header [RFC9110] to indicate to
     clients how often to retry.  Note that in other HTTP applications,
     Retry-After often indicates the minimum time to wait before retrying
     a request.  In this protocol, it indicates the desired (i.e., both
     requested minimum and maximum) amount of time to wait.

     Clients MUST NOT check a certificate's RenewalInfo after the
     certificate has expired.  Clients MUST NOT check a certificate's
     RenewalInfo after they consider the certificate to be replaced (for
     instance, after a new certificate for the same identifiers has been
     received and configured).

  5.  Privacy Considerations

     A very short certificate lifetime renewal time will cause clients to
     communicate with the EST Registrar more frequently.

     EST connections for renewals typically make use of mutually
     authenticated TLS.  When the client certificate being an IDevID, or
     the last issued certificate, often an LDevID, there is potential to
     disclose identities during this connection when using TLS 1.2.

     TLS 1.3 does not suffer from this problem, and it's use is
     RECOMMENDED as per [I-D.ietf-uta-require-tls13]





  Shekh-Yusef, et al.      Expires 16 August 2026                 [Page 5]


  Internet-Draft                  est-renew                  February 2026


  6.  Security Considerations

     Not sure what yet.

  7.  IANA Considerations

     Might need a header allocation

  8.  Acknowledgements

     Many bits of text are taken from [RFC9773].

  9.  Changelog

  10.  References

  10.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/info/rfc2119>.

     [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
                Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
                <https://www.rfc-editor.org/info/rfc3339>.

     [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
                Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
                <https://www.rfc-editor.org/info/rfc4648>.

     [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/info/rfc5280>.

     [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/info/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/info/rfc8174>.






  Shekh-Yusef, et al.      Expires 16 August 2026                 [Page 6]


  Internet-Draft                  est-renew                  February 2026


     [RFC8951]  Richardson, M., Werner, T., and W. Pan, "Clarification of
                Enrollment over Secure Transport (EST): Transfer Encodings
                and ASN.1", RFC 8951, DOI 10.17487/RFC8951, November 2020,
                <https://www.rfc-editor.org/info/rfc8951>.

  10.2.  Informative References

     [I-D.ietf-uta-require-tls13]
                Salz, R. and N. Aviram, "New Protocols Using TLS Must
                Require TLS 1.3", Work in Progress, Internet-Draft, draft-
                ietf-uta-require-tls13-12, 14 April 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-uta-
                require-tls13-12>.

     [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
                Kasten, "Automatic Certificate Management Environment
                (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
                <https://www.rfc-editor.org/info/rfc8555>.

     [RFC9773]  Gable, A., "ACME Renewal Information (ARI) Extension",
                RFC 9773, DOI 10.17487/RFC9773, June 2025,
                <https://www.rfc-editor.org/info/rfc9773>.

  Authors' Addresses

     Rifaat Shekh-Yusef
     Ciena
     Email: rifaat.s.ietf@gmail.com


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


     Mike Ounsworth
     Entrust Limited
     Email: mike.ounsworth@entrust.com













  Shekh-Yusef, et al.      Expires 16 August 2026                 [Page 7]


name: draft-ietf-tls-extended-key-update
rev: 09
title: Extended Key Update for Transport Layer Security (TLS) 1.3
time: 2026-02-19T05:02:41Z
group_uri: /api/v1/group/group/1326/
expires: 2026-08-23T05:02:41Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014967+00:00
abstract:
  TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie-
     Hellman key exchange during the initial handshake, protecting past
     communications even if a party's long-term keys (typically a private
     key with a corresponding certificate) are later compromised.  While
     the built-in KeyUpdate mechanism allows application traffic keys to
     be refreshed during a session, it does not incorporate fresh entropy
     from a new key exchange and therefore does not provide post-
     compromise security.  This limitation can pose a security risk in
     long-lived sessions, such as those found in industrial IoT or
     telecommunications environments.

     To address this, this specification defines an extended key update
     mechanism that performs a fresh Diffie-Hellman exchange within an
     active session, thereby ensuring post-compromise security.  By
     forcing attackers to exfiltrate new key material repeatedly, this
     approach mitigates the risks associated with static key compromise.
     Regular renewal of session keys helps contain the impact of such
     compromises.  The extension is applicable to both TLS 1.3 and DTLS
     1.3.

full_text:
  Transport Layer Security                                   H. Tschofenig
  Internet-Draft                                                   Siemens
  Updates: 9261, 8446 (if approved)                               M. Tüxen
  Intended status: Standards Track       Münster Univ. of Applied Sciences
  Expires: 23 August 2026                                         T. Reddy
                                                                     Nokia
                                                                  S. Fries
                                                                   Siemens
                                                              Y. Rosomakho
                                                                   Zscaler
                                                          19 February 2026


         Extended Key Update for Transport Layer Security (TLS) 1.3
                   draft-ietf-tls-extended-key-update-09

  Abstract

     TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie-
     Hellman key exchange during the initial handshake, protecting past
     communications even if a party's long-term keys (typically a private
     key with a corresponding certificate) are later compromised.  While
     the built-in KeyUpdate mechanism allows application traffic keys to
     be refreshed during a session, it does not incorporate fresh entropy
     from a new key exchange and therefore does not provide post-
     compromise security.  This limitation can pose a security risk in
     long-lived sessions, such as those found in industrial IoT or
     telecommunications environments.

     To address this, this specification defines an extended key update
     mechanism that performs a fresh Diffie-Hellman exchange within an
     active session, thereby ensuring post-compromise security.  By
     forcing attackers to exfiltrate new key material repeatedly, this
     approach mitigates the risks associated with static key compromise.
     Regular renewal of session keys helps contain the impact of such
     compromises.  The extension is applicable to both TLS 1.3 and DTLS
     1.3.

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




  Tschofenig, et al.       Expires 23 August 2026                 [Page 1]


  Internet-Draft         Extended Key Update for TLS         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 23 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.  Terminology and Requirements Language . . . . . . . . . . . .   4
     3.  Negotiating the Extended Key Update . . . . . . . . . . . . .   5
     4.  Extended Key Update Messages  . . . . . . . . . . . . . . . .   5
     5.  TLS 1.3 Considerations  . . . . . . . . . . . . . . . . . . .   8
       5.1.  TLS 1.3 Extended Key Update Example . . . . . . . . . . .  10
     6.  DTLS 1.3 Considerations . . . . . . . . . . . . . . . . . . .  11
       6.1.  DTLS 1.3 Extended Key Update Example  . . . . . . . . . .  14
     7.  Updating Traffic Keys . . . . . . . . . . . . . . . . . . . .  16
     8.  Post-Quantum Cryptography Considerations  . . . . . . . . . .  18
     9.  SSLKEYLOGFILE Update  . . . . . . . . . . . . . . . . . . . .  19
     10. Exporter  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
       10.1.  Post-Compromise Security for the Initial Exporter
              Secret . . . . . . . . . . . . . . . . . . . . . . . . .  20
       10.2.  Exporter Usage After Extended Key Update . . . . . . . .  21
     11. Use of Post-Handshake Authentication and Exported
             Authenticators with Extended Key Update . . . . . . . . .  22
       11.1.  Post-Handshake Certificate-Based Client
              Authentication . . . . . . . . . . . . . . . . . . . . .  22
       11.2.  Exported Authenticators  . . . . . . . . . . . . . . . .  23
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  23
       12.1.  Scope of Key Compromise  . . . . . . . . . . . . . . . .  24
       12.2.  Post-Compromise Security . . . . . . . . . . . . . . . .  24
       12.3.  Denial-of-Service (DoS)  . . . . . . . . . . . . . . . .  25
       12.4.  Operational Guidance . . . . . . . . . . . . . . . . . .  25



  Tschofenig, et al.       Expires 23 August 2026                 [Page 2]


  Internet-Draft         Extended Key Update for TLS         February 2026


     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
       13.1.  TLS Flags  . . . . . . . . . . . . . . . . . . . . . . .  25
       13.2.  TLS HandshakeType  . . . . . . . . . . . . . . . . . . .  25
       13.3.  ExtendedKeyUpdate Message Subtypes Registry  . . . . . .  26
       13.4.  SSLKEYLOGFILE labels . . . . . . . . . . . . . . . . . .  26
     14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
       14.1.  Normative References . . . . . . . . . . . . . . . . . .  27
       14.2.  Informative References . . . . . . . . . . . . . . . . .  28
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  30
     Appendix B.  State Machines . . . . . . . . . . . . . . . . . . .  30
       B.1.  TLS 1.3 State Machines  . . . . . . . . . . . . . . . . .  31
         B.1.1.  Initiator State Machine . . . . . . . . . . . . . . .  31
         B.1.2.  Responder State Machine . . . . . . . . . . . . . . .  32
       B.2.  DTLS 1.3 State Machines . . . . . . . . . . . . . . . . .  33
         B.2.1.  Terms and Abbreviations . . . . . . . . . . . . . . .  34
         B.2.2.  State Machine (Initiator) . . . . . . . . . . . . . .  34
         B.2.3.  State Machine (Responder) . . . . . . . . . . . . . .  36
     Appendix C.  Overview of Security Goals . . . . . . . . . . . . .  38
       C.1.  Post-Compromise Security (PCS)  . . . . . . . . . . . . .  39
       C.2.  Key Freshness and Cryptographic Independence  . . . . . .  39
       C.3.  Elimination of Standard KeyUpdate . . . . . . . . . . . .  39
       C.4.  Detecting Divergent Key State . . . . . . . . . . . . . .  39
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40

  1.  Introduction

     The Transport Layer Security (TLS) 1.3 protocol provides forward
     secrecy by using an ephemeral Diffie-Hellman (DHE) key exchange
     during the initial handshake.  This ensures that encrypted
     communication remains confidential even if an attacker later obtains
     a party's long-term private key, protecting against passive
     adversaries who record encrypted traffic for later decryption.

     TLS 1.3 also includes a KeyUpdate mechanism that allows traffic keys
     to be refreshed during an established session.  However, this
     mechanism does not provide post-compromise security, as it applies
     only a key derivation function to the previous application traffic
     key as input.  While this design is generally sufficient for short-
     lived connections, it may present security limitations in scenarios
     where sessions persist for extended periods, such as in industrial
     IoT or telecommunications systems, where continuous availability is
     critical and session renegotiation or resumption is impractical.

     Earlier versions of TLS supported session renegotiation, which
     allowed peers to negotiate fresh keying material, including
     performing new Diffie-Hellman exchanges during the session lifetime.
     Due to protocol complexity and known vulnerabilities, renegotiation
     was first restricted by [TLS-RENEGOTIATION] and ultimately removed in



  Tschofenig, et al.       Expires 23 August 2026                 [Page 3]


  Internet-Draft         Extended Key Update for TLS         February 2026


     TLS 1.3.  While the KeyUpdate message was introduced to offer limited
     rekeying functionality, it does not fulfill the same cryptographic
     role as renegotiation and cannot refresh the TLS main secret and
     consequently cannot derive new secrets from fresh DHE input.

     Security guidance from national agencies, such as ANSSI (France
     [ANSSI]), recommends the periodic renewal of cryptographic keys
     during long-lived sessions to limit the impact of key compromise.
     This approach encourages designs that force an attacker to perform
     dynamic key exfiltration, as defined in [CONFIDENTIALITY].  Dynamic
     key exfiltration refers to attack scenarios where an adversary must
     repeatedly extract fresh keying material to maintain access to
     protected data, increasing operational cost and risk for the
     attacker.  In contrast, static key exfiltration, where the TLS main
     secret is extracted once and reused, poses a greater long-term
     threat, especially when session keys are not refreshed with fresh key
     exchange input rather than key derivation.

     This specification defines a TLS extension that introduces an
     extended key update mechanism.  Unlike the standard key update, this
     mechanism allows peers to perform a fresh Diffie-Hellman exchange
     within an active session using one of the groups negotiated during
     the initial handshake.  By periodically rerunning (EC)DHE, this
     extension enables the derivation of new traffic keys that are
     independent of prior key material.  As noted in Appendix F of [TLS],
     this approach mitigates the risk of static key exfiltration and
     shifts the attacker burden toward dynamic key exfiltration.

     The proposed extension is applicable to both TLS 1.3 [TLS] and DTLS
     1.3 [DTLS].  For clarity, the term "TLS" is used throughout this
     document to refer to both protocols unless otherwise specified.

  2.  Terminology and Requirements Language

     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.

     To distinguish the key update procedure defined in [TLS] from the key
     update procedure specified in this document, we use the terms
     "standard key update" and "extended key update", respectively.

     In this document, we use the term post-compromise security, as
     defined in [CCG16].  We assume that an adversary may obtain access to
     the application traffic keys.




  Tschofenig, et al.       Expires 23 August 2026                 [Page 4]


  Internet-Draft         Extended Key Update for TLS         February 2026


     Unless otherwise specified, all references to traffic keys in this
     document refer to application traffic keys and because the Extended
     Key Update procedure occurs after the handshake phase has completed,
     no handshake traffic keys are involved.

     In this document, send key refers to the [sender]_write_key, and
     receive key refers to the [receiver]_write_key.  These keys are
     derived from the active client_application_traffic_secret_N and
     server_application_traffic_secret_N, as defined in (D)TLS 1.3 [TLS],
     and are replaced with new ones after each successful Extended Key
     Update.

  3.  Negotiating the Extended Key Update

     Client and servers use the TLS flags extension [TLS-FLAGS] to
     indicate support for the functionality defined in this document.  We
     call this flag "Extended_Key_Update" flag.

     The "Extended_Key_Update" flag proposed by the client in the
     ClientHello (CH) MUST be acknowledged in the EncryptedExtensions
     (EE), if the server also supports the functionality defined in this
     document and is configured to use it.

     If the "Extended_Key_Update" flag is not set, servers ignore any of
     the functionality specified in this document and applications that
     require post-compromise security will have to initiate a full
     handshake.

  4.  Extended Key Update Messages

     If the client and server agree to use the extended key update
     mechanism, the standard key update MUST NOT be used.  In this case,
     the extended key update fully replaces the standard key update
     functionality.

     Implementations that receive a classic KeyUpdate message after
     successfully negotiating the Extended Key Update functionality MUST
     terminate the connection with an "unexpected_message" alert.

     The extended key update messages are signaled in a new handshake
     message named ExtendedKeyUpdate (EKU), with an internal uint8 message
     subtype indicating its role.  This specification defines three
     ExtendedKeyUpdate message subtypes:

     *  key_update_request (0)

     *  key_update_response (1)




  Tschofenig, et al.       Expires 23 August 2026                 [Page 5]


  Internet-Draft         Extended Key Update for TLS         February 2026


     *  new_key_update (2)

     New ExtendedKeyUpdate message subtypes are assigned by IANA as
     described in Section 13.3.

     A TLS peer which receives a ExtendedKeyUpdate with an unexpected
     message subtype MUST abort the connection with an
     "unexpected_message" alert.

     The extended key update process can be initiated by either peer after
     it has sent a Finished message.  Implementations that receive an
     ExtendedKeyUpdate message prior to the sender having sent Finished
     MUST terminate the connection with an "unexpected_message" alert.

     The KeyShareEntry carried in a key_update_request and in a
     key_update_response MUST use the group that was negotiated by the
     client and server during the initial handshake.  An implementation
     that receives an algorithm other than previously negotiated MUST
     terminate the connection with an "illegal_parameter" alert.

     Figure 1 shows the interaction graphically.  First, support for the
     functionality in this specification is negotiated in the ClientHello
     and the EncryptedExtensions messages.  Then, the ExtendedKeyUpdate
     exchange is sent to update the application traffic secrets.

     The extended key update exchange is performed between the initiator
     and the responder; either the TLS client or the TLS server may act as
     initiator.























  Tschofenig, et al.       Expires 23 August 2026                 [Page 6]


  Internet-Draft         Extended Key Update for TLS         February 2026


          Client                                           Server

   Key  ^ ClientHello
   Exch | + key_share
        | + signature_algorithms
        v + extended_key_update   -------->
                                                     ServerHello  ^ Key
                                                     + key_share  | Exch
                                                                  v
                                           {EncryptedExtensions   ^ Server
                                          + extended_key_update}  | Params
                                            {CertificateRequest}  v
                                                   {Certificate}  ^
                                             {CertificateVerify}  | Auth
                                                      {Finished}  v
                                  <--------
        ^ {Certificate}
   Auth | {CertificateVerify}
        v {Finished}              -------->
          [Application Data]N     <------->  [Application Data]N
                                     ...
     [EKU(key_update_request)]N   -------->
                                  <--------  [EKU(key_update_response)]N
         [EKU(new_key_update)]N   -------->
                                     ...
          [Application Data]N+1   <------->  [Application Data]N+1

   Legend:

       +   Indicates noteworthy extensions sent in the
       previously noted message.

       -   Indicates optional or situation-dependent
       messages/extensions that are not always sent.

       () Indicates messages protected using keys
       derived from a client_early_traffic_secret.

       {} Indicates messages protected using keys
       derived from a [sender]_handshake_traffic_secret.

       []N Indicates messages protected using keys
       derived from [sender]_application_traffic_secret_N.

         Figure 1: Extended Key Update Message Exchange in TLS 1.3.

     The ExtendedKeyUpdate wire format is:




  Tschofenig, et al.       Expires 23 August 2026                 [Page 7]


  Internet-Draft         Extended Key Update for TLS         February 2026


     enum {
        key_update_request(0),
        key_update_response(1),
        new_key_update(2),
        (255)
     } ExtendedKeyUpdateType;

     struct {
        ExtendedKeyUpdateType eku_type;
        select (eku_type) {
           case key_update_request: {
               KeyShareEntry key_share;
           }
           case key_update_response: {
               KeyShareEntry key_share;
           }
           case new_key_update: {
               /* empty */
           }
        };
     } ExtendedKeyUpdate;

     Fields:

     *  eku_type: the subtype of the ExtendedKeyUpdate message.

     *  key_share: key share information.  The contents of this field is
        determined by the specified group and its corresponding definition
        (see Section 4.2.8 of [TLS]).

  5.  TLS 1.3 Considerations

     The following steps are taken by a TLS 1.3 implementation; the steps
     executed with DTLS 1.3 differ slightly.

     1.  The initiator sends ExtendedKeyUpdate(key_update_request)
         carrying a KeyShareEntry.  While an extended key update is in
         progress, the initiator MUST NOT initiate another key update.

     2.  Upon receipt, the responder sends its own KeyShareEntry in a
         ExtendedKeyUpdate(key_update_response) message.  While an
         extended key update is in progress, the responder MUST NOT
         initiate another key update.  The responder MAY defer sending a
         response if system load or resource constraints prevent immediate
         processing.  In such cases, the response MUST be sent once
         sufficient resources become available.





  Tschofenig, et al.       Expires 23 August 2026                 [Page 8]


  Internet-Draft         Extended Key Update for TLS         February 2026


     3.  After the responder sends ExtendedKeyUpdate(key_update_response)
         it MUST update its send keys.

     4.  Upon receipt of an ExtendedKeyUpdate(key_update_response) the
         initiator derives the new secrets from the exchanged key shares.
         The initiator then updates its receive keys and sends an empty
         ExtendedKeyUpdate(new_key_update) message to complete the
         process.  The initiator MUST NOT defer derivation of the secrets
         and sending the ExtendedKeyUpdate(new_key_update) message as it
         would stall the communication.

     5.  After sending ExtendedKeyUpdate(new_key_update) initiator MUST
         update its send keys.

     6.  After receiving the initiator’s
         ExtendedKeyUpdate(new_key_update), the responder MUST update its
         receive keys.

     Both initiator and responder MUST encrypt their ExtendedKeyUpdate
     messages with the old keys.  Responder MUST ensure that the
     ExtendedKeyUpdate(new_key_update) encrypted with the old key is
     received before accepting any messages encrypted with the new key.

     If TLS peers independently initiate the extended key update and the
     requests cross in flight, the ExtendedKeyUpdate(key_update_request)
     with the lower lexicographic order of the key_exchange value in
     KeyShareEntry MUST be ignored.  This prevents each side from
     advancing keys by two generations.  If the tie-break comparison
     yields equality (an event that should be impossible for genuine
     asymmetric key pairs), the endpoint MUST treat this as a protocol
     violation, send an "unexpected_message" alert, and close the
     connection.

     The handshake framing uses a single HandshakeType for this message
     (see Figure 2).
















  Tschofenig, et al.       Expires 23 August 2026                 [Page 9]


  Internet-Draft         Extended Key Update for TLS         February 2026


           struct {
               HandshakeType msg_type;    /* handshake type */
               uint24 length;             /* bytes in message */
               select (Handshake.msg_type) {
                   case client_hello:          ClientHello;
                   case server_hello:          ServerHello;
                   case end_of_early_data:     EndOfEarlyData;
                   case encrypted_extensions:  EncryptedExtensions;
                   case certificate_request:   CertificateRequest;
                   case certificate:           Certificate;
                   case certificate_verify:    CertificateVerify;
                   case finished:              Finished;
                   case new_session_ticket:    NewSessionTicket;
                   case key_update:            KeyUpdate;
                   case extended_key_update:   ExtendedKeyUpdate;
               };
           } Handshake;

                     Figure 2: TLS 1.3 Handshake Structure.

  5.1.  TLS 1.3 Extended Key Update Example

     While Figure 1 shows the high-level interaction between a TLS 1.3
     client and server, this section shows an example message exchange
     with information about the updated keys added.

     There are two phases:

     1.  The support for the functionality in this specification is
         negotiated in the ClientHello and the EncryptedExtensions
         messages.

     2.  Once the initial handshake is completed, a key update can be
         triggered.

     Figure 3 provides an overview of the exchange starting with the
     initial negotiation followed by the key update.














  Tschofenig, et al.       Expires 23 August 2026                [Page 10]


  Internet-Draft         Extended Key Update for TLS         February 2026


          Client                                           Server

   Key  ^ ClientHello
   Exch | + key_share
        | + signature_algorithms
        v + extended_key_update
                                -------->
                                                     ServerHello  ^ Key
                                                     + key_share  | Exch
                                                                  v
                                           {EncryptedExtensions   ^ Server
                                          + extended_key_update}  | Params
                                            {CertificateRequest}  v
                                                   {Certificate}  ^
                                             {CertificateVerify}  | Auth
                                                      {Finished}  v
                                  <--------
        ^ {Certificate}
   Auth | {CertificateVerify}
        v {Finished}              -------->
                                     ...
                                 some time later
                                     ...
    [EKU(key_update_request       -------->
          (with key_share))]
                                  <-------- [EKU(key_update_response
                                              (with key_share))]
                                           # Server derives new secrets
                                           # and updates SEND keys here
   # Client derives new secrets
   # and updates RECEIVE keys here
           [EKU(new_key_update)]  -------->
   # Client updates SEND keys here
                                       # Server updates RECEIVE keys here

                   Figure 3: Extended Key Update Example.

  6.  DTLS 1.3 Considerations

     Unlike TLS 1.3, DTLS 1.3 implementations must take into account that
     handshake messages are not transmitted over a reliable transport
     protocol.









  Tschofenig, et al.       Expires 23 August 2026                [Page 11]


  Internet-Draft         Extended Key Update for TLS         February 2026


     EKU messages MUST be transmitted reliably, like other DTLS handshake
     messages.  If necessary, EKU messages MAY be fragmented as described
     in Section 5.5 of [DTLS].  Due to the possibility of an
     ExtendedKeyUpdate messages being lost and thereby preventing the
     sender of that message from updating its keying material, receivers
     MUST retain the pre-update keying material until receipt and
     successful decryption of a message using the new keys.

     Due to packet loss and/or reordering, DTLS 1.3 peers MAY receive
     records from an earlier epoch.  If the necessary keys are available,
     implementations SHOULD attempt to process such records; however, they
     MAY choose to discard them.  The exchange has the following steps:

     1.  The initiator sends an ExtendedKeyUpdate(key_update_request)
         message, which contains a key share.  While an extended key
         update is in progress, the initiator MUST NOT initiate further
         key updates.  This message is subject to DTLS handshake
         retransmission, but delivery is only confirmed when the initiator
         either receives the corresponding
         ExtendedKeyUpdate(key_update_response) or an ACK.

     2.  Upon receipt, the responder sends its own KeyShareEntry in a
         ExtendedKeyUpdate(key_update_response) message.  While an
         extended key update is in progress, the responder MUST NOT
         initiate further key updates.  The responder MAY defer sending a
         response if system load or resource constraints prevent immediate
         processing.  In such cases, the responder MUST acknowledge
         receipt of the key_update_request with an ACK and, once
         sufficient resources become available, retransmit the
         key_update_response until it is acknowledged by the initiator.

     3.  On receipt of ExtendedKeyUpdate(key_update_response) the
         initiator derives a secret key based on the exchanged key shares.
         This message also serves as an implicit acknowledgment of the
         initiator's ExtendedKeyUpdate(key_update_request), so no separate
         ACK is required.  The initiator MUST update its receive keys and
         epoch value.  The initiator MUST NOT defer derivation of the
         secrets.

     4.  The initiator transmits an ExtendedKeyUpdate(new_key_update)
         message.  This message is subject to DTLS retransmission until
         acknowledged.

     5.  The responder MUST acknowledge the received message by sending an
         ACK message.






  Tschofenig, et al.       Expires 23 August 2026                [Page 12]


  Internet-Draft         Extended Key Update for TLS         February 2026


     6.  After the responder receives the initiator's
         ExtendedKeyUpdate(new_key_update), the responder MUST update its
         send key and epoch value.  With the receipt of that message, the
         responder MUST also update its receive keys.

     7.  On receipt of the ACK message, the initiator updates its send key
         and epoch value.  If this ACK is not received, the initiator re-
         transmits its ExtendedKeyUpdate(new_key_update) until ACK is
         received.  The key update is complete once this ACK is processed
         by the initiator.

     The handshake framing uses a single HandshakeType for this message
     (see Figure 4).






































  Tschofenig, et al.       Expires 23 August 2026                [Page 13]


  Internet-Draft         Extended Key Update for TLS         February 2026


            enum {
                client_hello(1),
                server_hello(2),
                new_session_ticket(4),
                end_of_early_data(5),
                encrypted_extensions(8),
                request_connection_id(9),
                new_connection_id(10),
                certificate(11),
                certificate_request(13),
                certificate_verify(15),
                finished(20),
                key_update(24),
                extended_key_update(TBD),  /* new */
                message_hash(254),
                (255)
            } HandshakeType;

            struct {
                HandshakeType msg_type;    /* handshake type */
                uint24 length;             /* bytes in message */
                uint16 message_seq;        /* DTLS-required field */
                uint24 fragment_offset;    /* DTLS-required field */
                uint24 fragment_length;    /* DTLS-required field */
                select (msg_type) {
                    case client_hello:          ClientHello;
                    case server_hello:          ServerHello;
                    case end_of_early_data:     EndOfEarlyData;
                    case encrypted_extensions:  EncryptedExtensions;
                    case certificate_request:   CertificateRequest;
                    case certificate:           Certificate;
                    case certificate_verify:    CertificateVerify;
                    case finished:              Finished;
                    case new_session_ticket:    NewSessionTicket;
                    case key_update:            KeyUpdate;
                    case extended_key_update:   ExtendedKeyUpdate;
                    case request_connection_id: RequestConnectionId;
                    case new_connection_id:     NewConnectionId;
                } body;
            } DTLSHandshake;

                    Figure 4: DTLS 1.3 Handshake Structure.

  6.1.  DTLS 1.3 Extended Key Update Example

     The following example illustrates a successful extended key update,
     including how the epochs change during the exchange.




  Tschofenig, et al.       Expires 23 August 2026                [Page 14]


  Internet-Draft         Extended Key Update for TLS         February 2026


     Client                            Server
     (Initiator)                       (Responder)

       /---------------------------------------\
      |           Initial Handshake             |
       \---------------------------------------/

     [C: tx=3, rx=3]                   [S: tx=3, rx=3]
     [Application Data]               -------->
     [C: tx=3, rx=3]                   [S: tx=3, rx=3]

     [C: tx=3, rx=3]                   [S: tx=3, rx=3]
                                       <--------   [Application Data]
     [C: tx=3, rx=3]                   [S: tx=3, rx=3]

       /---------------------------------------\
      |           Some time later ...           |
       \---------------------------------------/

     [C: tx=3, rx=3]                   [S: tx=3, rx=3]
     [EKU(key_update_request)]  -------->
                                       # no epoch change yet

                                <-------- [EKU(key_update_response)]
     # Sent under OLD epoch. Server does NOT bump yet.

     # Step 3: initiator bumps RECEIVE epoch on
     # receiving key update response-in:
     # (rx:=rx+1; tx still old)
     [C: tx=3, rx=4]                   [S: tx=3, rx=3]

     [EKU(new_key_update)]      -------->
     # Sender's NKU is tagged with OLD tx (3).

     # Epoch switch point:
     # Step 6: responder bumps BOTH tx and rx on NKU-in:
     [C: tx=3, rx=4]                   [S: tx=4, rx=4]

                                <-------- [ACK] (tag=new)

     # Step 7: initiator bumps SEND epoch on ACK-in:
     [C: tx=4, rx=4]                   [S: tx=4, rx=4]

     [Application Data]         -------->
     [C: tx=4, rx=4]                   [S: tx=4, rx=4]

                                <--------   [Application Data]
     [C: tx=4, rx=4]                   [S: tx=4, rx=4]



  Tschofenig, et al.       Expires 23 August 2026                [Page 15]


  Internet-Draft         Extended Key Update for TLS         February 2026


       Figure 5: Example DTLS 1.3 Extended Key Update: Message Exchange.

     Figure 6 shows the steps, the message in flight, and the epoch
     changes on both sides.  The A/B -> X/Y notation indicates the change
     of epoch values for tx/rx before and after the message transmission.

     +--------------------+----------------+--------------+
     | Message            | Client tx/rx   | Server tx/rx |
     +--------------------+----------------+--------------+
     | APP ------------>  | 3/3 -> 3/3     | 3/3 -> 3/3   |
     | <------------ APP  | 3/3 -> 3/3     | 3/3 -> 3/3   |
     | req -------------> | 3/3 -> 3/3     | 3/3 -> 3/3   |
     | <------------ resp | 3/3 -> 3/4     | 3/3 -> 3/3   | <- step 3
     | NKU  ------------> | 3/4 -> 3/4     | 3/3 -> 4/4   | <- step 6
     | <------------- ACK | 3/4 -> 4/4     | 4/4 -> 4/4   | <- step 7
     | APP -------------> | 4/4 -> 4/4     | 4/4 -> 4/4   |
     | <------------- APP | 4/4 -> 4/4     | 4/4 -> 4/4   |
     +--------------------+----------------+--------------+

         Figure 6: Example DTLS 1.3 Extended Key Update: Epoch Changes.

  7.  Updating Traffic Keys

     When the extended key update message exchange is completed both peers
     have successfully updated their application traffic keys.  The key
     derivation function described in this document is used to perform
     this update.

     The design of the key derivation function for computing the next
     generation of application_traffic_secret is motivated by the desire
     to include

     *  a secret derived from the (EC)DHE exchange (or from the hybrid key
        exchange / PQ-KEM exchange),

     *  a secret that allows the new key exchange to be cryptographically
        bound to the previously established secret,

     *  a transcript hash that is updated after each Extended Key Update
        exchange by hashing together the previous transcript hash value
        and the current ExtendedKeyUpdate(key_update_request) and
        ExtendedKeyUpdate(key_update_response) messages, which contain the
        key shares, thereby binding the encapsulated shared secret
        ciphertext to the IKM in the case of PQ/T hybrid or PQC key
        exchange and cryptographically binding the newly derived secrets
        to the prior handshake transcript and all preceding EKU exchanges,
        as well as to the current EKU exchange, and




  Tschofenig, et al.       Expires 23 August 2026                [Page 16]


  Internet-Draft         Extended Key Update for TLS         February 2026


     *  new label strings to distinguish it from the key derivation used
        in TLS 1.3.

     The transcript_hash_N denotes the transcript hash value associated
     with generation N.  During each Extended Key Update exchange, the
     transcript hash value for the next generation is computed as follows:

      transcript_hash_N+1 = Transcript-Hash(transcript_hash_N ||
                                            EKU(key_update_request) ||
                                            EKU(key_update_response))

     Once transcript_hash_N+1 has been computed, transcript_hash_N can be
     deleted.  No prior transcript hash values need to be retained for
     future EKU exchanges. transcript_hash_0 denotes the transcript hash
     of the initial TLS handshake, covering all messages from the
     ClientHello up to and including the client Finished message.

     The following diagram shows the key derivation hierarchy.

            Main Secret N
                  |
                  v
            Derive-Secret(., "derived", "")
                  |
                  v
      (EC)DHE -> HKDF-Extract = Main Secret N+1
                  |
                  +-----> Derive-Secret(., "c ap traffic",
                  |                     transcript_hash_N+1)
                  |                = client_application_traffic_secret_N+1
                  |
                  +-----> Derive-Secret(., "s ap traffic",
                  |                     transcript_hash_N+1)
                  |                = server_application_traffic_secret_N+1
                  |
                  +-----> Derive-Secret(., "exp master",
                  |                     transcript_hash_N+1)
                  |                = exporter_secret_N+1
                  |
                  +-----> Derive-Secret(., "res master",
                  |                     transcript_hash_N+1)
                                   = resumption_main_secret_N+1

     During the initial handshake, the Main Secret is generated (see
     Section 7.1 of [TLS]).  Since the Main Secret is discarded during the
     key derivation procedure, a derived value is stored.  This stored
     value then serves as the input salt to the first key update procedure
     that incorporates the ephemeral (EC)DHE- established value as input



  Tschofenig, et al.       Expires 23 August 2026                [Page 17]


  Internet-Draft         Extended Key Update for TLS         February 2026


     keying material (IKM) to produce main_secret_{N+1}. The derived value
     from this new master secret serves as input salt to the subsequent
     key update procedure, which also incorporates a fresh ephemeral
     (EC)DHE value as IKM.  This process is repeated for each additional
     key update procedure.

     The traffic keys are re-derived from
     client_application_traffic_secret_N+1 and
     server_application_traffic_secret_N+1, as described in Section 7.3 of
     [TLS].

     Once client_/server_application_traffic_secret_N+1 and its associated
     traffic keys have been computed, implementations SHOULD delete
     client_/server_application_traffic_secret_N and its associated
     traffic keys as soon as possible.  Note: The client_/
     server_application_traffic_secret_N and its associated traffic keys
     can only be deleted by the responder after receiving the
     ExtendedKeyUpdate(new_key_update) message.

     Once client_/server_application_traffic_secret_N+1 and the
     corresponding traffic keys are in use, all subsequent records,
     including alerts and post-handshake messages MUST be protected using
     those keys.

     When using this extension, it is important to consider its
     interaction with ticket-based session resumption.  If resumption
     occurs without a new (EC)DH exchange that provides forward secrecy,
     an attacker could potentially revert the security context to an
     earlier state, thereby negating the benefits of the extended key
     update.  To preserve the security guarantees provided by key updates,
     endpoints MUST either invalidate any session tickets issued prior to
     the key update or ensure that resumption always involves a fresh
     (EC)DH exchange.

     If session tickets cannot be stored securely, developers SHOULD
     consider disabling ticket-based resumption in their deployments.
     While this approach may impact performance, it provides improved
     security properties.

  8.  Post-Quantum Cryptography Considerations

     Hybrid key exchange refers to the simultaneous use of multiple key
     exchange algorithms, with the resulting shared secret derived by
     combining the outputs of each.  The goal of this approach is to
     maintain security even if all but one of the component algorithms are
     later found to be vulnerable.





  Tschofenig, et al.       Expires 23 August 2026                [Page 18]


  Internet-Draft         Extended Key Update for TLS         February 2026


     The transition to post-quantum cryptography has motivated the
     adoption of hybrid key exchanges in TLS, as described in
     [TLS-HYBRID].  Specific hybrid groups have been registered in
     [TLS-ECDHE-MLKEM].  When hybrid key exchange is used, the
     key_exchange field of each KeyShareEntry in the initial handshake is
     formed by concatenating the key_exchange fields of the constituent
     algorithms.  This same approach is reused during the Extended Key
     Update, when new key shares are exchanged.

     The specification in [TLS-MLKEM] registers the lattice-based ML-KEM
     algorithm and its variants, such as ML-KEM-512, ML-KEM-768 and ML-
     KEM-1024.  The KEM encapsulation key or KEM ciphertext is represented
     as a 'KeyShareEntry' field.  This same approach is reused during the
     Extended Key Update, when new key shares are exchanged.

  9.  SSLKEYLOGFILE Update

     As a successful extended key update exchange invalidates previous
     secrets, SSLKEYLOGFILE [TLS-KEYLOGFILE] needs to be populated with
     new entries.  As a result, two additional secret labels are utilized
     in the SSLKEYLOGFILE:

     1.  CLIENT_TRAFFIC_SECRET_N+1: identifies the
         client_application_traffic_secret_N+1 in the key schedule

     2.  SERVER_TRAFFIC_SECRET_N+1: identifies the
         server_application_traffic_secret_N+1 in the key schedule

     3.  EXPORTER_SECRET_N+1: identifies the exporter_secret_N+1 in the
         key schedule

     Similar to other entries in the SSLKEYLOGFILE, the label is followed
     by the 32-byte value of the Random field from the ClientHello message
     that established the TLS connection, and the corresponding secret
     encoded in hexadecimal.

     SSLKEYLOGFILE entries for the extended key update MUST NOT be
     produced if SSLKEYLOGFILE was not used for other secrets in the
     handshake.

     Note that each successful Extended Key Update invalidates all
     previous SSLKEYLOGFILE secrets including past iterations of
     CLIENT_TRAFFIC_SECRET_, SERVER_TRAFFIC_SECRET_ and EXPORTER_SECRET_.

  10.  Exporter






  Tschofenig, et al.       Expires 23 August 2026                [Page 19]


  Internet-Draft         Extended Key Update for TLS         February 2026


  10.1.  Post-Compromise Security for the Initial Exporter Secret

     The TLS 1.3 Key Schedule, see Figure 5 of [TLS], derives the
     exporter_secret from the main secret.  This exporter_secret is static
     for the lifetime of the connection and is not updated by a standard
     key update.

     A core design goal of this specification is not met if the
     exporter_secret does not change.  Therefore, this document defines an
     exporter interface that derives a fresh exporter secret whenever new
     application traffic keys are updated through the EKU.

     If the initial exporter secret for this new interface were identical
     to exporter_secret, then compromising exporter_secret at any point
     during the lifetime of the connection would enable an attacker to
     recompute all exporter outputs derived from it.  This would break
     post-compromise security for exported keying material.

     Therefore, the initial exporter secret used by the exporter interface
     defined in this document, i.e., the exporter output available prior
     to the first Extended Key Update, MUST be distinct from the
     exporter_secret.  This separation ensures that compromise of the TLS
     exporter interface does not compromise outputs derived from the
     exporter interface defined in this document.

     Prior to the first Extended Key Update, the exporter interface
     provides an initial exporter secret, denoted exporter_secret_0.  This
     secret is derived from the TLS main secret and the handshake
     transcript, but is cryptographically independent of the TLS
     exporter_secret.  It is computed as follows:

     exporter_secret_0 =
     Derive-Secret(Main Secret,
     "exporter eku",
     Transcript-Hash(ClientHello..server Finished))

     Applications that require post-compromise security MUST use the
     exporter interface defined in this document.  This exporter interface
     is independent of the TLS exporter defined in Section 7.5 of [TLS],
     which continues to use a static exporter_secret for the lifetime of
     the connection for compatiblity with "legacy" applications.










  Tschofenig, et al.       Expires 23 August 2026                [Page 20]


  Internet-Draft         Extended Key Update for TLS         February 2026


  10.2.  Exporter Usage After Extended Key Update

     Protocols such as DTLS-SRTP and DTLS-over-SCTP rely on TLS or DTLS
     for key establishment, but reuse portions of the derived keying
     material for their own specific purposes.  These protocols use the
     TLS exporter defined in Section 7.5 of [TLS].  Exporters are also
     used for deriving authentication related values such as nonces, as
     described in [RFC9729].

     Once the Extended Key Update mechanism is complete, such protocols
     would need to use the newly derived exporter secret to generate
     Exported Keying Material (EKM) to protect packets.  The "sk" derived
     in the Section 7 will be used as the "Secret" in the exporter
     function, defined in Section 7.5 of [TLS], to generate EKM, ensuring
     that the exported keying material is aligned with the updated
     security context.  The newly derived exporter secret is
     cryptographically independent of previous exporter secrets.

     When a new exporter secret becomes active following a successful
     Extended Key Update, the TLS or DTLS implementation would have to
     provide an asynchronous notification to the application indicating
     that:

     *  A new epoch has become active, and the (D)TLS implementation can
        include the corresponding epoch identifier.  Applications
        receiving an epoch identifier can use it to request keying
        material for that specific epoch through an epoch-aware exporter
        interface.  In TLS, this identifier represents a local logical
        counter that may differ between peers.

     Applications are notified that a new epoch is active only after both
     peers have completed the Extended Key Update exchange and switched to
     the new traffic keys.

     *  In TLS, the initiator triggers notification after Step 5 in
        Section 5, and the responder triggers notification after Step 4 in
        Section 5.

     *  In DTLS, the initiator triggers notification to the application
        after Step 7 in Section 6, and the responder triggers notification
        after Step 9 in Section 6.

     The corresponding EKM is obtained by the application through the TLS/
     DTLS exporter interface using its chosen label and context values as
     defined in Section 4 of [RFC5705].






  Tschofenig, et al.       Expires 23 August 2026                [Page 21]


  Internet-Draft         Extended Key Update for TLS         February 2026


     To prevent desynchronization, the application will have to retain
     both the previous and the newly derived exporter secrets for a short
     period.  For TLS, the previous exporter secret would be discarded
     once data derived from the new exporter has been successfully
     processed, and no records protected with the old exporter secret are
     expected to arrive.  For DTLS, the previous exporter secret needs to
     be retained until the retention timer expires for the prior epoch, to
     allow for processing of packets that may arrive out of order.  The
     retention policy for exporter secrets is application-specific.  For
     example, in DTLS-SRTP, the application might retain the previous
     exporter secret until its replay window no longer accepts packets
     protected with keys derived from that secret, as described in
     Section 3.3.2 of [RFC3711].

  11.  Use of Post-Handshake Authentication and Exported Authenticators
       with Extended Key Update

     EKU provides fresh traffic secrets, but EKU alone does not
     authenticate that both endpoints derived the same updated keys.  An
     attacker that temporarily compromises an endpoint may later act as an
     active MitM capable of interfering with the EKU exchange.  Such an
     attacker can cause the peers to transition to divergent traffic
     secrets without detection, but cannot compromise the endpoint to
     derive secrets after the new epoch is established.  To confirm that
     both peers transitioned to the same new key state, TLS 1.3 provides
     two mechanisms: Post-Handshake Certificate-Based Client
     Authentication and Exported Authenticators [RFC9261].

  11.1.  Post-Handshake Certificate-Based Client Authentication

     When Post-Handshake Certificate-Based Client Authentication
     (Section 4.6.2 of [TLS]) is performed after an Extended Key Update
     (EKU) is complete, the Handshake Context used for the transcript hash
     is updated.  It consists of transcript_hash_N+1 concatenated with the
     CertificateRequest message.  The Finished message is computed using a
     MAC key derived from the Base Key of the new epoch
     (client_application_traffic_secret_N+1).  This confirms that both
     peers are operating with the same updated traffic keys and completes
     an authenticated transition after the EKU.

     To prevent cryptographic state ambiguity, the following constraints
     apply:

     *  A TLS server MUST NOT initiate a post-handshake CertificateRequest
        while an EKU exchange is in progress.






  Tschofenig, et al.       Expires 23 August 2026                [Page 22]


  Internet-Draft         Extended Key Update for TLS         February 2026


     *  If a CertificateRequest has been sent but the corresponding
        Finished message has not yet been received, the peers MUST NOT
        initiate an EKU exchange.

  11.2.  Exported Authenticators

     This document updates Section 5.1 of [RFC9261] to specify that, after
     an Extended Key Update has completed, the Handshake Context and
     Finished MAC Key used for Exported Authenticators MUST be derived
     from the exporter secret associated with the current epoch.
     Implementations that support the epoch-aware Exported Authenticators
     interface MUST provide a means for applications to request the
     generation or validation of Exported Authenticators using the
     exporter secret for a specific epoch.

     The Handshake Context and Finished MAC Key used in both the
     CertificateVerify message (Section 5.2.2 of [RFC9261]) and the
     Finished message (Section 5.2.3 of [RFC9261]) are derived from the
     exporter secret associated with the current epoch.  If a MitM
     interferes with the EKU exchange and causes the peers to derive
     different traffic and exporter secrets, their Handshake Contexts and
     Finished MAC Keys will differ.  As a result, validation procedures
     specified in Section 5.2.4 of [RFC9261] will fail, thereby detecting
     the divergence of key state between peers.

     A new optional API SHOULD be defined to permit applications to
     request or verify Exported Authenticators for a specific exporter
     epoch.  As discussed in Section 7 of [RFC9261], this can, as an
     exception, be implemented at the application layer when the epoch-
     aware TLS exporter is available.  The APIs defined in [RFC9261]
     remain unchanged, so existing applications continue to operate
     without modification.  The epoch-aware API accepts an epoch
     identifier; when present, the (D)TLS implementation MUST derive the
     Handshake Context and Finished MAC Key from the exporter secret
     associated with that epoch.  When Exported Authenticators are
     generated using the epoch-aware Exported Authenticators interface,
     the epoch identifier used for their derivation can be conveyed in the
     certificate_request_context field, allowing the peer, particularly in
     DTLS where records may be reordered, to determine the correct
     exporter secret for validation.

  12.  Security Considerations

     This section discusses additional security and operational aspects
     introduced by the Extended Key Update mechanism.  All security
     considerations of TLS 1.3 [TLS] and DTLS.13 [DTLS] continue to apply.





  Tschofenig, et al.       Expires 23 August 2026                [Page 23]


  Internet-Draft         Extended Key Update for TLS         February 2026


  12.1.  Scope of Key Compromise

     Extended Key Update assumes a transient compromise of the current
     application traffic keys, not a persistent attacker with ongoing
     access to key material.  The procedure itself does not rely on long-
     term private keys; those are assumed to remain secure, as they are
     typically stored in a secure element, such as a Trusted Execution
     Environment (TEE), Hardware Security Module (HSM), or Trusted
     Platform Module (TPM).  In contrast, application traffic keys are
     stored within the rich operating system, where short-term exposure
     due to memory disclosure or transient compromise may occur.  Post-
     compromise security can be re-established, provided the compromise is
     no longer active when an Extended Key Update is performed.

     Extended Key Update can restore confidentiality only if the attacker
     no longer has access to either peer.  If an adversary retains access
     to current application traffic keys and can act as a man-in-the-
     middle during the Extended Key Update, then the update cannot restore
     security unless Section 11 is used.

     If one of the mechanisms defined in Section 11 is not used, the
     attacker can impersonate each endpoint, substitute EKU messages, and
     maintain control of the communication.  When Post-handshake
     Certificate-Based Client Authentication or the modified Exported
     Authenticator mechanism is used, the authentication messages are
     bound to the keys established after the EKU.  Any modification or
     substitution of EKU messages therefore becomes detectable, preventing
     this attack.

     If a compromise occurs before the handshake completes, the ephemeral
     key exchange, client_handshake_traffic_secret,
     server_handshake_traffic_secret, and the initial client_/
     server_application_traffic_secret could be exposed.  In that case,
     only the initial handshake messages and the application data
     encrypted under the initial client_/server_application_traffic_secret
     can be decrypted until the Extended Key Update procedure completes.
     The Extended Key Update procedure derives fresh
     application_traffic_secrets from a new ephemeral key exchange,
     ensuring that all subsequent application data remains confidential.

  12.2.  Post-Compromise Security

     Extended Key Update provides post-compromise security for long-lived
     TLS sessions.  To ensure post-compromise security guarantees:

     *  Each update MUST use freshly generated ephemeral key-exchange
        material.  Implementations MUST NOT reuse ephemeral key-exchange
        material across updates or across TLS sessions.



  Tschofenig, et al.       Expires 23 August 2026                [Page 24]


  Internet-Draft         Extended Key Update for TLS         February 2026


  12.3.  Denial-of-Service (DoS)

     The Extended Key Update mechanism increases computational and state-
     management overhead.  A malicious peer could attempt to exhaust CPU
     or memory resources by initiating excessive update requests.

     Implementations SHOULD apply the following mitigations:

     *  Limit the frequency of accepted Extended Key Update requests per
        session.

     *  A peer that has sent an Extended Key Update MUST NOT initiate
        another until the previous update completes.  If a peer violates
        this rule, the receiving peer MUST treat it as a protocol
        violation, send an "unexpected_message" alert, and terminate the
        connection.

  12.4.  Operational Guidance

     Deployments SHOULD evaluate Extended Key Update performance under
     load and fault conditions, such as high-frequency or concurrent
     updates.  TLS policies SHOULD define explicit rate limits that
     balance post-compromise security benefits against potential DoS
     exposure.

  13.  IANA Considerations

  13.1.  TLS Flags

     IANA is requested to add the following entry to the "TLS Flags"
     extension registry [TLS-Ext-Registry]:

     *  Value: TBD1

     *  Flag Name: extended_key_update

     *  Messages: CH, EE

     *  Recommended: Y

     *  Reference: [This document]

  13.2.  TLS HandshakeType

     IANA is requested to add the following entry to the "TLS
     HandshakeType" registry [TLS-Ext-Registry]:

     *  Value: TBD2



  Tschofenig, et al.       Expires 23 August 2026                [Page 25]


  Internet-Draft         Extended Key Update for TLS         February 2026


     *  Description: extended_key_update

     *  DTLS-OK: Y

     *  Reference: [This document]

  13.3.  ExtendedKeyUpdate Message Subtypes Registry

     IANA is requested to create a new registry "TLS ExtendedKeyUpdate
     Message Subtypes", within the existing "Transport Layer Security
     (TLS) Parameters" registry [TLS-Ext-Registry].  This new registry
     reserves types used for Extended Key Update entries.  The initial
     contents of this registry are as follows.

           +=======+=====================+=========+===============+
           | Value | Description         | DTLS-OK | Reference     |
           +=======+=====================+=========+===============+
           | 0     | key_update_request  | Y       | This document |
           +-------+---------------------+---------+---------------+
           | 1     | key_update_response | Y       | This document |
           +-------+---------------------+---------+---------------+
           | 2     | new_key_update      | Y       | This document |
           +-------+---------------------+---------+---------------+
           | 3-255 | Unassigned          |         |               |
           +-------+---------------------+---------+---------------+

                                    Table 1

     New assignments in the "TLS ExtendedKeyUpdate Types" registry will be
     administered by IANA through Specification Required procedure
     [RFC8126].  The role of the designated expert is described in
     Section 17 of [RFC8447].  The designated expert [RFC8126] ensures
     that the specification is publicly available.  It is sufficient to
     have an Internet-Draft (that is posted and never published as an RFC)
     or to cite a document from another standards body, industry
     consortium, or any other location.  An expert may provide more in-
     depth reviews, but their approval should not be taken as an
     endorsement of the ExtendedKeyUpdate Message Subtype.

  13.4.  SSLKEYLOGFILE labels

     IANA is requested to add the following entries to the "TLS
     SSLKEYLOGFILE Labels" extension registry [TLS-Ext-Registry]:








  Tschofenig, et al.       Expires 23 August 2026                [Page 26]


  Internet-Draft         Extended Key Update for TLS         February 2026


     +===========================+=============+===========+============+
     | Value                     | Description | Reference | Comment    |
     +===========================+=============+===========+============+
     | CLIENT_TRAFFIC_SECRET_N+1 | Secret      | This      | N          |
     |                           | protecting  | document  | represents |
     |                           | client      |           | iteration  |
     |                           | records     |           | of         |
     |                           | after       |           | Extended   |
     |                           | Extended    |           | Key Update |
     |                           | Key Update  |           |            |
     +---------------------------+-------------+-----------+------------+
     | SERVER_TRAFFIC_SECRET_N+1 | Secret      | This      | N          |
     |                           | protecting  | document  | represents |
     |                           | server      |           | iteration  |
     |                           | records     |           | of         |
     |                           | after       |           | Extended   |
     |                           | Extended    |           | Key Update |
     |                           | Key Update  |           |            |
     +---------------------------+-------------+-----------+------------+
     | EXPORTER_SECRET_N+1       | Exporter    | This      | N          |
     |                           | secret      | document  | represents |
     |                           | after       |           | iteration  |
     |                           | Extended    |           | of         |
     |                           | Key Update  |           | Extended   |
     |                           |             |           | Key Update |
     +---------------------------+-------------+-----------+------------+

                                   Table 2

  14.  References

  14.1.  Normative References

     [DTLS]     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>.

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

     [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
                Norrman, "The Secure Real-time Transport Protocol (SRTP)",
                RFC 3711, DOI 10.17487/RFC3711, March 2004,
                <https://www.rfc-editor.org/rfc/rfc3711>.




  Tschofenig, et al.       Expires 23 August 2026                [Page 27]


  Internet-Draft         Extended Key Update for TLS         February 2026


     [RFC5705]  Rescorla, E., "Keying Material Exporters for Transport
                Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
                March 2010, <https://www.rfc-editor.org/rfc/rfc5705>.

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

     [RFC9261]  Sullivan, N., "Exported Authenticators in TLS", RFC 9261,
                DOI 10.17487/RFC9261, July 2022,
                <https://www.rfc-editor.org/rfc/rfc9261>.

     [RFC9729]  Schinazi, D., Oliver, D., and J. Hoyland, "The Concealed
                HTTP Authentication Scheme", RFC 9729,
                DOI 10.17487/RFC9729, February 2025,
                <https://www.rfc-editor.org/rfc/rfc9729>.

     [TLS]      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>.

     [TLS-FLAGS]
                Nir, Y., "A Flags Extension for TLS 1.3", Work in
                Progress, Internet-Draft, draft-ietf-tls-tlsflags-16, 14
                September 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-tls-tlsflags-16>.

  14.2.  Informative References

     [ANSSI]    ANSSI, "Recommendations for securing networks with IPsec,
                Technical Report", August 2015,
                <https://cyber.gouv.fr/sites/default/files/2012/09/
                NT_IPsec_EN.pdf>.

     [CCG16]    IEEE, "On Post-compromise Security", August 2016,
                <https://doi.org/10.1109/csf.2016.19>.

     [CONFIDENTIALITY]
                Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
                Trammell, B., Huitema, C., and D. Borkmann,
                "Confidentiality in the Face of Pervasive Surveillance: A
                Threat Model and Problem Statement", RFC 7624,
                DOI 10.17487/RFC7624, August 2015,
                <https://www.rfc-editor.org/rfc/rfc7624>.





  Tschofenig, et al.       Expires 23 August 2026                [Page 28]


  Internet-Draft         Extended Key Update for TLS         February 2026


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

     [RFC8447]  Salowey, J. and S. Turner, "IANA Registry Updates for TLS
                and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
                <https://www.rfc-editor.org/rfc/rfc8447>.

     [TLS-ECDHE-MLKEM]
                Kwiatkowski, K., Kampanakis, P., Westerbaan, B., and D.
                Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement
                for TLSv1.3", Work in Progress, Internet-Draft, draft-
                ietf-tls-ecdhe-mlkem-04, 8 February 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
                ecdhe-mlkem-04>.

     [TLS-Ext-Registry]
                IANA, "Transport Layer Security (TLS) Extensions",
                November 2023, <https://www.iana.org/assignments/tls-
                extensiontype-values>.

     [TLS-HYBRID]
                Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key
                exchange in TLS 1.3", Work in Progress, Internet-Draft,
                draft-ietf-tls-hybrid-design-16, 7 September 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
                hybrid-design-16>.

     [TLS-KEYLOGFILE]
                Thomson, M., Rosomakho, Y., and H. Tschofenig, "The
                SSLKEYLOGFILE Format for TLS", Work in Progress, Internet-
                Draft, draft-ietf-tls-keylogfile-05, 9 June 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
                keylogfile-05>.

     [TLS-MLKEM]
                Connolly, D., "ML-KEM Post-Quantum Key Agreement for TLS
                1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
                mlkem-07, 12 February 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
                mlkem-07>.

     [TLS-RENEGOTIATION]
                Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
                "Transport Layer Security (TLS) Renegotiation Indication
                Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
                <https://www.rfc-editor.org/rfc/rfc5746>.



  Tschofenig, et al.       Expires 23 August 2026                [Page 29]


  Internet-Draft         Extended Key Update for TLS         February 2026


  Appendix A.  Acknowledgments

     We would like to thank the members of the "TSVWG DTLS for SCTP
     Requirements Design Team" for their discussion.  The members, in no
     particular order, were:

     *  Marcelo Ricardo Leitner

     *  Zaheduzzaman Sarker

     *  Magnus Westerlund

     *  John Mattsson

     *  Claudio Porfiri

     *  Xin Long

     *  Michael Tüxen

     *  Hannes Tschofenig

     *  K Tirumaleswar Reddy

     *  Bertrand Rault

     Additionally, we would like to thank the chairs of the Transport and
     Services Working Group (tsvwg) Gorry Fairhurst and Marten Seemann as
     well as the responsible area director Martin Duke.

     Finally, we would like to thank Martin Thomson, Ilari Liusvaara,
     Benjamin Kaduk, Scott Fluhrer, Dennis Jackson, David Benjamin,
     Matthijs van Duin, Rifaat Shekh-Yusef, Joe Birr-Pixton, Eric
     Rescorla, and Thom Wiggers for their review comments.

  Appendix B.  State Machines

     The sections below describe the state machines for the extended key
     update operation for TLS 1.3 and DTLS 1.3.

     The state machine diagrams in the Appendix are provided for
     illustrative purposes only to aid understanding of the protocol flow.
     They are not normative.  In case of any discrepancy between the
     Appendix diagrams and the protocol behavior specified in the main
     body of this document, the text in the draft takes precedence.

     For editorial reasons we abbreviate the protocol message types:




  Tschofenig, et al.       Expires 23 August 2026                [Page 30]


  Internet-Draft         Extended Key Update for TLS         February 2026


     *  Req - ExtendedKeyUpdate(request)

     *  Resp - ExtendedKeyUpdate(response)

     *  NKU - ExtendedKeyUpdate(new_key_update)

     *  ACK - Acknowledgement message from Section 7 of [DTLS]

     *  APP - application data payloads

     In the (D)TLS 1.3 state machines discussed below, the terms SEND and
     RECEIVE keys refer to the send and receive key variables defined in
     Section 2.

     The TLS state machine diagrams use the following notation:

     *  Numbered labels (1), (2), … denote normal protocol transitions in
        the order they occur.

     *  Lettered labels (A), (B), … denote exceptional or conditional
        transitions.

     *  Self-loops indicate that the state does not change as a result of
        the event.

  B.1.  TLS 1.3 State Machines

     This section describes the initiator and responder state machines.

  B.1.1.  Initiator State Machine





















  Tschofenig, et al.       Expires 23 August 2026                [Page 31]


  Internet-Draft         Extended Key Update for TLS         February 2026


     +----------------------+
     | START                |
     | send_key=current,    |
     | receive_key=current  |
     | updating=0           |
     +----------------------+
           |
     (1) send Req with local KeyShareEntry
         set updating=1
           v
     +----------------------+
     | WAIT_RESP            |
     | updating=1           |
     +----------------------+
     |  \
     |   \ (A) recv peer Req (crossed updates):
     |    \  compare peer.key_exchange to local.key_exchange
     |     \  - if peer < local: IGNORE peer Req (send nothing)
     |      \ - if peer == local: ABORT "unexpected_message"
     |       \ - if peer > local: ABANDON local update:
     |          * set updating=0
     |          * act as RESPONDER: send Resp with KeyShareEntry,
     |            derive new secrets, then proceed as in responder flow
     |
     |  (2) recv Resp with key_share:
     |      derive new secrets
     |      send NKU (encrypted under old keys)
     |      update SEND key (send_key := new)
     |      update RECEIVE key (receive_key := new)
     |      set updating=0
            v
     +----------------------+
     | FINISHED             |
     +----------------------+

     Notes:

     *  NKU message is sent under old keys.

     *  If a classic KeyUpdate arrives (EKU negotiated), ABORT
        "unexpected_message".

     *  Crossed-requests: ignore the request with LOWER lexicographic
        key_exchange; if equal, abort.

  B.1.2.  Responder State Machine





  Tschofenig, et al.       Expires 23 August 2026                [Page 32]


  Internet-Draft         Extended Key Update for TLS         February 2026


     +----------------------+
     | START                |
     | send_key=current,    |
     | receive_key=current  |
     | updating=0           |
     +----------------------+
           |
     (1) recv Req
         set updating=1
           v
     +----------------------+
     | RESPOND              |
     +----------------------+
     |  send Resp with KeyShareEntry
     |  (may defer sending if under load;
     |   must send once resources free)
     |  derive new secrets
     |  update SEND keys (send_key := new)
     |  --> WAIT_I_NKU
           v
     +----------------------+
     | WAIT_I_NKU           |
     | updating=1           |
     +----------------------+
           |
     (2) recv NKU (encrypted under old keys)
         update RECEIVE keys (receive_key := new)
         set updating=0
           v
     +----------------------+
     | FINISHED             |
     +----------------------+

     Notes:

     *  Responder may defer Resp under load (no status reply), then must
        send it once resources are free.

     *  If a classic KeyUpdate arrives (EKU negotiated), ABORT
        "unexpected_message".

  B.2.  DTLS 1.3 State Machines

     This section describes the initiator and responder state machines.







  Tschofenig, et al.       Expires 23 August 2026                [Page 33]


  Internet-Draft         Extended Key Update for TLS         February 2026


  B.2.1.  Terms and Abbreviations

     The following variables and abbreviations are used in the state
     machine diagrams.

     *  rx - current, accepted receive epoch.

     *  tx - current transmit epoch used for tagging outgoing messages.

     *  E - initial epoch value.

     *  updating - true while a key-update handshake is in progress.

     *  old_rx - the previous receive epoch remembered during retention.

     *  retain_old - when true, receiver accepts tags old_rx and rx.

     *  tag=... - the TX-epoch value written on an outgoing message.

     *  e==... - the epoch tag carried on an incoming message (what the
        peer sent).

     *  FINISHED / START / WAIT_RESP / WAIT_I_NKU / WAIT_R_NKU / ACTIVATE
        RETENTION / RESPOND / WAIT_ACK - diagram states; FINISHED denotes
        the steady state after success.

     Crossed requests.  If both peers independently initiate the extended
     key update and the key_update_request messages cross in flight,
     compare the KeyShareEntry.key_exchange values.  The request with the
     lower lexicographic value must be ignored.  If the values are equal,
     the endpoint must abort with an "unexpected_message" alert.  If the
     peer's value is higher than the local one, the endpoint abandons its
     in-flight update and processes the peer's request as responder.

  B.2.2.  State Machine (Initiator)

     The initiator starts in the START state with matching epochs (rx :=
     E; tx := E).  It sends a Req and enters WAIT_RESP (updating := 1).
     While waiting, APP data may be sent at any time (tagged with the
     current tx) and received according to the APP acceptance rule below.

     Once the responder returns Resp with a tag matching the current rx,
     the initiator derives new key material.  It then sends NKU still
     tagged with the old tx.  The initiator activates retention mode: the
     old epoch is remembered, the receive epoch is incremented, and
     application data is accepted under both epochs for a transition
     period.  Initiator moves to WAIT_ACK.




  Tschofenig, et al.       Expires 23 August 2026                [Page 34]


  Internet-Draft         Extended Key Update for TLS         February 2026


     If a peer key_update_request arrives while in WAIT_RESP (crossed
     updates), apply the crossed-request rule above.  If the peer's
     key_exchange is higher, abandon the local update (updating := 0) and
     continue as responder: send key_update_response, derive new secrets,
     then proceed with the responder flow.  If lower, ignore the peer's
     request; if equal, abort with "unexpected_message".

     Upon receiving the responder's ACK matching the updated epoch, the
     initiator completes the transition by synchronizing transmit and
     receive epochs (tx := rx), disabling retention, and clearing the
     update flag.  The state machine returns to FINISHED, ready for
     subsequent updates.

     Throughout the process:

     *  Duplicate messages are tolerated (for retransmission handling).

     *  Temporary epoch mismatches are permitted while an update is in
        progress.

     *  Application data flows continuously, subject to epoch acceptance
        rules.

     +---------------------------------+
     | START                           |
     | rx := E; tx := E, updating := 0 |
     +---------------------------------+
           |
     (1) send Req [tag=tx]
         set updating := 1
           v
     +------------------------------+
     | WAIT_RESP                    |
     +------------------------------+
      ^    ^    ^           ^
      |    |    |           |
      |    |    |           |
      |    |    |           +-- (A) recv peer Req (crossed):
      |    |    |                if peer < local  -> IGNORE (Self-Loop)
      |    |    |                if peer == local -> ABORT  (Error)
      |    |    |                if peer > local  -> ABANDON update;
      |    |    |                                    updating := 0;
      |         |    |                                    act as RESPONDER
      |    |    |
      |    |    +-- APP send (anytime)           (Self-Loop)
      |    |
      |    +-- APP recv: retain_old && e == old_rx   (Self-Loop)
      |



  Tschofenig, et al.       Expires 23 August 2026                [Page 35]


  Internet-Draft         Extended Key Update for TLS         February 2026


      +-- APP recv: e == rx                           (Self-Loop)

               | recv Resp [e == rx]
               | derive secrets
               v
     +---------------------+
     | ACTIVATE RETENTION  |
     | old_rx=rx;          |
     | retain_old=1; rx++  |
     +---------------------+
               |
     (2) send NKU [tag=old tx]
               v
     +------------------------------+
     | WAIT_ACK (updating = 1)      |
     +------------------------------+
           |
           |  APP send/recv allowed
           |
     (3) recv ACK [e==rx]
         tx=rx; retain_old=0; updating := 0
           v
     +------------------------------------------+
     | FINISHED                                 |
     +------------------------------------------+

  B.2.3.  State Machine (Responder)

     The responder starts in the START state with synchronized transmit
     and receive epochs (rx := E; tx := E) and no update in progress.
     Application data can be transmitted at any time using the sender's
     current transmit epoch.  A receiver must accept application data if
     the epoch tag on the DTLS record equals the receiver's current
     receive epoch.  If the receiver has retention active (retain_old ==
     true), the receiver must also accept DTLS records whose epoch tag
     equals the remembered previous epoch.

     Upon receiving an ExtendedKeyUpdate(key_update_request) (Req), the
     responder transitions to RESPOND.  The responder may defer sending
     ExtendedKeyUpdate(key_update_response) under load; in that case it
     must acknowledge the request with an ACK and retransmit the response
     until it is acknowledged by the initiator, as specified in DTLS
     considerations.  When sent, ExtendedKeyUpdate(key_update_response) is
     tagged with the current tx.

     After an ExtendedKeyUpdate(new_key_update) (NKU) is received with the
     correct epoch, the responder:




  Tschofenig, et al.       Expires 23 August 2026                [Page 36]


  Internet-Draft         Extended Key Update for TLS         February 2026


     1.  activates retention (old_rx := rx; retain_old := 1),

     2.  increments both epochs (rx++, tx++),

     3.  sends ACK tagged with the new tx (which now equals the new rx),

     4.  clears updating and enters FINISHED.

     Retention at the responder ends automatically on the first APP
     received under the new rx (then retain_old := 0).  APP traffic is
     otherwise permitted at any time; reordering is tolerated by the
     acceptance rule.

     APP acceptance rule (receiver): accept if e == rx or (retain_old && e
     == old_rx).  If retain_old is set and an APP with the new rx arrives,
     clear retain_old.



































  Tschofenig, et al.       Expires 23 August 2026                [Page 37]


  Internet-Draft         Extended Key Update for TLS         February 2026


     +---------------------------------+
     | START                           |
     | rx := E; tx := E, updating := 0 |
     +---------------------------------+
           |
     (1) recv Req [e==rx]
         set updating := 1
           v
     +----------------------+
     | RESPOND              |
     +----------------------+
           |
           | send Resp [tag=tx]
           | (may defer; if deferred, ACK Req and later retransmit Resp
           |  until acknowledged by the initiator)
           v
     +---------------+
     | WAIT_I_NKU    |
     | (updating=1)  |
     +-------+-------+
           |
     (2) recv NKU [e==rx]      (assert accepted)
           |
     +---------------------+
     | ACTIVATE RETENTION  |
     | old_rx=rx;          |
     | retain_old=1;       |
     | rx=rx+1; tx=tx+1    |
     +----------+----------+
           |
     (3) send ACK [tag=tx]
         set updating := 0; assert tx==rx
           v
     +------------------------------------------+
     | FINISHED                                 |
     | (retain_old=0 after first APP at new rx) |
     +------------------------------------------+

  Appendix C.  Overview of Security Goals

     A complete security analysis of the EKU is outside the scope of this
     document.  This appendix provides an informal description of the
     primary security goals that EKU is designed to achieve.








  Tschofenig, et al.       Expires 23 August 2026                [Page 38]


  Internet-Draft         Extended Key Update for TLS         February 2026


  C.1.  Post-Compromise Security (PCS)

     Extended Key Update supports post-compromise security under the
     assumptions described in Section 12.1.  If an attacker temporarily
     compromises an endpoint and obtains the traffic keys in use before an
     Extended Key Update takes place, but the compromise does not persist
     after the EKU completes, the attacker cannot derive the new keying
     material established by EKU.  This property follows from the use of
     fresh ephemeral key exchange material during each Extended Key
     Update, which produces new traffic keys that are independent of the
     previous ones.  This property provides only best-effort post-
     compromise security, as it assumes the attacker is not acting as a
     MiTM during the Extended Key Update.

     As a result, confidentiality of application data encrypted after the
     Extended Key Update is preserved even if the earlier traffic keys
     were exposed.

  C.2.  Key Freshness and Cryptographic Independence

     Each Extended Key Update derives new traffic keys from ephemeral key
     exchange material.  This ensures strong separation between successive
     traffic keys:

     *  The new traffic keys established by an Extended Key Update are
        independent of the previous traffic keys.

     *  Compromise of one of traffic keys does not allow recovery of any
        earlier or later traffic keys.

     *  Application data protected under one of the traffic keys cannot be
        decrypted using keys from another.

  C.3.  Elimination of Standard KeyUpdate

     Once Extended Key Update has been negotiated for a session, peers
     rely exclusively on EKU rather than the standard TLS 1.3 KeyUpdate
     mechanism.  Relying solely on Extended Key Update helps maintain PCS
     properties throughout the lifetime of the TLS session.

  C.4.  Detecting Divergent Key State

     As described in Section 11, both Post-handshake Certificate-Based
     Client Authentication and Exported Authenticators can be used after
     an Extended Key Update to confirm that both endpoints derived the
     same traffic keys.  Because the authentication messages produced by
     these mechanisms depend on values derived from the updated traffic
     keys, any divergence in those traffic keys causes validation to fail,



  Tschofenig, et al.       Expires 23 August 2026                [Page 39]


  Internet-Draft         Extended Key Update for TLS         February 2026


     revealing interference by an active attacker.

  Authors' Addresses

     Hannes Tschofenig
     Siemens
     Email: hannes.tschofenig@gmx.net


     Michael Tüxen
     Münster Univ. of Applied Sciences
     Email: tuexen@fh-muenster.de


     Tirumaleswar Reddy
     Nokia
     Email: kondtir@gmail.com


     Steffen Fries
     Siemens
     Email: steffen.fries@siemens.com


     Yaroslav Rosomakho
     Zscaler
     Email: yrosomakho@zscaler.com
























  Tschofenig, et al.       Expires 23 August 2026                [Page 40]


name: draft-ietf-anima-constrained-voucher
rev: 30
title: Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)
time: 2026-02-27T12:49:46Z
group_uri: /api/v1/group/group/1956/
expires: 2026-08-31T12:49:46Z
shepherd: /api/v1/person/email/tte@cs.fau.de/
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/41/"]
categories: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014969+00:00
abstract:
  This document defines the Constrained Bootstrapping Remote Secure Key
     Infrastructure (cBRSKI) protocol, which provides a solution for
     secure zero-touch onboarding of resource-constrained (IoT) devices
     into the network of a domain owner.  This protocol is designed for
     constrained networks, which may have limited data throughput or may
     experience frequent packet loss. cBRSKI is a variant of the BRSKI
     protocol, which uses an artifact signed by the device manufacturer
     called the "voucher" which enables a new device and the owner's
     network to mutually authenticate.  While the BRSKI voucher data is
     encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher.  The
     BRSKI voucher data definition is extended with new data types that
     allow for smaller voucher sizes.  The Enrollment over Secure
     Transport (EST) protocol, used in BRSKI, is replaced with EST-over-
     CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP
     (CoAPS).  This document Updates RFC 8995 and RFC 9148.

full_text:
  anima Working Group                                        M. Richardson
  Internet-Draft                                  Sandelman Software Works
  Updates: 8995, 9148 (if approved)                        P. van der Stok
  Intended status: Standards Track                  vanderstok consultancy
  Expires: 31 August 2026                                    P. Kampanakis
                                                             Cisco Systems
                                                                   E. Dijk
                                                         IoTconsultancy.nl
                                                          27 February 2026


    Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)
                  draft-ietf-anima-constrained-voucher-30

  Abstract

     This document defines the Constrained Bootstrapping Remote Secure Key
     Infrastructure (cBRSKI) protocol, which provides a solution for
     secure zero-touch onboarding of resource-constrained (IoT) devices
     into the network of a domain owner.  This protocol is designed for
     constrained networks, which may have limited data throughput or may
     experience frequent packet loss. cBRSKI is a variant of the BRSKI
     protocol, which uses an artifact signed by the device manufacturer
     called the "voucher" which enables a new device and the owner's
     network to mutually authenticate.  While the BRSKI voucher data is
     encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher.  The
     BRSKI voucher data definition is extended with new data types that
     allow for smaller voucher sizes.  The Enrollment over Secure
     Transport (EST) protocol, used in BRSKI, is replaced with EST-over-
     CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP
     (CoAPS).  This document Updates RFC 8995 and RFC 9148.

  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-anima-constrained-
     voucher/.

     Discussion of this document takes place on the anima Working Group
     mailing list (mailto:anima@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/anima/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/anima/.

     Source for this draft and an issue tracker can be found at
     https://github.com/anima-wg/constrained-voucher.




  Richardson, et al.       Expires 31 August 2026                 [Page 1]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  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 31 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  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   7
     4.  Overview of Protocol  . . . . . . . . . . . . . . . . . . . .   7
     5.  Updates to RFC 8995 and RFC 9148  . . . . . . . . . . . . . .   9
     6.  BRSKI-EST Protocol  . . . . . . . . . . . . . . . . . . . . .  10
       6.1.  DTLS Connection . . . . . . . . . . . . . . . . . . . . .  10
         6.1.1.  DTLS Version  . . . . . . . . . . . . . . . . . . . .  10
         6.1.2.  TLS Client Certificates: IDevID authentication  . . .  10
         6.1.3.  DTLS Handshake Fragmentation Considerations . . . . .  11
         6.1.4.  Registrar and the Server Name Indicator (SNI) . . . .  11
         6.1.5.  Registrar Server Certificate Requirements . . . . . .  12
       6.2.  cBRSKI Join Proxy . . . . . . . . . . . . . . . . . . . .  12
       6.3.  Request URIs, Resource Discovery and Content-Formats  . .  12
         6.3.1.  Status Telemetry Returns  . . . . . . . . . . . . . .  14



  Richardson, et al.       Expires 31 August 2026                 [Page 2]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


         6.3.2.  CoAP Resources Table  . . . . . . . . . . . . . . . .  15
         6.3.3.  CoAP Uri-Path Abbreviation  . . . . . . . . . . . . .  15
       6.4.  CoAP Responses  . . . . . . . . . . . . . . . . . . . . .  15
       6.5.  Extensions to EST-coaps . . . . . . . . . . . . . . . . .  16
         6.5.1.  Pledge Enrollment Procedure . . . . . . . . . . . . .  16
         6.5.2.  Renewal of CA certificates  . . . . . . . . . . . . .  17
         6.5.3.  Change of Domain Trust Anchor(s)  . . . . . . . . . .  17
         6.5.4.  Re-enrollment Procedure . . . . . . . . . . . . . . .  18
         6.5.5.  Multipart Content-Format for CA certificates (/crts)
                 Resource  . . . . . . . . . . . . . . . . . . . . . .  19
       6.6.  Registrar Extensions  . . . . . . . . . . . . . . . . . .  20
     7.  BRSKI-MASA Protocol . . . . . . . . . . . . . . . . . . . . .  21
       7.1.  Protocol and Formats  . . . . . . . . . . . . . . . . . .  21
       7.2.  Registrar Voucher Request . . . . . . . . . . . . . . . .  22
       7.3.  MASA and the Server Name Indicator (SNI)  . . . . . . . .  22
       7.4.  Registrar Client Certificate Requirements . . . . . . . .  23
     8.  Pinning in Voucher Artifacts  . . . . . . . . . . . . . . . .  23
       8.1.  Registrar Identity Selection and Encoding . . . . . . . .  23
       8.2.  MASA Pinning Policy . . . . . . . . . . . . . . . . . . .  24
       8.3.  Pinning of Raw Public Keys (RPK)  . . . . . . . . . . . .  25
     9.  Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . .  26
       9.1.  Example Artifacts . . . . . . . . . . . . . . . . . . . .  27
         9.1.1.  Example Pledge Voucher Request (PVR) Artifact . . . .  27
         9.1.2.  Example Registrar Voucher Request (RVR) Artifact  . .  27
         9.1.3.  Example Voucher Artifacts . . . . . . . . . . . . . .  28
       9.2.  Signing Voucher and Voucher Request Artifacts with
             COSE  . . . . . . . . . . . . . . . . . . . . . . . . . .  29
         9.2.1.  Signing of Registrar Voucher Request (RVR)  . . . . .  30
         9.2.2.  Signing of Pledge Voucher Request (PVR) . . . . . . .  31
         9.2.3.  Signing of Voucher by MASA  . . . . . . . . . . . . .  32
         9.2.4.  Optional Validation of Voucher by Registrar . . . . .  34
         9.2.5.  Additional Information in the COSE Header . . . . . .  34
     10. Extensions to Discovery . . . . . . . . . . . . . . . . . . .  35
       10.1.  Discovery Operations by a Pledge . . . . . . . . . . . .  36
         10.1.1.  Examples . . . . . . . . . . . . . . . . . . . . . .  37
       10.2.  Discovery Operations by a Join Proxy . . . . . . . . . .  39
     11. Deployment-specific Discovery Considerations  . . . . . . . .  39
       11.1.  6TiSCH Deployments . . . . . . . . . . . . . . . . . . .  39
       11.2.  IP networks using GRASP  . . . . . . . . . . . . . . . .  39
       11.3.  IP networks using mDNS . . . . . . . . . . . . . . . . .  40
       11.4.  Thread Networks using Mesh Link Establishment (MLE)  . .  40
     12. Design and Implementation Considerations  . . . . . . . . . .  41
       12.1.  Voucher Format and Encoding  . . . . . . . . . . . . . .  41
       12.2.  CoAP Usage . . . . . . . . . . . . . . . . . . . . . . .  41
       12.3.  Use of cBRSKI with HTTPS . . . . . . . . . . . . . . . .  41
     13. Raw Public Key Variant  . . . . . . . . . . . . . . . . . . .  42
       13.1.  Introduction and Scope . . . . . . . . . . . . . . . . .  42
       13.2.  DTLS Connection and Registrar Trust Anchor . . . . . . .  42



  Richardson, et al.       Expires 31 August 2026                 [Page 3]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


       13.3.  The Pledge Voucher Request . . . . . . . . . . . . . . .  43
       13.4.  The Voucher Response . . . . . . . . . . . . . . . . . .  43
       13.5.  The Enrollment Phase . . . . . . . . . . . . . . . . . .  44
     14. Security Considerations . . . . . . . . . . . . . . . . . . .  44
       14.1.  Duplicate Serial Numbers . . . . . . . . . . . . . . . .  44
       14.2.  IDevID Security in the Pledge  . . . . . . . . . . . . .  45
       14.3.  Security of the BRSKI-MASA Protocol  . . . . . . . . . .  46
       14.4.  Registrar Certificate May Be Self-signed . . . . . . . .  47
       14.5.  Use of RPK Alternatives to 'proximity-registrar-cert'  .  47
     15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  48
       15.1.  Resource Type Link Target Attribute Values Registry  . .  48
       15.2.  Media Types Registry . . . . . . . . . . . . . . . . . .  48
         15.2.1.  application/voucher+cose . . . . . . . . . . . . . .  48
         15.2.2.  Interoperability Considerations for application/
                 voucher+cose  . . . . . . . . . . . . . . . . . . . .  49
       15.3.  CoAP Content-Formats Registry  . . . . . . . . . . . . .  50
       15.4.  Update to BRSKI Well-Known URIs Registry . . . . . . . .  50
       15.5.  Structured Syntax Suffixes Registry  . . . . . . . . . .  51
     16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  52
       16.1.  Normative References . . . . . . . . . . . . . . . . . .  52
       16.2.  Informative References . . . . . . . . . . . . . . . . .  56
     Appendix A.  Software and Library Support for cBRSKI  . . . . . .  58
       A.1.  Open Source cBRSKI Implementations  . . . . . . . . . . .  58
       A.2.  Security Library Support  . . . . . . . . . . . . . . . .  59
         A.2.1.  OpensSSL Example Code . . . . . . . . . . . . . . . .  60
         A.2.2.  mbedTLS Example Code  . . . . . . . . . . . . . . . .  61
       A.3.  Generating Certificates with OpenSSL  . . . . . . . . . .  61
     Appendix B.  cBRSKI Message Examples  . . . . . . . . . . . . . .  65
       B.1.  enrollstatus  . . . . . . . . . . . . . . . . . . . . . .  65
       B.2.  voucher_status  . . . . . . . . . . . . . . . . . . . . .  67
     Appendix C.  COSE-signed Voucher (Request) Examples . . . . . . .  68
       C.1.  Pledge, Registrar and MASA Keys . . . . . . . . . . . . .  68
         C.1.1.  Pledge IDevID Private Key . . . . . . . . . . . . . .  68
         C.1.2.  Registrar Private Key . . . . . . . . . . . . . . . .  68
         C.1.3.  MASA Private Key  . . . . . . . . . . . . . . . . . .  69
       C.2.  Pledge, Registrar, Domain CA and MASA Certificates  . . .  69
         C.2.1.  Pledge IDevID Certificate . . . . . . . . . . . . . .  69
         C.2.2.  Registrar Certificate . . . . . . . . . . . . . . . .  71
         C.2.3.  Domain CA Certificate . . . . . . . . . . . . . . . .  73
         C.2.4.  MASA Certificate  . . . . . . . . . . . . . . . . . .  75
       C.3.  COSE-signed Pledge Voucher Request (PVR)  . . . . . . . .  77
       C.4.  COSE-signed Registrar Voucher Request (RVR) . . . . . . .  78
       C.5.  COSE-signed Voucher from MASA . . . . . . . . . . . . . .  81
     Appendix D.  Pledge Device Class Profiles . . . . . . . . . . . .  83
       D.1.  Minimal Pledge  . . . . . . . . . . . . . . . . . . . . .  83
       D.2.  Typical Pledge  . . . . . . . . . . . . . . . . . . . . .  83
       D.3.  Full-featured Pledge  . . . . . . . . . . . . . . . . . .  84
       D.4.  Comparison Chart of Pledge Classes  . . . . . . . . . . .  84



  Richardson, et al.       Expires 31 August 2026                 [Page 4]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Appendix E.  Pledge Discovery of Onboarding and Enrollment
             Options . . . . . . . . . . . . . . . . . . . . . . . . .  86
       E.1.  Pledge Discovery Query for All cBRSKI Resources . . . . .  86
       E.2.  Pledge Discovery Query for the cBRSKI Base Resource . . .  88
       E.3.  Usage of ct Attribute . . . . . . . . . . . . . . . . . .  88
       E.4.  EST-coaps Resource Discovery  . . . . . . . . . . . . . .  89
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  90
     Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . .  91
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  93

  1.  Introduction

     Secure enrollment of new nodes into constrained networks with
     constrained nodes presents unique challenges.  As explained in
     [RFC7228], such networks may have limited data throughput or may
     experience frequent packet loss.  In addition, its nodes may be
     constrained by energy availability, memory space, and code size.

     The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol
     described in [RFC8995] provides a solution for secure zero-touch
     (automated) onboarding of new (unconfigured) devices.  These new
     devices are called "Pledges", equipped with a factory-installed
     Initial Device Identifier (IDevID) (see [ieee802-1AR]).  Using the
     IDevID, a Pledge is securely enrolled into a network.

     The BRSKI solution described in [RFC8995] was designed to be modular,
     and this document describes a version scaled to the constraints of
     IoT deployments.  This document uses the constrained voucher and
     voucher request artifacts defined in [RFC8366bis] for a constrained
     version of the BRSKI protocol: cBRSKI.  The cBRSKI protocol uses the
     CoAP-based version of EST (EST-coaps from [RFC9148]) rather than the
     EST over HTTPS [RFC7030].  cBRSKI is itself scalable to multiple
     resource levels through the definition of optional functions.
     Appendix D illustrates this.

     In BRSKI, the [RFC8366bis] voucher data is by default serialized to
     JSON with a signature in CMS [RFC5652]. cBRSKI uses the CBOR
     [RFC8949] voucher data serialization defined by [RFC8366bis], and
     applies a new COSE [RFC9052] signature format as defined in
     Section 9.

     This COSE-signed CBOR-encoded voucher is transported using both
     secured CoAP [RFC7252] and HTTPS.  The CoAP connection (between
     Pledge and Registrar) is to be protected by DTLS (CoAPS).  The HTTP
     connection (between Registrar and MASA) is to be protected using TLS
     (HTTPS).





  Richardson, et al.       Expires 31 August 2026                 [Page 5]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Section 4 to Section 10 define the default cBRSKI protocol, by means
     of additions to and modifications of regular BRSKI.  Section 11
     considers some variations of the protocol, specific to particular
     deployments or IoT networking technologies.  Next in Section 12, some
     considerations for the design and implementation of cBRSKI components
     are provided.

     Section 13 introduces a variant of cBRSKI for the most-constrained
     Pledges, using Raw Public Keys (RPK).  This variant achieves smaller
     sizes of data objects and avoids doing certain costly PKIX
     verification operations on the Pledge.

     Appendix E provides more details on how a Pledge may discover the
     various onboarding/enrollment options that a Registrar provides.
     Implementing these methods is optional for a Pledge.

  2.  Terminology

     The following terms are defined in [RFC8366bis], and are used
     identically as in that document: Artifact, Attribute, Domain, Join
     Registrar and Coordinator (JRC), Malicious Registrar, Manufacturer
     Authorized Signing Authority (MASA), Pledge, Registrar, Onboarding,
     Owner, Voucher Data, Voucher Request and Voucher.

     The protocol described in this document is referred to as cBRSKI, the
     constrained version of BRSKI [RFC8995].

     The following terms from [RFC8995] are used identically as in that
     document: Domain CA, enrollment, IDevID, Join Proxy, LDevID,
     manufacturer, nonced, nonceless, PKIX.

     The following terms from [RFC7030] are used identically as in that
     document: Explicit Trust Anchor (TA), Explicit TA database, Third-
     party TA.

     The following terms from [RFC7252] are used identically as in that
     document: Confirmable (CON), Acknowledgement (ACK), Endpoint, ETag,
     Client, Server, Piggybacked Response, resource, Resource Discovery,
     Content-Format.

     The term Pledge Voucher Request, or acronym PVR, is introduced to
     refer to the voucher request between the Pledge and the Registrar.

     The term Registrar Voucher Request, or acronym RVR, is introduced to
     refer to the voucher request between the Registrar and the MASA.

     The terms "PKIX Certificate" and "certificate" both refer to the
     X.509v3 profile described in [RFC5280].



  Richardson, et al.       Expires 31 August 2026                 [Page 6]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     The term "base resource" is defined as a CoAP resource that can be
     used as a base to append an additional path segment to, where this
     segment is a short resource name ('short-name') as defined in
     Section 6.3 and Table 1.

     In code examples, the string "<CODE BEGINS>" denotes the start of a
     code example and "<CODE ENDS>" the end of the code example. "lf
     added" means that extra linefeed characters were added to an example
     to make lines fit in this document.

     The ellipsis ("...") in a CBOR diagnostic notation byte string
     denotes a further sequence of bytes that is not shown for brevity.
     This notation is defined in [I-D.ietf-cbor-edn-literals].

  3.  Requirements Language

     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.

  4.  Overview of Protocol

     [RFC8366bis] defines a voucher that can assert proximity,
     authenticates the Registrar, and can offer varying levels of anti-
     replay protection.  The proximity proof provided by a voucher is an
     assertion that the Pledge and the Registrar are believed to be close
     together, from a network topology point of view.  Similar to BRSKI
     [RFC8995], proximity is proven by making a DTLS connection between a
     Pledge and a Registrar.  The Pledge initiates this connection using a
     link-local source address.

     The secure DTLS connection is then used by the Pledge to send a
     Pledge Voucher Request (PVR).  The Registrar then includes the PVR
     into its own Registrar Voucher Request (RVR), which is sent to an
     agent (MASA) of the Pledge's manufacturer.  The MASA verifies the PVR
     and RVR and issues a signed voucher.  The voucher provides an
     authorization statement from the manufacturer indicating that the
     Registrar is the intended owner of the Pledge.  The voucher refers to
     the Registrar through pinning of the Registrar's identity.










  Richardson, et al.       Expires 31 August 2026                 [Page 7]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     After verification of the voucher, the Pledge enrolls into the
     Registrar's domain by obtaining a certificate using the EST-coaps
     [RFC9148] protocol, suitable for constrained devices.  Once the
     Pledge has obtained its domain identity (LDevID) in this manner, it
     can use this identity to obtain network access credentials, which are
     used to join the local IP network.  The method to obtain such
     credentials depends on the particular network technology used and is
     outside the scope of this document.

     The two main parts of the BRSKI protocol are named separately in this
     document: BRSKI-EST (Section 6) for the protocol between Pledge and
     Registrar, and BRSKI-MASA (Section 7) for the protocol between the
     Registrar and the MASA.

     Time-based vouchers are supported, but given that constrained devices
     are unlikely to have accurate time, their use will be uncommon.  Most
     Pledges using constrained vouchers will be online during enrollment
     and will use live nonces to provide anti-replay protection rather
     than expiry times.

     [RFC8366bis] defines the CBOR voucher data encoding for the
     constrained voucher and the constrained voucher request, which are
     used by cBRSKI.

     The constrained voucher request MUST be signed by the Pledge.  COSE
     [RFC9052] is used for signing as defined in Section 9.2.  It signs
     using the private key of its IDevID.  The constrained voucher MUST be
     signed by the MASA.  Also in this case, COSE is used for signing.

     For the constrained voucher request (PVR) the default method for the
     Pledge to identify the Registrar is using the Registrar's full PKIX
     certificate.  But when operating PKIX-less as described in
     Section 13, the Registrar's Raw Public Key (RPK) is used for this.

     For the constrained voucher the default method to indicate ("pin") a
     trusted domain identity is the domain's PKIX CA certificate, but when
     operating PKIX-less instead the RPK of the Registrar is pinned.

     For certificates, cBRSKI currently uses the X.509 format, like BRSKI.
     The protocol and data formats are defined such that future extension
     to other certificate formats is enabled.  For example, CBOR-encoded
     and COSE-signed C509 certificates ([I-D.ietf-cose-cbor-encoded-cert])
     may provide data size savings as well as code sharing benefits with
     CBOR/COSE libraries, when applied to cBRSKI.

     The BRSKI architecture mandates that the MASA be aware of the
     capabilities of the Pledge.  This is not a drawback as a Pledge is
     constructed by a manufacturer which also arranges for the MASA to be



  Richardson, et al.       Expires 31 August 2026                 [Page 8]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     aware of the inventory of devices.  The MASA therefore knows if the
     Pledge supports PKIX operations, or if it is limited to RPK
     operations only.  Based upon this, the MASA can select which
     attributes to use in the voucher for certain operations, like the
     pinning of the Registrar or domain identity.

  5.  Updates to RFC 8995 and RFC 9148

     This section details the ways in which this document updates other
     RFCs.

     This document Updates [RFC8995] because it:

     *  clarifies how pinning in vouchers is done (Section 8),

     *  clarifies the use of TLS Server Name Indicator (SNI)
        (Section 6.1.4, Section 7.3),

     *  clarifies when new trust anchors should be retrieved by a Pledge
        (Section 6.5.1),

     *  clarifies what kinds of Extended Key Usage attributes are
        appropriate for each certificate (Section 6.1.5, Section 7.4),

     *  extends BRSKI with the use of CoAP,

     *  makes some BRSKI messages optional to send if the results can be
        inferred from other validations (Section 6.5),

     *  extends the BRSKI-EST/BRSKI-MASA protocols (Section 6, Section 7,
        Section 9.2) to carry the new application/voucher+cose format.

     This document Updates [RFC9148] because it:

     *  defines stricter DTLS requirements (Section 6.1)),

     *  details how an EST-coaps client handles certificate renewal and
        re-enrollment (Section 6.5),

     *  details how an EST-coaps server processes a "CA certificates"
        request for content-format 287 (application/pkix-cert)
        (Section 6.6).

     *  adds enrollment status telemetry to the certificate renewal
        procedure (Section 6.5.4),

     *  adds support for the media type application/multipart-core for the
        CA certificates (/crts) resource (Section 6.5.5),



  Richardson, et al.       Expires 31 August 2026                 [Page 9]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     *  defines a resource type ('rt') attribute value "ace.est" for the
        EST-coaps base resource (Section 15.1).

  6.  BRSKI-EST Protocol

     This section describes the extensions to both BRSKI [RFC8995] and
     EST-coaps [RFC9148] operations between Pledge and Registrar.

  6.1.  DTLS Connection

     A DTLS connection is established between the Pledge and the
     Registrar, similar to the TLS connection described in Section 5.1 of
     [RFC8995].  This may occur via a Join Proxy as described in
     Section 6.2.  Regardless of the Join Proxy presence or particular
     mechanism used, the DTLS connection should operate identically.  The
     cBRSKI and EST-coaps requests and responses for onboarding are
     carried over this DTLS connection.

  6.1.1.  DTLS Version

     DTLS version 1.3 [RFC9147] SHOULD be used in any implementation of
     this specification.  An exception case where DTLS 1.2 [RFC6347] MAY
     be used is in a Pledge that uses a software platform where a DTLS 1.3
     client is not available (yet).  This may occur for example if a
     legacy device gets software-upgraded to support cBRSKI.  For this
     reason, a Registrar MUST by default support both DTLS 1.3 and DTLS
     1.2 client connections.  However, for security reasons the Registrar
     MAY be administratively configured to support only a particular DTLS
     version or higher.

     An EST-coaps server [RFC9148] (if present as a separate entity from
     above Registrar) that implements this specification also MUST support
     both DTLS 1.3 and DTLS 1.2 client connections by default.  However,
     for security reasons the EST-coaps server MAY be administratively
     configured to support only a particular DTLS version or higher.

  6.1.2.  TLS Client Certificates: IDevID authentication

     As described in Section 5.1 of [RFC8995], the Pledge makes a
     connection to the Registrar using a TLS Client Certificate for
     authentication.  This is the Pledge's IDevID certificate.

     Subsequently the Pledge will send a Pledge Voucher Request (PVR).
     Further elements of Pledge authentication may be present in the PVR,
     as detailed in Section 9.2.






  Richardson, et al.       Expires 31 August 2026                [Page 10]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  6.1.3.  DTLS Handshake Fragmentation Considerations

     DTLS includes a mechanism to fragment handshake messages.  This is
     described in Section 4.4 of [RFC9147]. cBRSKI will often be used with
     a Join Proxy, described in Section 6.2, which relays each DTLS
     message to the Registrar.  A stateless Join Proxy will need some
     additional space to wrap each DTLS message inside a Join Proxy UDP
     message, while the wrapped result needs to fit in the maximum IPv6
     MTU guaranteed on 6LoWPAN [RFC6282] networks, which is 1280 bytes.

     For this reason it is RECOMMENDED that a PMTU of 1024 bytes be
     assumed for the DTLS handshake and appropriate DTLS fragmentation is
     used.  It is unlikely that any ICMPv6 Packet Too Big indications
     ([RFC4443]) will be relayed by the Join Proxy back to the Pledge.

     During the operation of the EST-coaps protocol, the CoAP Block-wise
     transfer mechanism [RFC7959] will be automatically used when message
     sizes exceed the PMTU.  A Pledge/EST-client on a constrained network
     MUST use the (D)TLS maximum fragment length extension
     ('max_fragment_length') defined in Section 4 of [RFC6066] with the
     maximum fragment length set to a value of either 2^9 or 2^10, when
     operating as a DTLS 1.2 client.

     A Pledge/EST-client operating as DTLS 1.3 client, MUST use the (D)TLS
     record size limit extensions ('record_size_limit') defined in
     Section 4 of [RFC8449], with RecordSizeLimit set to a value between
     512 and 1024 (inclusive).

  6.1.4.  Registrar and the Server Name Indicator (SNI)

     The SNI issue described below affects [RFC8995] as well, and is
     reported in errata: https://www.rfc-editor.org/errata/eid6648
     (https://www.rfc-editor.org/errata/eid6648)

     As the Registrar is discovered by IP address, and typically connected
     via a Join Proxy, the hostname of the Registrar is not known to the
     Pledge.  Therefore, it cannot do DNS-ID validation ([RFC9525]) on the
     Registrar's certificate.  Instead, it must do validation using the
     voucher.

     Without knowing the hostname, the Pledge cannot put any reasonable
     value into the [RFC6066] Server Name Indicator (SNI) extension.
     Therefore the Pledge SHOULD omit the SNI extension as per Section 9.2
     of [RFC8446].

     In some cases, particularly while testing BRSKI, a Pledge may be
     given the hostname of a particular Registrar to connect to directly.
     Such a bypass of the discovery process may result in the Pledge



  Richardson, et al.       Expires 31 August 2026                [Page 11]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     taking a different code branch to establish a DTLS connection, and
     may result in the SNI being inserted by a library.  For this reason,
     the Registrar MUST ignore any SNI it receives from a Pledge.

     A primary motivation for making the SNI ubiquitous in the public web
     is because it allows for multi-tenant hosting of HTTPS sites on a
     single (scarce) IPv4 address.  This consideration does not apply to
     the server function in the Registrar because:

     *  it uses DTLS and CoAP, not HTTPS;

     *  it typically uses IPv6, often [RFC4193] Unique Local Address,
        which are plentiful;

     *  the server port number is typically discovered, so multiple
        tenants can be accommodated via unique UDP port numbers.

  6.1.5.  Registrar Server Certificate Requirements

     As per Section 3.6.1 of [RFC7030], the Registrar certificate MUST
     have the Extended Key Usage (EKU) id-kp-cmcRA.  This certificate is
     also used as a TLS Server Certificate, so it MUST also have the EKU
     id-kp-serverAuth.

     See Appendix C.2.2 for an example of a Registrar certificate with
     these EKUs set.  See Section 7.4 for Registrar client certificate
     requirements.

  6.2.  cBRSKI Join Proxy

     [I-D.ietf-anima-constrained-join-proxy] specifies the details for a
     stateful or stateless constrained Join Proxy which is equivalent to
     the BRSKI Proxy defined in [RFC8995], Section 4.  See also Section 10
     for more details on discovery of a Join Proxy by a Pledge, and
     discovery of a Registrar by a Join Proxy.

  6.3.  Request URIs, Resource Discovery and Content-Formats

     cBRSKI operates using CoAP over DTLS, with request URIs using the
     coaps scheme.  The Pledge operates in CoAP client role.  To keep the
     protocol messages small the EST-coaps and cBRSKI request URIs are
     shorter than the respective EST and BRSKI URIs.

     During the cBRSKI onboarding on an IPv6 network these request URIs
     have the following form:

       coaps://[<link-local-ipv6>]:<port>/.well-known/brski/<short-name>
       coaps://[<link-local-ipv6>]:<port>/.well-known/est/<short-name>



  Richardson, et al.       Expires 31 August 2026                [Page 12]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     where <link-local-ipv6> is the discovered link-local IPv6 address of
     a Join Proxy, and <port> is the discovered port of the Join Proxy
     that is used to offer the cBRSKI proxy functionality.

     <short-name> is the short resource name for the cBRSKI and EST-coaps
     resources.  For EST-coaps, Section 5.1 of [RFC9148] defines the CoAP
     <short-name> resource names.  For cBRSKI, this document defines the
     short resource names based on the [RFC8995] long HTTP resource names.
     See Table 1 for a summary of these resource names.

     Section 11 details how the Pledge discovers a Join Proxy link-local
     address and port in different deployment scenarios.

     The request URI formats defined here enable the Pledge to perform
     onboarding/enrollment without requiring discovery of the available
     onboarding options, voucher formats, BRSKI/EST resources, enrollment
     protocols, and so on.  This is helpful for the majority of
     constrained Pledges that would support only a single set of these
     options.  However, for Pledges that do support multiple options,
     [I-D.ietf-anima-brski-discovery] will define discovery methods so
     that a Pledge can select the optimal set of options for the current
     onboarding operation.

     Alternatively, a Pledge could also send CoAP discovery queries
     (Section 7 of [RFC7252]) to the Registrar to discover detailed
     options for onboarding and/or enrollment functions.  Supporting these
     queries is OPTIONAL for both the Pledge and the Registrar.  To
     clarify which options in particular can be discovered, Appendix E
     provides an informative overview of what can be discovered and how to
     discover it.

     Because a Pledge only has indirect access to the Registrar via a
     single port on the Join Proxy, the Registrar MUST host all cBRSKI/
     EST-coaps resources on the same (UDP) server IP address and port.
     This is the address and port where a Join Proxy would relay DTLS
     records from the Pledge to.

     Although the request URI templates include IP address, scheme and
     port, in practice the CoAP request message sent over the secure DTLS
     connection only encodes the URI path explicitly.  For example, a
     Pledge that skips resource discovery operations just sends the
     initial CoAP voucher request as follows:

       REQ: POST /.well-known/brski/rv
         Content-Format: 836 (application/voucher+cose)
         Payload       : (COSE-signed Pledge Voucher Request, PVR)





  Richardson, et al.       Expires 31 August 2026                [Page 13]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Note that only content-format 836 (application/voucher+cose) is
     defined in this document for the payload sent to the voucher request
     resource (/rv).  Content-format 836 MUST be supported by the
     Registrar for the /rv resource and it MAY support additional formats.
     The Pledge MAY also indicate in the request the desired format of the
     (voucher) response, using the Accept Option.  An example of using
     this option in the request is as follows:

       REQ: POST /.well-known/brski/rv
         Content-Format: 836 (application/voucher+cose)
         Accept        : 836 (application/voucher+cose)
         Payload       : (COSE-signed Pledge Voucher Request, PVR)

     If the Accept Option is omitted in the request, the response format
     follows from the request payload format (which is 836).

     Note that this specification allows for application/voucher+cose
     format requests and vouchers to be transported over HTTPS, as well as
     for application/voucher-cms+json and other formats yet to be defined
     over CoAP.  The burden for this flexibility is placed upon the
     Registrar.  A Pledge on constrained hardware is expected to support a
     single format only.

     The Pledge and MASA need to support one or more formats (at least
     format 836) for the voucher and for the voucher request.  The MASA
     needs to support all formats that the Pledge supports.

  6.3.1.  Status Telemetry Returns

     [RFC8995] defines two telemetry returns from the Pledge which are
     sent to the Registrar.  These are the BRSKI Status Telemetry
     [RFC8995], Section 5.7 and the Enrollment Status Telemetry [RFC8995],
     Section 5.9.4.  These are two CoAP POST requests made the by Pledge
     at two key steps in the process.

     [RFC8995] defines the content of these POST operations in CDDL, which
     are serialized as JSON.  This document extends this with an
     additional CBOR format, derived using the CDDL rules in [RFC8610].

     The new CBOR telemetry format has CoAP content-format 60
     (application/cbor) and MUST be supported by the Registrar for both
     the /vs and /es resources.  The existing JSON format has CoAP
     content-format 50 (application/json) and MAY also be supported by the
     Registrar.  A Pledge MUST use the new CBOR format to send telemetry
     messages.






  Richardson, et al.       Expires 31 August 2026                [Page 14]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  6.3.2.  CoAP Resources Table

     cBRSKI inherits EST-coaps [RFC9148] functions: specifically, the
     mandatory Simple (Re-)Enrollment (/sen and /sren) and Certification
     Authority certificates request (/crts).  Support for CSR Attributes
     Request (/att) and server-side key generation (/skg, /skc) remains
     optional for the EST-coaps server.

     Table 1 summarizes the resources used in cBRSKI.  It includes both
     the short-name cBRSKI resources and the EST-coaps resources.

     +=================+====================+===============+============+
     | BRSKI + EST     | cBRSKI + EST-coaps | Well-known    | Required   |
     | name            | <short-name>       | URI           | for        |
     |                 |                    | namespace     | Registrar? |
     +=================+====================+===============+============+
     | /enrollstatus   | /es                | brski         | MUST       |
     +-----------------+--------------------+---------------+------------+
     | /requestvoucher | /rv                | brski         | MUST       |
     +-----------------+--------------------+---------------+------------+
     | /voucher_status | /vs                | brski         | MUST       |
     +-----------------+--------------------+---------------+------------+
     | /cacerts        | /crts              | est           | MUST       |
     +-----------------+--------------------+---------------+------------+
     | /csrattrs       | /att               | est           | MAY        |
     +-----------------+--------------------+---------------+------------+
     | /simpleenroll   | /sen               | est           | MUST       |
     +-----------------+--------------------+---------------+------------+
     | /simplereenroll | /sren              | est           | MUST       |
     +-----------------+--------------------+---------------+------------+
     | /serverkeygen   | /skg               | est           | MAY        |
     +-----------------+--------------------+---------------+------------+
     | /serverkeygen   | /skc               | est           | MAY        |
     +-----------------+--------------------+---------------+------------+

          Table 1: BRSKI/EST resource name mapping to cBRSKI/EST-coaps
                              short resource name

  6.3.3.  CoAP Uri-Path Abbreviation

     To minimize the size of CoAP request packets on constrained networks,
     the CoAP Uri-Path-Abbrev Option defined in
     [I-D.ietf-core-uri-path-abbrev] MUST be supported by the Registrar.

  6.4.  CoAP Responses

     [RFC8995], Section 5 defines a number of HTTP response codes that the
     Registrar is to return when certain conditions occur.



  Richardson, et al.       Expires 31 August 2026                [Page 15]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     The 401, 403, 404, 406 and 415 response codes map directly to CoAP
     codes 4.01, 4.03, 4.04, 4.06 and 4.15 respectively.

     The 202 Retry process which may occur in the voucher request, is to
     be handled in the same way as the Section 5.7 of [RFC9148] process
     for Delayed Responses.

  6.5.  Extensions to EST-coaps

     This section defines extensions to EST-coaps for Pledges (during
     initial onboarding), EST-coaps clients (after initial onboarding) and
     Registrars (that implement an EST-coaps server).  Note that a device
     that is already onboarded is not called "Pledge" in this section: it
     now acts in the role of an EST-coaps client.

  6.5.1.  Pledge Enrollment Procedure

     This section defines optimizations for the EST-coaps protocol as used
     by a Pledge.  These aim to reduce payload sizes and the number of
     messages (round-trips) required for the initial EST enrollment.

     A Pledge SHOULD NOT perform the optional EST-coaps "CSR attributes
     request" (/att).  Instead, the Pledge selects the attributes to
     include in the CSR as specified below.

     One or more Subject Distinguished Name fields MUST be included in the
     CSR.  If the Pledge has no specific information on what attributes/
     fields are desired in the CSR, which is the common case, it MUST use
     the Subject Distinguished Name fields from its IDevID unmodified.
     Note that a Pledge MAY receive such specific information via the
     voucher data (encoded in a vendor-specific way, or as defined by a
     future specification) or via some other, out-of-band means.

     A Pledge uses the following optimized EST-coaps procedure:

     1.  If the voucher, that validates the current Registrar, contains a
         single pinned domain CA certificate, the Pledge provisionally
         considers this certificate as the EST trust anchor, as if it were
         the result of a "CA certificates request" (/crts) to the
         Registrar.

     2.  Using this CA certificate as trust anchor it proceeds with EST
         simple enrollment (/sen) to obtain a provisionally trusted LDevID
         certificate.

     3.  If the Pledge determines that the pinned domain CA is (1) a root
         CA certificate and (2) signer of the LDevID certificate, the
         Pledge accepts the pinned domain CA certificate as the legitimate



  Richardson, et al.       Expires 31 August 2026                [Page 16]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


         trust anchor root CA for the Registrar's domain.  It also accepts
         the LDevID certificate as its new LDevID identity.  And steps 4
         and 5 are skipped.

     4.  Otherwise, if the step 3 condition was not met, the Pledge MUST
         perform a "CA certificates request" (/crts) to the EST server to
         obtain the full set of EST CA trust anchors.  It then MUST
         attempt to chain the LDevID certificate to one of the CAs in the
         set.

     5.  If the Pledge cannot obtain the set of CA certificates, or it is
         unable to create the chain as defined in step 4, the Pledge MUST
         abort the enrollment process and report the error using the
         enrollment status telemetry (/es).

  6.5.2.  Renewal of CA certificates

     An EST-coaps client that has an idea of the current time (internally,
     or via Network Time Protocol) SHOULD consider the validity time of
     the trust anchor CA(s), and MAY begin requesting new trust anchor
     certificates(s) using the /crts request when the CA has 50% of it's
     validity time (notAfter - notBefore) left.  A client without access
     to the current time cannot decide if trust anchor CA(s) have expired,
     and SHOULD poll periodically for a new trust anchor certificate(s)
     using the /crts request at an interval of approximately 1 month.  An
     EST-coaps server SHOULD include the CoAP ETag Option ([RFC7252],
     Section 5.10.6)in every response to a /crts request, to enable
     clients to perform low-overhead validation whether their trust anchor
     CA is still valid.  The EST-coaps client SHOULD store the ETag
     resulting from a /crts response in memory and SHOULD use this value
     in an ETag Option in its next GET /crts request.

  6.5.3.  Change of Domain Trust Anchor(s)

     The domain trust anchor(s) may change over time.  Such a change may
     happen due to relocation of the client device to a new domain, a new
     subdomain, or due to a key update of a trust anchor as described in
     [RFC4210], Section 4.4.

     From the client's viewpoint, a trust anchor change happens during
     EST-coaps re-enrollment: since a change of domain CA requires all
     devices operating under the old domain CA to acquire a new LDevID
     certificate issued by the new domain CA.  A client's re-enrollment
     may be triggered by various events, such as an instruction to re-
     enroll sent by a domain entity, or an imminent expiry of its LDevID
     certificate, or other.  How the re-enrollment is explicitly triggered
     on the client by a domain entity, such as a commissioner or a
     Registrar, is out of scope of this specification.



  Richardson, et al.       Expires 31 August 2026                [Page 17]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     The mechanism described in [RFC7030], Section 4.1.3 and [RFC4210],
     Section 4.4 for root CA key update requires four certificates:
     OldWithOld, OldWithNew, NewWithOld, and NewWithNew.  Of these four,
     the OldWithOld certificate is already stored in the client's Explicit
     TA database.  The other certificates will be provided to the client
     in a /crts response, during the EST-coaps re-enrollment procedure.

  6.5.4.  Re-enrollment Procedure

     For re-enrollment, the EST-coaps client MUST support the following
     EST-coaps procedure.  During this procedure the EST-coaps server MAY
     re-enroll the client into a new domain or into a new sub-CA within a
     larger domain.

     1.  The client connects with DTLS to the EST-coaps server, and
         authenticates with its present domain certificate (LDevID) as
         usual.  The EST-coaps server authenticates itself with its domain
         RA certificate that is currently trusted by the client, i.e. it
         chains to a trust anchor CA that the client has stored in its
         Explicit TA database.  This is the OldWithOld trust anchor.  The
         client checks that the server is a Registration Authority (RA) of
         the domain as required by Section 3.6.1 of [RFC7030] before
         proceeding.

     2.  The client performs the simple re-enrollment request (/sren) and
         upon success it obtains a new LDevID certificate.

     3.  The client verifies the new LDevID certificate against its
         Explicit TA database.  If the new LDevID chains successfully to a
         TA, this means trust anchors did not significantly change and the
         client MAY skip retrieving the current CA certificates using the
         "CA certificates request" (/crts).  If it does not chain
         successfully, it means trust anchor(s) were changed significantly
         and the client MUST retrieve the new domain trust anchors using
         the "CA certificates request" (/crts).

     4.  If the client retrieved new trust anchor(s) in step 3, then it
         MUST verify that the new LDevID certificate it obtained in step 2
         chains with the new trust anchor(s).  If it chains successfully,
         the client stores the new trust anchor(s) in its Explicit TA
         database, accepts the new LDevID certificate and stops using its
         prior LDevID certificate.  If it does not chain successfully, the
         client MUST NOT update its LDevID certificate, and it MUST NOT
         update its Explicit TA database, and the client MUST abort the
         enrollment process and MUST attempt to report the error to the
         EST-coaps server using enrollment status telemetry (/es).





  Richardson, et al.       Expires 31 August 2026                [Page 18]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Note that even though the EST-coaps client may skip the /crts request
     in step 3 at this time, it SHOULD still support renewal of the trust
     anchors as detailed in Section 6.5.2.

     Note that an EST-coaps server that is also a Registrar will already
     support the enrollment status telemetry resource (/es) in step 4,
     while an EST-coaps server that purely implements [RFC9148], and not
     the present specification, will not support this resource.

  6.5.5.  Multipart Content-Format for CA certificates (/crts) Resource

     In EST-coaps [RFC9148] the PKCS#7 container format is used for CA
     certificates distribution.  Because the PKCS#7 format is only used as
     a certificate container and no additional security is applied on the
     container, it becomes attractive to replace this format by something
     simpler, on a constrained Pledge: so that additional PKCS#7 code is
     avoided.  Therefore, this document defines a container format using
     the [RFC8710] application/multipart-core media type (CoAP content-
     format 62).  This is beneficial since a Pledge necessarily already
     supports CBOR parsing, so there is little code overhead to support
     this CBOR-based container format.

     A Registrar or EST-coaps server MUST support content-format 62 for
     the /crts resource.  The multipart collection MUST contain the
     individual CA certificates, each encoded as an application/pkix-cert
     (287) representation.  Future documents may define other certificate
     formats: the multipart collection can handle any future types.  The
     order of CA certificates MUST be in the CA hierarchy order starting
     from the issuer of the client's LDevID first, up to the highest-level
     domain CA, then optionally followed by any further CA certificates
     that are not part of this hierarchy.  These further CA certificates
     may be Third-party TAs as defined in [RFC7030].  The highest-level
     domain CA may or may not be a root CA certificate.

     As an example, for the two-level CA domain PKI of Figure 1 the
     multipart container will contain two representations:

     [ <domain sub-CA cert (2)> , <domain CA cert (1)> ]

     Encoded as an application/multipart-core CBOR array this is (shown in
     CBOR diagnostic notation):

     [ 287, h'3082' ... 'd713', 287, h'3082' ... 'a034' ]

     The total number of CA certificates SHOULD be 1, 2 or 3 and not
     higher to prevent constrained Pledges from running out of memory for
     the trust anchor storage (Explicit TA database).  However if a domain
     operator can guarantee that any Pledges enrolled in its network can



  Richardson, et al.       Expires 31 August 2026                [Page 19]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     support larger sets of CA certificates, the total number MAY be
     configured as higher than 3.  To facilitate a reliable transfer of
     large payloads over constrained networks, the server MUST support
     CoAP Block-wise transfer for the /crts response.  The server MUST
     also support the Size2 Option [RFC7959] to provide the total resource
     length in bytes, when requested by a client.

     Implementation notes: a client that receives the first block of
     payload data from the server, can already inspect the total number of
     CA certificates by decoding the first byte of the payload.  In CBOR
     encoding, the respective first bytes 0x81-0x97 represent an array
     with length 1-23, respectively.  Furthermore, the length in bytes of
     the first CA certificate can be already determined by decoding the
     first bytes of the second element, because the CBOR encoding for
     binary string includes the length of this string.  A client that
     requires an estimate of the total resource size (to be returned as
     part of the first Block2 response from the server) can use a Size2
     Option with value 0 in its request.  Knowing the overall progress of
     the data transfer may be helpful in certain cases, e.g. when a Pledge
     provides visual progress information on the onboarding progress.

  6.6.  Registrar Extensions

     Before a Registrar forwards a COSE-signed voucher from MASA to the
     Pledge, it MUST remove any 'x5bag' or 'x5chain' unprotected COSE
     header attributes (which are defined in [RFC9360]).  The contents of
     these unprotected attributes are solely for validation/logging use by
     the Registrar.  Removing these attributes reduces the voucher size on
     the constrained network path to the Pledge.

     The content-format 60 (application/cbor) MUST be supported by the
     Registrar for the /vs and /es resources.

     Content-format 836 (application/voucher+cose) MUST be supported by
     the Registrar for the /rv resource for CoAP POST requests, both as
     request payload and as response payload.

     Content-format 287 (application/pkix-cert) MUST be supported by the
     Registrar as a response payload for the /sen and /sren resources.












  Richardson, et al.       Expires 31 August 2026                [Page 20]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     When a Registrar receives a "CA certificates request" (/crts) request
     with a CoAP Accept Option with value 287 (application/pkix-cert) it
     MUST return only the single CA certificate that is the envisioned or
     actual CA authority for the current, authenticated Pledge making the
     request.  An exception to this rule is when the domain has been
     configured to operate with multiple CA trust anchors exclusively:
     then the Registrar returns a 4.06 Not Acceptable error to signal to
     the client that it needs to request another content-format that
     supports retrieval of multiple CA certificates.

  7.  BRSKI-MASA Protocol

     This section describes extensions to and clarifications of the BRSKI-
     MASA protocol between Registrar and MASA.

  7.1.  Protocol and Formats

     Section 5.4 of [RFC8995] describes a connection between the Registrar
     and the MASA as being a normal TLS connection using HTTPS.  This
     document does not change that.

     The MASA only needs to support formats for which it has constructed
     Pledges that use that format.

     The Registrar MUST use the same format for the RVR as the Pledge used
     for its PVR.  Specifically, the Registrar MUST use the media type
     application/voucher+cose for its voucher request to MASA, when the
     Pledge used content-format 836 in the payload of its request to the
     Registrar.

     The Registrar indicates the voucher format (by media type) it wants
     to receive from MASA using the HTTP Accept header.  This format MUST
     be the same as the format of the PVR, so that the Pledge can parse
     the resulting voucher.

     At the moment of writing the creation of CoAPS based MASAs is deemed
     unrealistic and unnecessary.  The use of CoAP for the BRSKI-MASA
     connection is out of scope but can be the subject of another
     document.  Some consideration was made to specify CoAP support for
     consistency, but:

     *  the Registrar is not expected to be so constrained that it cannot
        support HTTPS client connections.

     *  the technology and experience to build Internet-scale HTTPS
        responders (which the MASA is) is common, while the experience
        doing the same for CoAP is much less common.




  Richardson, et al.       Expires 31 August 2026                [Page 21]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     *  a Registrar is likely to provide onboarding services to both
        constrained and non-constrained devices.  Such a Registrar would
        need to speak HTTPS anyway.

     *  a manufacturer is likely to offer both constrained and non-
        constrained devices, so there may in practice be no situation in
        which the MASA could be CoAP-only.  Additionally, as the MASA is
        intended to be a function that can easily be outsourced to a
        third-party service provider, reducing the complexity would also
        seem to reduce the cost of that function.

     *  security-related considerations: see Section 14.3.

  7.2.  Registrar Voucher Request

     If the PVR contains a proximity assertion, the Registrar MUST
     propagate this assertion into the RVR by including the 'assertion'
     attribute with the value "proximity".  This conforms to the example
     in Section 3.3 of [RFC8995] of carrying the assertion forward.

  7.3.  MASA and the Server Name Indicator (SNI)

     A TLS/HTTPS connection is established between the Registrar and MASA.

     Section 5.4 of [RFC8995] explains this process, and there are no
     externally visible changes made by this document.  A MASA that
     supports the unconstrained voucher formats should be able to support
     constrained voucher formats equally well.

     There is no requirement that a single MASA be used for both
     constrained and unconstrained voucher requests: the choice of MASA is
     determined by the id-mod-MASAURLExtn2016 extension contained in the
     IDevID, so it can be determined by the manufacturer.

     The Registrar MUST do DNS-ID checks ([RFC9525]) on the contents of
     the certificate provided by the MASA during the TLS handshake.

     In contrast to the Pledge/Registrar situation, the Registrar always
     knows the name of the MASA, and MUST always include an [RFC6066]
     Server Name Indicator.  The SNI is optional in TLS 1.2, but common.
     The SNI is considered mandatory with TLS 1.3.

     The presence of the SNI extension is required by the MASA, in order
     for the MASA's server to host multiple tenants (for different
     customers).






  Richardson, et al.       Expires 31 August 2026                [Page 22]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  7.4.  Registrar Client Certificate Requirements

     The Registrar SHOULD use a TLS Client Certificate to authenticate to
     the MASA per Section 5.4.1 of [RFC8995].  If the certificate that the
     Registrar uses is marked as a id-kp-cmcRA certificate, via Extended
     Key Usage, then it MUST also have the id-kp-clientAuth EKU attribute
     set.

     In summary, for typical Registrar use, where a single Registrar
     certificate is used for both client and server roles, the certificate
     MUST have an EKU set with at least all of id-kp-cmcRA, id-kp-
     serverAuth, and id-kp-clientAuth.

  8.  Pinning in Voucher Artifacts

     The voucher is a statement by the MASA for use by the Pledge that
     provides the identity of the Pledge's owner.  This section describes
     how the owner's identity is determined and how it is specified within
     the voucher.

  8.1.  Registrar Identity Selection and Encoding

     Section 5.5 of [RFC8995] describes BRSKI policies for selection of
     the owner identity.  It indicates some of the flexibility enabled for
     the Registrar, and recommends the Registrar to include only
     certificates in the voucher request (CMS) signing structure that
     participate in the certificate chain that is to be pinned.

     The MASA is expected to evaluate the certificates included in an RVR,
     forming them into a chain with the Registrar's (signing) identity on
     one end.  Then, it pins a certificate selected from this chain
     according to its pinning policy (Section 8.2).

     For instance, for a domain with a two-level certification authority
     (see Figure 1), where the RVR has been signed by "domain Registrar",
     the RVR includes the chain formed by the domain Registrar EE
     certificate, the domain Sub-CA certificate, and the domain CA trust
     anchor certificate.  The arrows in the figure indicate the issuing of
     a certificate, i.e. author of (1) issued (2) and author of (2) issued
     (3).











  Richardson, et al.       Expires 31 August 2026                [Page 23]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


      .------------------.
      |  domain CA (1)   |
      |  trust anchor    |
      '------------------'
                |
                v
         .------------.
         | domain (2) |
         | Sub-CA     |
         '------------'
                |
                v
       .----------------.
       |   domain       |
       | Registrar (3)  |
       | EE certificate |
       '----------------'

                           Figure 1: Two-Level CA PKI

     When the Registrar is using a COSE-signed RVR, the COSE_Sign1 object
     contains a protected and an unprotected header.  The Registrar MUST
     place all the certificates needed by MASA to validate the signature
     chain for its RVR in an 'x5bag' attribute in either the protected or
     the unprotected header as defined in Section 2 of [RFC9360].

  8.2.  MASA Pinning Policy

     The MASA, having assembled and verified the certificate chain that
     signed the RVR then needs to select a certificate to pin.  (For the
     case that only the Registrar's End-Entity certificate is included,
     only this certificate can be selected and this section does not
     apply.)  The BRSKI policy for pinning by the MASA as described in
     Section 5.5.2 of [RFC8995] leaves much flexibility to the
     manufacturer.

     The present document adds the following rules to the MASA pinning
     policy to reduce the network load on the constrained network side:

     1.  for a voucher containing a nonce, it SHOULD pin the most specific
         (lowest-level) CA certificate in the chain.

     2.  for a nonceless voucher, it SHOULD pin the least-specific
         (highest-level) CA certificate in the chain that is allowed under
         the MASA's policy for this specific domain.






  Richardson, et al.       Expires 31 August 2026                [Page 24]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     The rationale for 1. is that in case of a voucher with nonce, the
     voucher is valid only in scope of the present DTLS connection between
     Pledge and Registrar anyway, so there is no benefit to pin a higher-
     level CA.  By pinning the most specific CA the constrained Pledge can
     validate its DTLS connection using less crypto operations.  The
     rationale for pinning a CA instead of the Registrar's End-Entity
     certificate directly is based on the following benefit on constrained
     networks: the pinned certificate in the voucher can in common cases
     be re-used as a Domain CA trust anchor during the EST enrollment and
     during the operational phase that follows after EST enrollment, as
     explained in Section 6.5.1.

     The rationale for 2. follows from the flexible BRSKI trust model for,
     and purpose of, nonceless vouchers (Sections 5.5.* and 7.4.1 of
     [RFC8995]).

     Referring to the example of Figure 1 of a domain with a two-level
     certification authority, the most specific CA ("Sub-CA") is the
     identity that is pinned by MASA in a nonced voucher.

     In case of a nonceless voucher, depending on the trust level, the
     MASA pins the "Registrar" certificate (low trust in customer), or the
     "Sub-CA" certificate (in case of medium trust, implying that any
     Registrar of that sub-domain is acceptable), or even the "domain CA"
     certificate (in case of high trust in the customer, and possibly a
     pre-agreed need of the customer to obtain flexible long-lived
     vouchers).

  8.3.  Pinning of Raw Public Keys (RPK)

     Specifically for the most-constrained use cases, the pinning of the
     raw public key (RPK) of the Registrar is also supported in the
     constrained voucher, instead of a PKIX certificate.  This is used by
     the RPK variant of cBRSKI described in Section 13, but it can also be
     used in the default cBRSKI flow as a means to reduce voucher size.

     For both cases, if an RPK is pinned, it MUST be the RPK of the
     Registrar, which equals the public key of the Registrar's EE
     certificate.

     When the Pledge is known by MASA to support the RPK variant only, the
     voucher produced by the MASA pins the RPK of the Registrar in either
     the 'pinned-domain-pubk' or 'pinned-domain-pubk-sha256' attribute of
     the voucher data.  This is described in more detail in [RFC8366bis]
     and Section 13.






  Richardson, et al.       Expires 31 August 2026                [Page 25]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     When the Pledge is known by MASA to support PKIX operations, the
     'pinned-domain-cert' attribute present in a voucher normally pins a
     domain certificate.  That can be either the End-Entity certificate of
     the Registrar, or the certificate of a domain CA, as specified in
     Section 8.2.  However, if the Pledge is known by MASA to also support
     RPK pinning and the MASA policy intends to pin the Registrar in the
     voucher (and not a CA), then MASA SHOULD pin the RPK (RPK3 in
     Figure 2) of the Registrar instead of the Registrar's End-Entity
     certificate to save space in the voucher.

                                               .-------------.
      .------------.                           | private     |
      | pub-CA (1) |                           | root-CA (1) |
      '------------'                           '-------------'
             |                                        |
             v             .-------------.            v
      .------------.       | private     |     .------------.
      | sub-CA (2) |       | root-CA (1) |     | sub-CA (2) |
      '------------'       '-------------'     '------------'
             |                    |                   |
             v                    v                   v
     .--------------.     .--------------.     .--------------.
     | Registrar(3) |     | Registrar(3) |     | Registrar(3) |
     |    RPK3      |     |    RPK3      |     |    RPK3      |
     '--------------'     '--------------'     '--------------'

                Figure 2: Raw Public Key (RPK) pinning examples

  9.  Artifacts

     The YANG ([RFC7950]) module and CBOR serialization for the
     constrained voucher as used by cBRSKI are described in [RFC8366bis].
     That document also assigns SID values to YANG elements in accordance
     with [RFC9254] and [RFC9595].  The present section provides some
     examples of these artifacts and defines a new signature format for
     these, using COSE.

     Compared to the first voucher request definition done in [RFC8995],
     the constrained voucher request adds the attributes 'proximity-
     registrar-pubk' and 'proximity-registrar-pubk-sha256'.  One of these
     is optionally used to replace the 'proximity-registrar-cert'
     attribute, for a smaller voucher request data size - useful for the
     most constrained cases.

     The constrained voucher adds the attributes 'pinned-domain-pubk' and
     'pinned-domain-pubk-sha256' to pin an RPK.  One of these is
     optionally used instead of the 'pinned-domain-cert' attribute, for a
     smaller voucher data size.



  Richardson, et al.       Expires 31 August 2026                [Page 26]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  9.1.  Example Artifacts

  9.1.1.  Example Pledge Voucher Request (PVR) Artifact

     Below, example voucher data from a constrained voucher request (PVR)
     from a Pledge to a Registrar is shown in CBOR diagnostic notation.
     Long CBOR byte strings have been shortened for readability, using the
     ellipsis ("...") to indicate elided bytes.  This notation is defined
     in [I-D.ietf-cbor-edn-literals].  The enum value of the assertion
     attribute is 2 for the 'proximity' assertion as defined in
     Section 8.3 of [RFC8366bis].

     {
      2501: {          / SID=2501, ietf-voucher-request:voucher|voucher /
        1: 2,                      / SID=2502, assertion 2 = "proximity"/
        7: h'831D5198A6CA2C7F',    / SID=2508, nonce                    /
       12: h'30593013' ... '9A54', / SID=2513, proximity-registrar-pubk /
       13: "JADA123456789"         / SID=2514, serial-number            /
      }
     }

     The Pledge has included the attribute 'proximity-registrar-pubk'
     which carries the public key of the Registrar, instead of including
     the full Registrar certificate in a 'proximity-registrar-cert'
     attribute.  This is done to reduce the size of the PVR.  Also note
     that the Pledge did not include the 'created-on' attribute since it
     lacks an internal real-time clock and has no knowledge of the current
     time at the moment of performing the onboarding.

  9.1.2.  Example Registrar Voucher Request (RVR) Artifact

     Next, example voucher data from a constrained voucher request (RVR)
     from a Registrar to a MASA is shown in CBOR diagnostic notation.  The
     Registrar has created this request triggered by the reception of the
     Pledge voucher request (PVR) of the previous example.  Again, long
     CBOR byte strings have been shortened for readability.

     {
      "ietf-voucher-request:voucher": {
         "assertion":     2,
         "created-on":    "2022-12-05T19:19:19.536Z",
         "nonce":         h'831D5198A6CA2C7F',
         "idevid-issuer": h'04183016' ... '1736C3E0',
         "serial-number": "JADA123456789",
         "prior-signed-voucher-request": h'A11909' ... '373839'
      }
     }




  Richardson, et al.       Expires 31 August 2026                [Page 27]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Note that the Registrar uses here the string data type for all key
     names, instead of the more compact SID integer keys.  This is fine
     for any use cases where the network between Registrar and MASA is an
     unconstrained network where data size is not critical.  The
     constrained voucher request format supports both the string and SID
     key types, for PVR as well as RVR.

  9.1.3.  Example Voucher Artifacts

     Below, an example of constrained voucher data is shown in CBOR
     diagnostic notation.  It was created by a MASA in response to
     receiving the Registrar Voucher Request (RVR) shown in Section 9.1.2.
     The enum value of the 'assertion' attribute is set to "proximity"
     (2), to acknowledge to both the Pledge and the Registrar that the
     proximity of the Pledge to the Registrar is considered proven.

     {
      2451: {               / SID = 2451, ietf-voucher:voucher|voucher /
        1: 2,                      / SID = 2452, assertion "proximity" /
        2: "2022-12-05T19:19:23Z", / SID = 2453, created-on            /
        3: false,       / SID = 2454, domain-cert-revocation-checks    /
        7: h'831D5198A6CA2C7F',    / SID = 2508, nonce                 /
        8: h'308201' ... '8CFF',   / SID = 2459, pinned-domain-cert    /
       11: "JADA123456789"         / SID = 2462, serial-number         /
      }
     }

     While the above example voucher data includes the nonce from the PVR,
     the next example is for a nonce-less voucher.  Instead of a nonce, it
     includes an 'expires-on' attribute with the date and time on which
     the voucher expires.  Because the MASA did not verify the proximity
     of the Pledge and Registrar in this case, the 'assertion' attribute
     contains a weaker assertion of "verified" (0).  This indicates that
     the MASA verified the domain's ownership of the Pledge via some other
     means.

     {
      2451: {               / SID = 2451, ietf-voucher:voucher|voucher /
        1: 0,                      / SID = 2452, assertion "verified"  /
        2: "2022-12-06T10:15:32Z", / SID = 2453, created-on            /
        3: false,          / SID = 2454, domain-cert-revocation-checks /
        4: "2022-12-13T10:15:32Z", / SID = 2455, expires-on            /
        8: h'308201F8' ... 'FF',   / SID = 2459, pinned-domain-cert    /
       11: "JADA123456789"         / SID = 2462, serial-number         /
      }
     }





  Richardson, et al.       Expires 31 August 2026                [Page 28]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     The voucher is valid for one week.  To verify the voucher's validity,
     the Pledge would either need an internal real-time clock or some
     external means of obtaining the current time, such as Network Time
     Protocol (NTP) or a radio time signal receiver.

  9.2.  Signing Voucher and Voucher Request Artifacts with COSE

     The COSE_Sign1 structure is discussed in Section 4.2 of [RFC9052].
     The CBOR object that carries the body, the signature, and the
     information about the body and signature is called the COSE_Sign1
     structure.  It is used when only one signature is used on the body.

     Support for ECDSA with SHA2-256 using curve secp256r1 (aka
     prime256k1) is RECOMMENDED.  Most current low power hardware has
     support for acceleration of this algorithm.  Future hardware designs
     could omit this in favour of a newer algorithms.  This is the ES256
     (-7) keytype from Table 1 of [RFC9053].  Support for curve secp256k1
     is OPTIONAL.

     Support for EdDSA using Curve 25519 is RECOMMENDED in new designs if
     hardware support is available.  This is keytype EDDSA (-8) from
     Table 2 of [RFC9053].  A 'crv' parameter is necessary to specify the
     Curve, for example value Ed25519 (6) from Table 18 of [RFC9053].  The
     'kty' field MUST be present, and it MUST be "OKP" (Table 17 of
     [RFC9053]).

     A transition towards EdDSA is occurring in the industry.  Some
     hardware can accelerate only some algorithms with specific curves,
     other hardware can accelerate any curve, and still other kinds of
     hardware provide a tool kit for acceleration of any elliptic curve
     algorithm.

     In general, the Pledge is expected to support only a single
     algorithm, while the Registrar, usually not constrained, is expected
     to support a wide variety of algorithms: both legacy ones and up-and-
     coming ones via regular software updates.

     An example of the supported COSE_Sign1 object structure containing a
     Pledge Voucher Request (PVR) is shown below.












  Richardson, et al.       Expires 31 August 2026                [Page 29]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     18(                   / tag for COSE_Sign1                       /
      [
        h'A10126',         / protected COSE header encoding: {1: -7}  /
                           /            which means { "alg": ES256 }  /
        {},                / unprotected COSE header parameters       /
        h'A119' ... '3839', / PVR payload wrapped in CBOR byte string /
        h'4567' ... '1234'  / PVR binary Sign1 signature              /
      ]
     )

     The [COSE-registry] specifies the integers/encoding for the 'alg'
     field.  The 'alg' field restricts the key usage for verification of
     this COSE object to a particular cryptographic algorithm.

  9.2.1.  Signing of Registrar Voucher Request (RVR)

     A Registrar MUST include a COSE 'x5bag' structure in the RVR as
     explained in Section 8.1.  Below, an example Registrar Voucher
     Request (RVR) is shown that includes the 'x5bag' unprotected header
     parameter (32).  The bag contains two certificates in this case.

     18(                    / tag for COSE_Sign1                      /
      [
        h'A10126',          / protected COSE header encoding: {1: -7} /
                            /            which means { "alg": ES256 } /
        {                   / unprotected COSE header/
          32: [h'308202' ... '20AE', h'308201' ... '8CFF']    / x5bag /
        },
        h'A178' ... '7FED', / RVR payload wrapped in CBOR byte string /
        h'E1B7' ... '2925'  / RVR binary Sign1 signature              /
      ]
     )

     Besides storing the Registrar's own RVR-signing certificate chain
     (per Section 8.1), the Registrar MUST include in the same 'x5bag'
     structure all the certificates that the Pledge used to identify
     itself in the Pledge/Registrar DTLS handshake, including the End-
     Entity (IDevID) certificate and all CAs up to the root CA.  This
     serves two purposes:

     1.  A MASA that does not store the IDevIDs for all Pledges and their
         related sub-CAs is still able to reconstruct the certificate
         chain for a given Pledge and validate the Pledge's signature on
         the PVR based purely on the root CA of the Pledge's manufacturer
         that the MASA is storing.






  Richardson, et al.       Expires 31 August 2026                [Page 30]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     2.  Diagnostic/debugging purposes: since the PVR's COSE signature
         does not store any certificates related to the signer, but only
         the signature itself, it can be useful for the MASA to log or
         inspect the Pledge's certificate chain in case the onboarding
         attempt fails.  Having the complete signing certificate chain at
         hand facilitates finding the root cause of the problem and helps
         in the communication with the customer.

     A 'kid' (key ID) field is OPTIONAL in the unprotected COSE header
     parameters map of a COSE object.  If present, it identifies the
     public key of the key pair that was used to sign the COSE message.
     The value of the key identifier 'kid' parameter may be in any format
     agreed between signer and verifier.  Usually a hash of the public key
     is used to identify the public key; but the choice of key identifier
     method is vendor-specific.

     By default, a Registrar does not include a 'kid' parameter in the RVR
     since the signing key is already identified by the signing
     certificates chain included in the COSE 'x5bag' structure.  A
     Registrar nevertheless MAY use a 'kid' parameter in its RVR to
     identify its signing key/identity.

     The method of generating such 'kid' value is vendor-specific and
     SHOULD be configurable in the Registrar to support commonly used
     methods.  In order to support future business cases and supply chain
     integrations, a Registrar using the 'kid' field MUST be configurable,
     on a per-manufacturer basis, to select a particular method for
     generating the 'kid' value such that it is compatible with the method
     that the manufacturer expects.  Note that the 'kid' field always has
     a CBOR byte string (bstr) format.

     In Appendix C.4 a further example of a signed RVR is shown.

  9.2.2.  Signing of Pledge Voucher Request (PVR)

     Like in the RVR, a 'kid' (key ID) field is also OPTIONAL in the PVR.
     It can be used to identify the signing key/identity to the MASA.

     A Pledge by default SHOULD NOT use a 'kid' parameter in its PVR,
     because its signing key is already identified by the Pledge's unique
     serial number that is included in the PVR and (by the Registrar) in
     the RVR.  This achieves the smallest possible PVR data size while
     still enabling the MASA to fully verify the PVR.  Still, when
     required the Pledge MAY use a 'kid' parameter in its PVR to help the
     MASA identify the right public key to verify against.  This can occur
     for example if a Pledge has multiple IDevID identities.  The 'kid'
     parameter in this case may be an integer byte identifying one out of
     N identities present, or it may be a hash of the public key, or



  Richardson, et al.       Expires 31 August 2026                [Page 31]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     anything else the Pledge vendor decides.  A Registrar normally SHOULD
     ignore a 'kid' parameter used in a received PVR, as this information
     is intended for the MASA.  In other words, there is no need for the
     Registrar to verify the contents of this field, but it may include it
     in an audit log.

     The example below shows a PVR with 'kid' present as an unprotected
     header parameter.

     18(                    / tag for COSE_Sign1                      /
      [
        h'A10126',          / protected COSE header encoding: {1: -7} /
                            /            which means { "alg": ES256 } /
        {
           4: h'59AB3E'     / COSE "kid" header parameter             /
        },
        h'A119' ... '3839', / PVR payload wrapped in CBOR byte string /
        h'5678' ... '7890'  / PVR binary Sign1 signature              /
      ]
     )

     The Pledge SHOULD NOT use the 'x5bag' or 'x5chain' COSE header
     parameters in the PVR.  A Registrar that processes a PVR with such a
     structure MUST ignore it, and MUST use only the TLS Client
     Certificate extension for authentication of the Pledge.

     A situation where the Pledge MAY use the 'x5bag' or 'x5chain'
     structure is for communication of certificate chains to the MASA.
     This would arise in some vendor- specific situations involving
     outsourcing of MASA functionality, or rekeying of the IDevID
     certification authority.

     In Appendix C.3 a further example of a signed PVR is shown.

  9.2.3.  Signing of Voucher by MASA

     The MASA SHOULD NOT use a 'kid' parameter in the voucher response,
     because the MASA's signing key is already known to the Pledge.
     Still, where needed the MASA MAY use a 'kid' parameter in the voucher
     response to help the Pledge identify the right MASA public key to
     verify against.  This can occur for example if a Pledge has multiple
     IDevID identities.

     The MASA SHOULD NOT include an 'x5bag' or 'x5chain' attribute in the
     protected header of the voucher response, because normally a Pledge
     already stores the required public key for validation of the signed
     voucher.  The exception case is if the MASA knows that the Pledge
     doesn't pre-store the MASA's public key used for signing, and thus



  Richardson, et al.       Expires 31 August 2026                [Page 32]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     the MASA needs to provide a certificate or certificate chain that
     will enable linking the signing identity to a pre-stored Trust Anchor
     (CA) in the Pledge.  This approach is not recommended, because
     including certificates in the protected 'x5bag' or 'x5chain' COSE
     header parameters will significantly increase the size of the voucher
     which impacts cBRSKI operation on constrained networks.

     For example, if the MASA signing key is based upon a PKI (see
     [I-D.richardson-anima-masa-considerations] Section 2.3), and the
     Pledge only pre-stores a manufacturer (root) CA identity in its Trust
     Store which is not the identity that signs the voucher, then a
     certificate chain needs to be included with the voucher in order for
     the Pledge to validate the MASA signing CA's signature by validating
     the chain up to the CA in its Trust Store.  In BRSKI CMS signed
     vouchers [RFC8995], the CMS structure has a place for such a
     certificate chain.  In cBRSKI COSE-signed vouchers, the 'x5bag'
     attribute [RFC9360] placed in the COSE protected header parameters is
     used to contain the needed certificates for the Pledge to form the
     chain.

     To signal the complete chain of the MASA's signing identity to the
     Registrar, the MASA MUST include the complete chain of signing
     certificates in an 'x5bag' attribute in the unprotected header of the
     voucher.  This allows the Registrar to optionally validate the
     voucher before forwarding it to the Pledge, or to validate it for
     logging purposes.  There is no voucher size impact of including this
     certificate chain in an unprotected 'x5bag' COSE header parameter for
     constrained networks, because the Registrar will remove this
     unprotected attribute prior to forwarding the voucher response to the
     Pledge, as defined in Section 6.6.

     Note that cBRSKI currently does not support signing the voucher with
     an RPK for which there is no corresponding certificate at all.  If
     the MASA wants to sign a voucher with an RPK that is not part of any
     PKIX hierarchy, it creates a single self-signed "placeholder" root CA
     certificate that uses the designated RPK as the public key.  This
     "placeholder" certificate is then included as the sole certificate in
     an unprotected 'x5bag' header parameter, as defined in the previous
     paragraph.

     Below, an example is shown of a COSE-signed voucher as created by
     MASA.  This example shows the common case where a protected 'x5bag'
     (32) attribute is not used, while an unprotected 'x5bag' (32)
     attribute is used to communicate the MASA's signature certificate
     chain to the Registrar.  The bag contains two certificates in this
     example.  One of these is the identity of the signer of the
     COSE_Sign1 object, whose signature is stored as the last CBOR array
     element in the below example.



  Richardson, et al.       Expires 31 August 2026                [Page 33]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     18(                    / tag for COSE_Sign1                        /
      [
        h'A10126',          / protected COSE header encoding: {1: -7}   /
                            /            which means { "alg": ES256 }   /
        {                   / unprotected COSE header parameters        /
          32: [h'308202' ... '20AE', h'308201' ... '8CFF']      / x5bag /
        },
        h'A119' ... '3839', / voucher payload wrapped in CBOR byte str  /
        h'2A2C' ... '7FBF'  / voucher binary Sign1 signature by MASA    /
      ]
     )

     In Appendix C.5 a further example of a signed voucher is shown.

  9.2.4.  Optional Validation of Voucher by Registrar

     For a Registrar, validation of the voucher and/or the signature of
     the voucher is optional, per Section 5.6 of [RFC8995].  However, if a
     Registrar does perform the validation of the signature chain,
     communicated in the 'x5bag' unprotected COSE header parameter (see
     Section 9.2.3)), it MUST validate that one of the below cases hold:

     1.  The signature chain is a single self-signed root CA certificate
         with a correct signature; and the public key in this certificate
         is also the public key that signed the voucher.  This represents
         the case where a voucher has been effectively signed with an RPK.

     2.  The signature chain consists of one or more certificates that can
         be chained to a known (preconfigured) trust root in the
         Registrar.

     The above validation elements are needed only for cases where
     (nonceless) vouchers are communicated over potentially unsecure
     channels to the Registrar.  Since the 'x5bag' header parameter is not
     protected by the voucher's COSE signature, it could have been
     modified in transit.

  9.2.5.  Additional Information in the COSE Header

     The COSE header of the signed voucher can contain COSE header
     parameters with additional information, to be used by the Pledge.
     This information is additional to, and separate from, the voucher
     data defined by [RFC8366bis].

     An example of how this additional information can be used is adding a
     CBOR Web Token (CWT, [RFC8392]) claim in the COSE header as defined
     by [RFC9597], to encode the COSE signing time as an integer value in
     an 'iat' (Issued At) CWT claim.  This information in an integer



  Richardson, et al.       Expires 31 August 2026                [Page 34]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     format may be useful for a Pledge that does not have date/time
     parsing functions, so it is unable to parse the date/time string
     value contained in the voucher.  Many other types of CWT claims can
     be included in a voucher in the same way, as needed for particular
     use cases.

     Such additional information can also be included in a COSE header of
     a voucher request by a Pledge, to be used by the MASA.

  10.  Extensions to Discovery

     It is assumed that a Join Proxy (Section 6.2) seamlessly provides a
     relayed DTLS connection between the Pledge and the Registrar.  To use
     a Join Proxy, a Pledge needs to discover it.  For Pledge discovery of
     a Join Proxy, this section extends Section 4.1 of [RFC8995] for the
     cBRSKI case.

     In general, the Pledge may be one or more hops away from the
     Registrar, where one hop means the Registrar is a direct link-local
     neighbor of the Pledge.  The case of one hop away can be considered
     as a degenerate case, because a Join Proxy is not really needed then.

     The degenerate case would be unusual in constrained wireless network
     deployments, because a Registrar would typically not have a wireless
     network interface of the type used by constrained devices.  Rather,
     it would have a high-speed network interface.  Nevertheless, the
     situation where the Registrar is one hop away from the Pledge could
     occur in various cases like wired IoT networks or in wireless
     constrained networks where the Pledge is in radio range of a 6LoWPAN
     Border Router (6LBR) ([RFC6775])and the 6LBR happens to host a
     Registrar.

     In order to support the degenerate case, the Registrar SHOULD
     announce itself as if it were a Join Proxy -- though it would
     actually announce its real (stateful) Registrar CoAPS endpoint.  No
     actual Join Proxy functionality is then required on the Registrar.

     That way, a Pledge only needs to discover a Join Proxy, regardless of
     whether it is one or more than one hop away from a relevant
     Registrar.  It first discovers the link-local address and the UDP
     join-port of a Join Proxy.  The Pledge then follows the cBRSKI
     procedure of initiating a DTLS connection using the link-local
     address and join-port of the Join Proxy.








  Richardson, et al.       Expires 31 August 2026                [Page 35]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Once enrolled, a Pledge itself may function as a Join Proxy.  The
     decision whether or not to provide this functionality depends upon
     many factors and is out of scope for this document.  Such a decision
     might depend upon the amount of energy available to the device, the
     network bandwidth available, as well as CPU and memory availability.

     The process by which a Pledge discovers the Join Proxy, and how a
     Join Proxy discovers the location of the Registrar, are the subject
     of the remainder of this section.  Further details on both these
     topics are provided in [I-D.ietf-anima-constrained-join-proxy].

  10.1.  Discovery Operations by a Pledge

     The Pledge must discover the address/port and optionally the protocol
     with which to communicate.  The present document only defines coaps
     (CoAP over DTLS) as the default protocol for cBRSKI, therefore
     protocol discovery is out of scope.

     For the discovery method, this section only defines unsecured CoAP
     discovery per Section 7 of [RFC7252] as the default method.  This
     uses CoRE Link Format [RFC6690] payloads.

     Section 11 briefly mentions other methods that apply to specific
     deployment types or technologies.  Details about these deployment-
     specific methods, or yet other methods, new payload formats, or more
     elaborate CoAP-based methods, may be defined in future documents such
     as [I-D.ietf-anima-brski-discovery].  The more elaborate methods for
     example may include discovering only Join Proxies that support a
     particular desired onboarding protocol, voucher format, or cBRSKI
     variant.

     Note that identifying the format of the voucher request and the
     voucher is currently not a required part of the Pledge's discovery
     operation.  It is assumed that all Registrars support all relevant
     voucher(-request) formats, while the Pledge only supports a single
     format.  A Pledge that makes a voucher request to a Registrar that
     does not support that format will receive a CoAP 4.06 Not Acceptable
     status code and the onboarding attempt will fail.

     Using CoAP discovery, a Pledge can discover a Join Proxy by sending a
     link-local multicast discovery message to the All CoAP Nodes address
     FF02::FD.  Zero, one, or multiple Join Proxies may respond.  The
     handling of multiple responses and absence of responses cases follow
     the guidelines of Section 4 of [RFC8995].  The discovery message is a
     CoAP GET request on the URI path /.well-known/core using a URI query
     "rt=brski.jp".  This resource type ('rt') is defined in Section 8.1
     of [I-D.ietf-anima-constrained-join-proxy].




  Richardson, et al.       Expires 31 August 2026                [Page 36]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Responding Join Proxies return a CoRE Link Format document with one
     or more links.  Each link indicates one CoAPS endpoint that offers
     cBRSKI Join Proxy functionality.  Formally, each link indicates a
     CoAP root resource (/) tagged with the "brski.jp" type, hosted on a
     CoAPS endpoint.

     In case a Pledge selects a particular Join Proxy for cBRSKI
     onboarding, it MUST use the link-local source address of the Join
     Proxy's discovery response as the destination IP address for its
     subsequent onboarding attempt.  This implies that the UTF-8 encoded
     link-local address literal that appears in the host subcomponent of
     each returned link is not used for determining the destination IP
     address of the onboarding attempt.

  10.1.1.  Examples

     Below, a typical example is provided showing the Pledge's CoAP
     request and the Join Proxy's CoAP response.  The Join Proxy responds
     with a link-local source address, which is the same address as
     indicated in the URI-reference element ([RFC6690]) in the link in the
     discovery response payload.  The Join Proxy has a dedicated UDP port
     8485 open for DTLS connections of Pledges:

       REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp

       RES: 2.05 Content
         Content-Format: 40 (application/link-format)
         Payload:
           <coaps://[fe80::c78:e3c4:58a0:a4ad]:8485>;rt=brski.jp

     Note that the Pledge would use the port number from the link in this
     response, but not the IPv6 literal in the host subcomponent
     ([fe80::c78:e3c4:58a0:a4ad]), as defined by the above discovery
     operation steps.

     The next example shows a Join Proxy that uses the default CoAPS port
     5684 for DTLS connections of Pledges.  In this case, the Join Proxy
     host is not using port 5684 for any other purposes, so it has the
     port available exclusively for accepting DTLS connections of Pledges.

       REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp

       RES: 2.05 Content
         Content-Format: 40 (application/link-format)
         Payload:
           <coaps://[fe80::c78:e3c4:58a0:a4ad]>;rt=brski.jp





  Richardson, et al.       Expires 31 August 2026                [Page 37]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     In the following example, two Join Proxies respond to the multicast
     query.  The Join Proxies each use a slightly different CoRE Link
     Format 'rt' value encoding.  While the first encoding is more
     compact, both encodings are allowed per [RFC6690].  The Pledge may
     now select one of the two Join Proxies for initiating its DTLS
     connection.

       REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski*

       RES: 2.05 Content
         Content-Format: 40 (application/link-format)
         Payload:
           <coaps://[fe80::c78:e3c4:58a0:a4ad]:8485>;rt=brski.jp

       RES: 2.05 Content
         Content-Format: 40 (application/link-format)
         Payload:
           <coaps://[fe80::d359:3813:f382:3b23]:63245>;rt="brski.jp"

     In the final example, a single Join Proxy host responds with two
     distinct cBRSKI endpoints.  The Pledge may now select one of the two
     CoAP endpoints for initiating its DTLS connection.

       REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski*

       RES: 2.05 Content
         Content-Format: 40 (application/link-format)
         Payload:
           <coaps://[fe80::d359:3813:f382:3b23]:61616>;rt=brski.jp
           <coaps://[fe80::d359:3813:f382:3b23]:61617>;rt=brski.jp;
                                                       var="c509 v2"

     The first endpoint on port 61616 supports only the cBRSKI protocol as
     defined by this document.  The second endpoint, on port 61617,
     supports the same cBRSKI protocol as well as additional variations or
     extensions.  In this example, these variations/extensions are encoded
     using string values in a single attribute 'var'.  This information
     may be also encoded using other attributes defined by a future
     specification.

     A Pledge not aware of these variations can safely ignore these
     values, because the base cBRSKI protocol is supported by both
     endpoints, as indicated by the resource type ('rt').  If however a
     Pledge is aware of these variations, it can select the endpoint with
     the variation it prefers, in case multiple options are discovered.
     The use of attributes with a single base resource type allows future
     extensibility of cBRSKI, and enables the Join Proxies to support
     cBRSKI variants that are unknown to them.



  Richardson, et al.       Expires 31 August 2026                [Page 38]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  10.2.  Discovery Operations by a Join Proxy

     A Join Proxy needs to discover a Registrar, either at the moment it
     needs to relay data (of a Pledge) towards the Registrar, or prior to
     that moment.  For example, it may start Registrar discovery as soon
     as it is requested to be enabled in a Join Proxy role.  It may
     periodically redo this discovery, or periodically or on-demand check
     that the Registrar is still available in the network at the
     discovered IP address.

     As shown in the final example in Section 10.1.1, a Join Proxy can
     discover multiple Registrars in its network and present these options
     to the Pledge.  Each of these Registrars may support specific
     variations/extensions of cBRSKI - which may be defined in future
     documents.  It is up to the administrator of the network how many
     Registrars are enabled.

     Further details on CoAP discovery of the Registrar by a Join Proxy
     are provided in Section 5.1.1 of
     [I-D.ietf-anima-constrained-join-proxy].

  11.  Deployment-specific Discovery Considerations

     This section details how discovery of a Join Proxy is done by the
     Pledge in specific deployment scenarios.  Future work such as
     [I-D.ietf-anima-brski-discovery] may define more details on discovery
     operations in the specific deployments listed here.

  11.1.  6TiSCH Deployments

     In 6TiSCH networks, the Constrained Join Protocol (CoJP) is used as
     described in [RFC9031].  Such networks are expected to use EDHOC
     [RFC9528] for key management, which is out of scope of this document.
     The IEEE 802.15.4 Enhanced Beacon has been extended in [RFC9032] to
     allow for discovery of a 6TiSCH-compliant Join Proxy.

  11.2.  IP networks using GRASP

     In IP networks that support GRASP [RFC8990], a Pledge can discover a
     Join Proxy by listening for GRASP messages.  GRASP supports mesh
     networks, and can also be used over unencrypted Wi-Fi.

     Details of GRASP discovery of constrained Join Proxies are out of
     scope of this document and may be defined in future work.







  Richardson, et al.       Expires 31 August 2026                [Page 39]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  11.3.  IP networks using mDNS

     [RFC8995] defines a mechanism for the Pledge to discover a Join Proxy
     by sending mDNS [RFC6762] queries.  This mechanism can be used on any
     IP network which does not have another recommended mechanism.  It can
     be used over unencrypted Wi-Fi.  This mechanism does support link-
     local Join Proxy discovery in mesh networks.  However, it does not
     support Registrar discovery by Join Proxies in mesh networks, because
     the Registrar is typically not reachable by link-local communication
     in that case.  For this, another mechanism is needed, which is out of
     scope of this document and may be defined in future work.

     A Pledge uses an mDNS PTR query for the name "_brski-
     proxy._udp.local." to discover link-local constrained Join Proxies.
     The label "_udp" here indicates a query for cBRSKI constrained Join
     Proxies, as opposed to "_tcp" defined in [RFC8995] which is for
     discovering BRSKI Proxies.

  11.4.  Thread Networks using Mesh Link Establishment (MLE)

     Thread [Thread] is a wireless mesh network protocol based on 6LoWPAN
     [RFC6282] and other IETF protocols.  In Thread, a new device
     discovers potential Thread networks and Thread nodes to join by using
     the Mesh Link Establishment (MLE)
     [I-D.ietf-6lo-mesh-link-establishment] protocol.  MLE uses the UDP
     port number 19788.

     The new device sends discovery requests on different IEEE 802.15.4
     radio channels, to which Thread nodes (if any present) respond with a
     discovery response containing information about their respective
     network.  The MLE discovery response message contains UDP port
     information to signal the new device which UDP port to use for its
     DTLS connection to the Join Proxy function.  The link-local IPv6
     source address of the MLE response message indicates the address of
     the Join Proxy.

     Once a suitable Thread node is selected as its Join Proxy, the new
     device initiates a DTLS transport-layer secured connection to the
     network's commissioning application, over a link-local single radio
     hop to the selected Join Proxy.  This link is not yet secured at the
     radio/MAC link layer: link-layer security will be set up once the new
     device is approved by the commissioning application to join the
     Thread network, and it gets provisioned with network access
     credentials.

     A Thread node that is capable to act as a Join Proxy will only enable
     this role if the network-wide configuration data indicates that new
     device commissioning is allowed.



  Richardson, et al.       Expires 31 August 2026                [Page 40]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  12.  Design and Implementation Considerations

  12.1.  Voucher Format and Encoding

     The design considerations for vouchers from Section 10 of
     [RFC8366bis] apply.  Specifically for CBOR encoding of voucher data,
     one key difference with JSON encoding is that the names of the leaves
     in the YANG definition do not affect the size of the resulting CBOR,
     if the SID ([RFC9254], [RFC9595]) translation process is used that
     assigns integers to the names.

     To obtain the lowest code size and RAM use on the Pledge, it is
     recommended that a Pledge is designed to only process/generate these
     SID integers and not the lengthy strings.  The MASA in that case is
     required to generate the voucher data for that Pledge using only SID
     integers.  Yet, this MASA MUST still support both SID integers and
     strings, to be able to process attribute (string) names in the RVR
     which the Registrar may use.

  12.2.  CoAP Usage

     A successful POST request to the Registrar's telemetry resources
     (/vs, /es) returns a 2.04 Changed response with empty payload.

     A CoAP client sending a request should be aware that the server, even
     in case of an empty payload, may use either a piggybacked CoAP
     response (for example ACK with code 2.04) but may also respond with a
     separate CoAP response.  This is first an ACK message with code 0.0
     that acknowledges the reception of the request.  It is followed by a
     CON message with a code 2.04 response in a separate CoAP message.
     See [RFC7252] for details.

  12.3.  Use of cBRSKI with HTTPS

     This specification contains two major extensions to [RFC8995]: a
     constrained voucher format (COSE), and a constrained transfer
     protocol (CoAP).

     On constrained networks with constrained devices, it make senses to
     use both together.  However, this document does not mandate that this
     be the only way.

     A given constrained device design and software may be re-used for
     multiple device models, such as a model having only an IEEE 802.15.4
     radio, or a model having only an IEEE 802.11 (Wi-Fi) radio, or a
     model having both these radios.  A manufacturer of such device models
     may wish to have code only for the use of the constrained voucher
     format (COSE), and use it on all supported radios including the IEEE



  Richardson, et al.       Expires 31 August 2026                [Page 41]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     802.11 radio.  For this radio, the software stack to support HTTP/TLS
     may be already integrated into the radio module hence it is
     attractive for the manufacturer to reuse this.  This type of approach
     is supported by this document.  In the case that HTTPS is used, the
     regular long [RFC8995] resource names are used, together with the new
     application/voucher+cose media type described in this document.  For
     status telemetry requests, the format and requirements defined in
     Section 6.3.1 remain unchanged.

     Other combinations are possible, but they are not enumerated here.
     New work such as [I-D.ietf-anima-jws-voucher] provides new formats
     that may be usable over a number of different transports.  In
     general, sending larger payloads over constrained networks makes less
     sense, while sending smaller payloads over unconstrained networks is
     perfectly acceptable.

     The Pledge will in most cases support a single voucher format, which
     it uses without negotiation i.e. without discovery of formats
     supported.  The Registrar, being unconstrained, is expected to
     support all voucher formats.  There will be cases where a Registrar
     does not support a new format that a new Pledge uses, and this is an
     unfortunate situation that will result in lack of interoperation.

     The responsibility for supporting new formats is on the Registrar.

  13.  Raw Public Key Variant

  13.1.  Introduction and Scope

     This section introduces a cBRSKI variant to further reduce the data
     volume and complexity of the cBRSKI onboarding.  The use of a raw
     public key (RPK) in the pinning process can significantly reduce the
     number of bytes sent over the wire and the number of round trips, and
     reduce the code footprint in a Pledge.  But it comes with a few
     significant operational limitations.

     One simplification that comes with RPK use is that a Pledge can avoid
     doing PKIX operations, such as certificate chain validation.

  13.2.  DTLS Connection and Registrar Trust Anchor

     When the Pledge first connects to the Registrar, the connection to
     the Registrar is provisional, as explained in Section 5.6.2 of
     [RFC8995].  The Registrar normally provides its public key in a
     TLSServerCertificate, and the Pledge uses that to validate that
     integrity of the DTLS connection, but it does not validate the
     identity of the provided certificate.




  Richardson, et al.       Expires 31 August 2026                [Page 42]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     As the TLSServerCertificate object is never verified directly by the
     Pledge, sending it can be considered superfluous.  So instead of
     using a (TLSServer)Certificate of type X509 (see Section 4.4.2 of
     [RFC8446]), a RawPublicKey object (as defined by [RFC7250]) is used.

     A Registrar operating in a mixed environment can determine whether to
     send a PKIX certificate chain or a Raw Public Key to the Pledge: this
     is signaled by the Pledge.  In the case the Pledge needs an RPK, it
     includes the server_certificate_type of RawPublicKey.  This is shown
     in Section 5 of [RFC7250].

     The Pledge MUST send a client_certificate_type of X509 (not an RPK),
     so that the Registrar can properly identify the Pledge and distill
     the MASA URI information from its IDevID certificate.

  13.3.  The Pledge Voucher Request

     The Pledge puts the Registrar's public key into the 'proximity-
     registrar-pubk' attribute of the Pledge Voucher Request (PVR).  The
     'proximity-registrar-pubk-sha256' can alternatively be used for
     efficiency, if the 32-bytes of a SHA256 hash turns out to be smaller
     than a typical ECDSA key.

     As the format of the 'proximity-registrar-pubk' attribute is
     identical to the TLS RawPublicKey data object, no manipulation at all
     is needed to insert this attribute into the PVR.  This approach
     reduces the size of the PVR significantly, compared to including the
     full certificate.

  13.4.  The Voucher Response

     A returned voucher will have a 'pinned-domain-pubk' attribute with
     the identical key as was found in the 'proximity-registrar-pubk'
     attribute above, as well as being identical to the Registrar's RPK in
     the currently active DTLS connection.  (Or alternatively the MASA may
     include the 'pinned-domain-pubk-sha256' attribute if it knows the
     Pledge supports this attribute.)

     Validation of this key by the Pledge is what takes the DTLS
     connection out of the provisional state; see Section 5.6.2 of
     [RFC8995] for more details.

     The received voucher needs to be validated by the Pledge.  The Pledge
     needs to have a public key to validate the signature from the MASA on
     the voucher.






  Richardson, et al.       Expires 31 August 2026                [Page 43]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     The MASA's public key counterpart of the (private) MASA signing key
     MUST be already installed in the Pledge at manufacturing time.
     Otherwise, the Pledge cannot validate the voucher's signature.

  13.5.  The Enrollment Phase

     A Pledge that does not support PKIX operations cannot use EST to
     enroll; it has to use another method for enrollment without
     certificates and the Registrar has to support this method also.  For
     example, an enrollment process that records an RPK owned by the
     Pledge as a legitimate entity that is part of the domain.

     It is possible that the Pledge will not enroll after obtaining a
     valid voucher, but instead will do only a network join operation (see
     for example [RFC9031]).  How the Pledge discovers this method and
     details of such enrollment methods are out of scope of this document.

  14.  Security Considerations

  14.1.  Duplicate Serial Numbers

     If a manufacturer sold products with duplicated serial numbers, that
     use the same MASA CA as their root of trust, a customer of one of
     these products can potentially perform an attack where it uses a
     voucher created for product 1 to onboard product 2.  This attack only
     works for nonceless vouchers.

     Note that such a situation could only arise due to manufacturer mis-
     management or oversight.

     For example, imagine the same manufacturer makes light bulbs as well
     as gas centrifuges, and said manufacturer does not uniquely allocate
     product serial numbers.  The attacker has obtained a light bulb which
     happens to have the same serial number as an operational gas
     centrifuge which it wishes to obtain access to.  The attacker
     performs a normal BRSKI onboarding for the light bulb, but then uses
     the resulting nonceless voucher to onboard the gas centrifuge.  The
     attack requires that the gas centrifuge be returned to a state where
     it is willing to perform a new onboarding operation.  For example, a
     factory reset.

     This attack is normally prevented by the mechanisms of using
     different trust root CAs for different product lines, and/or using
     unique serial numbers within a single MASA CA scope.







  Richardson, et al.       Expires 31 August 2026                [Page 44]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Section 6.2 of [RFC8366bis] discusses cases of duplicated serial
     numbers in products across different CAs and the role of the 'idevid-
     issuer' attribute in the RVR and in the voucher to disambiguate these
     products.

  14.2.  IDevID Security in the Pledge

     The security of this protocol depends upon the Pledge identifying
     itself to the Registrar using its manufacturer installed certificate:
     the IDevID certificate.  Associated with this certificate is the
     IDevID private key, known only to the Pledge.  Disclosure of this
     private key to an attacker would permit the attacker to impersonate
     the Pledge towards the Registrar, probably gaining access credentials
     to that Registrar's network.

     If the IDevID private key disclosure is known to the manufacturer,
     there is little recourse other than recall of the relevant part
     numbers.  The process for communicating this recall would be within
     the BRSKI-MASA protocol.  Neither this specification nor [RFC8995]
     provides for consultation of a Certification Revocation List (CRL) or
     Open Certificate Status Protocol (OCSP) by a Registrar when
     evaluating an IDevID certificate.  However, the BRSKI-MASA protocol
     submits the IDevID from the Registrar to the manufacturer's MASA and
     a manufacturer would have an opportunity to decline to issue a
     voucher for a device which they believe has become compromised.

     It may be difficult for a manufacturer to determine when an IDevID
     private key has been disclosed.  Two situations present themselves:
     in the first situation a compromised private key might be reused in a
     counterfeit device, which is sold to another customer.  This would
     present itself as an onboarding of the same device in two different
     networks.  The manufacturer may become suspicious seeing two voucher
     requests for the same device from different Registrars.  Such
     activity could be indistinguishable from a device which has been
     resold from one operator to another, or re-deployed by an operator
     from one location to another.















  Richardson, et al.       Expires 31 August 2026                [Page 45]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     In the second situation, an attacker having compromised the IDevID
     private key of a device might then install malware into the same
     device and attempt to return it to service.  The device, now blank,
     would go through a second onboarding process with the original
     Registrar.  Such a Registrar could notice that the device has been
     "factory reset" and alert the operator to this situation.  One remedy
     against the presence of malware is through the use of Remote
     Attestation such as described in [RFC9334].  Future work will need to
     specify a background-check Attestation flow as part of the voucher
     request/response process.  Attestation may still require access to a
     private key (e.g. IDevID private key) in order to sign Evidence, so a
     primary goal should be to keep any private key safe within the
     Pledge.

     In larger, more expensive, systems there is budget (power, space, and
     bill of materials) to include more specific defenses for a private
     key.  For instance, this includes putting the IDevID private key in a
     Trusted Platform Module (TPM), or use of Trusted Execution
     Environments (TEE) for access to the key.  On smaller IoT devices,
     the cost and power budget for an extra part is often prohibitive.

     It is becoming more and more common for CPUs to have an internal set
     of one-time fuses that can be programmed (often they are "burnt" by a
     laser) at the factory.  This section of memory is only accessible in
     some privileged CPU state.  The use of this kind of CPU is
     appropriate as it provides significant resistance against key
     disclosure even when the device can be disassembled by an attacker.

     In a number of industry verticals, there is increasing concern about
     counterfeit parts.  These may be look-alike parts created in a
     different factory, or parts which are created in the same factory
     during an illegal night-shift, but which are not subject to the
     appropriate level of quality control.  The use of a manufacturer-
     signed IDevID certificate provides for discovery of the pedigree of
     each part, and this often justifies the cost of the security measures
     associated with storing the private key.

  14.3.  Security of the BRSKI-MASA Protocol

     Section 7.1 explains why no CoAPS version of the BRSKI-MASA protocol
     is specified.  The connection from the Registrar to the MASA
     continues to be HTTPS as in [RFC8995].

     This choice enables the BRSKI-MASA protocol, which operates over the
     open Internet, to be secured using standard solutions that are
     commonly used for HTTPS over the Internet.  The use of UDP protocols
     across the Internet is sometimes fraught with security challenges.
     Denial-of-service attacks against UDP based protocols are trivial as



  Richardson, et al.       Expires 31 August 2026                [Page 46]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     there is no three-way handshake as done for TCP.  The three-way
     handshake of TCP guarantees that the node sending the connection
     request is reachable using the origin IP address.  While DTLS
     contains an option to do a stateless challenge -- a process actually
     stronger than that done by TCP -- it is not yet common for this
     mechanism to be available in hardware at multigigabit speeds.

     Also, in many enterprise networks outgoing UDP connections can be
     treated as suspicious, which could effectively block CoAP connections
     for some firewall configurations.  Reducing the complexity of MASA
     (i.e. less protocols supported) also reduces its potential attack
     surface, which is relevant since the MASA is 24/7 exposed on the
     Internet and accepting (untrusted) incoming connections.

  14.4.  Registrar Certificate May Be Self-signed

     The provisional (D)TLS connection formed by the Pledge with the
     Registrar does not authenticate the Registrar's identity.  This
     Registrar's identity is validated by the [RFC8366bis] voucher that is
     issued by the MASA, signed with a trust anchor that was built-in to
     the Pledge.

     The Registrar may therefore use any certificate, including a self-
     signed one.  The only restrictions on the certificate is that it MUST
     have EKU bits set as detailed in Section 6.1.5 and Section 7.4.

  14.5.  Use of RPK Alternatives to 'proximity-registrar-cert'

     In Section 9 of [RFC8366bis] two compact alternative attributes for
     'proximity-registrar-cert' are defined that include an RPK:
     'proximity-registrar-pubk' and 'proximity-registrar-pubk-sha256'.
     The Pledge can use these attributes in its PVR to identify the
     Registrar based on its public key only.  Since the full certificate
     of the proximate Registrar is not included, use of these attributes
     by a Pledge implies that a Registrar could insert another certificate
     with the same public key identity into the RVR.  For example, an
     older or a newer version of its certificate.  The MASA will not be
     able to detect such act by the Registrar.  But since any certificate
     the Registrar could insert in this way still encodes its own identity
     the additional risk of using the RPK alternatives is negligible.

     When a Registrar sees a PVR that uses one of 'proximity-registrar-
     pubk' or 'proximity-registrar-pubk-sha256' attributes, this implies
     the Registrar must include the certificate identified by these
     attributes into its RVR.  Otherwise, the MASA is unable to verify
     proximity.  This requirement is already implied by the "MUST"
     requirement in Section 8.1.




  Richardson, et al.       Expires 31 August 2026                [Page 47]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  15.  IANA Considerations

  15.1.  Resource Type Link Target Attribute Values Registry

     Additions to the "Resource Type (rt=) Link Target Attribute Values"
     IANA registry, within the "CoRE Parameters" registry group are
     specified below.

     Reference: [This RFC]

          +==========+==============================================+
          | Value    | Description                                  |
          +==========+==============================================+
          | brski    | Base resource of all Bootstrapping Remote    |
          |          | Secure Key Infrastructure (cBRSKI) resources |
          +----------+----------------------------------------------+
          | brski.rv | cBRSKI request voucher resource              |
          +----------+----------------------------------------------+
          | brski.vs | cBRSKI voucher status telemetry resource     |
          +----------+----------------------------------------------+
          | brski.es | cBRSKI enrollment status telemetry resource  |
          +----------+----------------------------------------------+
          | ace.est  | Base resource of all Enrollment over Secure  |
          |          | Transport CoAPS (EST-coaps) resources        |
          +----------+----------------------------------------------+

               Table 2: Resource Type (rt) link target attribute
                        values for cBRSKI and EST- coaps

     Note that the resource type "brski" identifies a base resource in a
     resource hierarchy on a CoAP server, where its sub-resources each
     have one of the resource types "brski.*" as defined by this
     specification.  Similarly, the resource type "ace.est" identifies a
     base resource in a resource hierarchy, where its sub-resources each
     have one of the resource types "ace.est.*" as defined by [RFC9148].

  15.2.  Media Types Registry

     This section registers the media type application/voucher+cose in the
     "Media Types" IANA registry.  This media type is used to indicate
     that the content is a CBOR voucher or voucher request signed with a
     COSE_Sign1 structure [RFC9052] as defined in this document.

  15.2.1.  application/voucher+cose







  Richardson, et al.       Expires 31 August 2026                [Page 48]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Type name:  application
     Subtype name:  voucher+cose
     Required parameters:  N/A
     Optional parameters:  N/A
     Encoding considerations:  binary (CBOR)
     Security considerations:  Section 14 of [This RFC], and Section 12
       of [RFC 9052] for the COSE_Sign1 structured that is used.
     Interoperability considerations:  Section 15.2.2 of [This RFC]
     Published specification:  [This RFC]
     Applications that use this media type:  cBRSKI/ANIMA, 6TiSCH, and
       other zero-touch onboarding systems
     Fragment identifier considerations: N/A
     Additional information:
       Deprecated alias names for this type: N/A
       Magic number(s):  N/A
       File extension(s):  .vch
       Macintosh file type code(s):  N/A
     Person & email address to contact for further information:  IETF
       ANIMA Working Group (anima@ietf.org) or IETF Operations and
       Management Area Working Group (opsawg@ietf.org)
     Intended usage:  COMMON
     Restrictions on usage:  N/A
     Author:  ANIMA WG
     Change controller:  IETF
     Provisional registration? (standards tree only):  NO

  15.2.2.  Interoperability Considerations for application/voucher+cose

     The media type defined here does not have any parameter to indicate
     whether names are used, or SID integers are used, or both can be
     mixed within a voucher data item.  In absence of any specific further
     knowledge about this, a mixed use of SID integers and names MUST be
     assumed, which is equivalent to the application/yang-data+cbor media
     type ([RFC9254]) without the optional 'id' parameter.

     Furthermore,

     *  a Registrar assumes that mixed SIDs/names MAY be present in a
        received PVR or voucher;

     *  a MASA assumes that mixed SIDs/names MAY be present in a received
        RVR;

     *  a Pledge assumes, depending on its implementation, that SIDs are
        present only, or names are present only, or mixed SIDs/names are
        present in a received voucher.





  Richardson, et al.       Expires 31 August 2026                [Page 49]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Because the MASA and Pledge are under control (either directly or by
     contract) of the same manufacturer, they can be co-developed
     regarding the type of identifiers produced and identifiers consumed
     in order to guarantee interoperability.

  15.3.  CoAP Content-Formats Registry

     IANA has allocated ID 836 from the "CoAP Content-Formats" registry as
     shown below.

          +==========================+==========+=====+============+
          | Media type               | Encoding | ID  | Reference  |
          +==========================+==========+=====+============+
          | application/voucher+cose | -        | 836 | [This RFC] |
          +--------------------------+----------+-----+------------+

             Table 3: Additions to the IANA CoAP Content-Formats
                                   Registry

  15.4.  Update to BRSKI Well-Known URIs Registry

     This section updates the "BRSKI Well-Known URIs" IANA registry of the
     Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters
     Registry group, by adding a new column "Short Path Segment",
     clarifying existing "Description" values, and renaming the column
     "URI" to "Path Segment".

     The new "Short Path Segment" entry denotes a shorter alternative to
     Path Segment for the resource that can be used by a client in a CoAP
     request on a well-known BRSKI resource.  A value "N/A" can be
     registered to denote that there is no short path segment defined.

     The contents of the registry with these changes applied are as
     follows:

















  Richardson, et al.       Expires 31 August 2026                [Page 50]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     +=================+============+=======================+============+
     | Path Segment    | Short      | Description           | Reference  |
     |                 | Path       |                       |            |
     |                 | Segment    |                       |            |
     +=================+============+=======================+============+
     | requestvoucher  | rv         | Request voucher:      | [RFC8995], |
     |                 |            | Pledge to Registrar,  | [This RFC] |
     |                 |            | and Registrar to MASA |            |
     +-----------------+------------+-----------------------+------------+
     | voucher_status  | vs         | Voucher status        | [RFC8995], |
     |                 |            | telemetry: Pledge to  | [This RFC] |
     |                 |            | Registrar             |            |
     +-----------------+------------+-----------------------+------------+
     | requestauditlog | N/A        | Request audit log:    | [RFC8995]  |
     |                 |            | Registrar to MASA     |            |
     +-----------------+------------+-----------------------+------------+
     | enrollstatus    | es         | Enrollment status     | [RFC8995], |
     |                 |            | telemetry: Pledge to  | [This RFC] |
     |                 |            | Registrar             |            |
     +-----------------+------------+-----------------------+------------+

           Table 4: Update of the IANA BRSKI Well-Known URIs Registry

  15.5.  Structured Syntax Suffixes Registry

     This section registers the "+cose" suffix in the "Structured Syntax
     Suffixes" IANA Registry based on the [RFC6838] procedure.
























  Richardson, et al.       Expires 31 August 2026                [Page 51]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Name:       CBOR Object Signing and Encryption (COSE) object
     +suffix:    +cose
     References: the application/cose media type [RFC9052]
     Encoding considerations: binary (CBOR)
     Interoperability considerations:
       the application/cose media type has an optional parameter
       "cose-type". Any new media type that uses the +cose suffix
       and allows use of this parameter MUST specify this
       explicitly, per Section 4.3 of [RFC6838]. If the parameter
       "cose-type" is allowed, its usage MUST be identical to the
       usage defined for the application/cose media type in
       Section 2 of [RFC9052].
       A COSE processor handling a media type foo+cose and which
       does not know the specific type "foo" SHOULD use the
       cose-type COSE tag, if present, or cose-type parameter, if
       present, to determine the specific COSE object type during
       processing. If the specific type cannot be determined,
       it MUST assume only the generic COSE object structure and
       it MUST NOT perform security-critical operations using the
       COSE object.
     Fragment identifier considerations: N/A
     Security considerations: see [RFC9052]
     Contact:
       IETF COSE Working Group (cose@ietf.org) or
       IESG (iesg@ietf.org)
     Author/Change controller:
       IETF ANIMA Working Group (anima@ietf.org).
       IESG has change control over this registration.

  16.  References

  16.1.  Normative References

     [I-D.ietf-anima-constrained-join-proxy]
                Dijk, E., Richardson, M., Van der Stok, P., and P.
                Kampanakis, "Join Proxy for Bootstrapping of Constrained
                Network Elements", Work in Progress, Internet-Draft,
                draft-ietf-anima-constrained-join-proxy-18, 19 October
                2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
                anima-constrained-join-proxy-18>.

     [I-D.ietf-core-uri-path-abbrev]
                Amsüss, C. and M. Richardson, "URI-Path abbreviation in
                CoAP", Work in Progress, Internet-Draft, draft-ietf-core-
                uri-path-abbrev-02, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-core-
                uri-path-abbrev-02>.




  Richardson, et al.       Expires 31 August 2026                [Page 52]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     [ieee802-1AR]
                "IEEE 802.1AR Secure Device Identity", IEEE Standards
                Association, 2018,
                <https://standards.ieee.org/ieee/802.1AR/6995/>.

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

     [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
                Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
                <https://www.rfc-editor.org/rfc/rfc4193>.

     [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
                "Internet X.509 Public Key Infrastructure Certificate
                Management Protocol (CMP)", RFC 4210,
                DOI 10.17487/RFC4210, September 2005,
                <https://www.rfc-editor.org/rfc/rfc4210>.

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

     [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
                Extensions: Extension Definitions", RFC 6066,
                DOI 10.17487/RFC6066, January 2011,
                <https://www.rfc-editor.org/rfc/rfc6066>.

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

     [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
                Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
                <https://www.rfc-editor.org/rfc/rfc6690>.

     [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
                DOI 10.17487/RFC6762, February 2013,
                <https://www.rfc-editor.org/rfc/rfc6762>.

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




  Richardson, et al.       Expires 31 August 2026                [Page 53]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
                Weiler, S., and T. Kivinen, "Using Raw Public Keys in
                Transport Layer Security (TLS) and Datagram Transport
                Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
                June 2014, <https://www.rfc-editor.org/rfc/rfc7250>.

     [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
                Application Protocol (CoAP)", RFC 7252,
                DOI 10.17487/RFC7252, June 2014,
                <https://www.rfc-editor.org/rfc/rfc7252>.

     [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
                the Constrained Application Protocol (CoAP)", RFC 7959,
                DOI 10.17487/RFC7959, August 2016,
                <https://www.rfc-editor.org/rfc/rfc7959>.

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

     [RFC8366bis]
                Watsen, K., Richardson, M., Dijk, E., Eckert, T. T., and
                Q. Ma, "A Voucher Artifact for Bootstrapping Protocols",
                Work in Progress, Internet-Draft, draft-ietf-anima-
                rfc8366bis-27, 26 February 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
                rfc8366bis-27>.

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

     [RFC8449]  Thomson, M., "Record Size Limit Extension for TLS",
                RFC 8449, DOI 10.17487/RFC8449, August 2018,
                <https://www.rfc-editor.org/rfc/rfc8449>.

     [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
                Definition Language (CDDL): A Notational Convention to
                Express Concise Binary Object Representation (CBOR) and
                JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
                June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

     [RFC8710]  Fossati, T., Hartke, K., and C. Bormann, "Multipart
                Content-Format for the Constrained Application Protocol
                (CoAP)", RFC 8710, DOI 10.17487/RFC8710, February 2020,
                <https://www.rfc-editor.org/rfc/rfc8710>.





  Richardson, et al.       Expires 31 August 2026                [Page 54]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949,
                DOI 10.17487/RFC8949, December 2020,
                <https://www.rfc-editor.org/rfc/rfc8949>.

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

     [RFC9031]  Vučinić, M., Ed., Simon, J., Pister, K., and M.
                Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
                RFC 9031, DOI 10.17487/RFC9031, May 2021,
                <https://www.rfc-editor.org/rfc/rfc9031>.

     [RFC9032]  Dujovne, D., Ed. and M. Richardson, "Encapsulation of
                6TiSCH Join and Enrollment Information Elements",
                RFC 9032, DOI 10.17487/RFC9032, May 2021,
                <https://www.rfc-editor.org/rfc/rfc9032>.

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

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

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

     [RFC9254]  Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann,
                C., and M. Richardson, "Encoding of Data Modeled with YANG
                in the Concise Binary Object Representation (CBOR)",
                RFC 9254, DOI 10.17487/RFC9254, July 2022,
                <https://www.rfc-editor.org/rfc/rfc9254>.






  Richardson, et al.       Expires 31 August 2026                [Page 55]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     [RFC9360]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Header Parameters for Carrying and Referencing X.509
                Certificates", RFC 9360, DOI 10.17487/RFC9360, February
                2023, <https://www.rfc-editor.org/rfc/rfc9360>.

     [RFC9525]  Saint-Andre, P. and R. Salz, "Service Identity in TLS",
                RFC 9525, DOI 10.17487/RFC9525, November 2023,
                <https://www.rfc-editor.org/rfc/rfc9525>.

  16.2.  Informative References

     [COSE-registry]
                IANA, "CBOR Object Signing and Encryption (COSE) registry
                group", 11 January 2017,
                <https://www.iana.org/assignments/cose/cose.xhtml>.

     [I-D.ietf-6lo-mesh-link-establishment]
                Kelsey, R., "Mesh Link Establishment", Work in Progress,
                Internet-Draft, draft-ietf-6lo-mesh-link-establishment-00,
                1 December 2015, <https://datatracker.ietf.org/doc/html/
                draft-ietf-6lo-mesh-link-establishment-00>.

     [I-D.ietf-anima-brski-discovery]
                Eckert, T. T. and E. Dijk, "BRSKI discovery and
                variations", Work in Progress, Internet-Draft, draft-ietf-
                anima-brski-discovery-09, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
                brski-discovery-09>.

     [I-D.ietf-anima-jws-voucher]
                Werner, T. and M. Richardson, "JWS signed Voucher
                Artifacts for Bootstrapping Protocols", Work in Progress,
                Internet-Draft, draft-ietf-anima-jws-voucher-16, 15
                January 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-anima-jws-voucher-16>.

     [I-D.ietf-cbor-edn-literals]
                Bormann, C., "CBOR Extended Diagnostic Notation (EDN)",
                Work in Progress, Internet-Draft, draft-ietf-cbor-edn-
                literals-19, 16 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-cbor-
                edn-literals-19>.









  Richardson, et al.       Expires 31 August 2026                [Page 56]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     [I-D.ietf-cose-cbor-encoded-cert]
                Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
                M. Furuhed, "CBOR Encoded X.509 Certificates (C509
                Certificates)", Work in Progress, Internet-Draft, draft-
                ietf-cose-cbor-encoded-cert-16, 25 January 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
                cbor-encoded-cert-16>.

     [I-D.richardson-anima-masa-considerations]
                Richardson, M. and W. Pan, "Operational Considerations for
                Voucher infrastructure for BRSKI MASA", Work in Progress,
                Internet-Draft, draft-richardson-anima-masa-
                considerations-09, 22 January 2025,
                <https://datatracker.ietf.org/doc/html/draft-richardson-
                anima-masa-considerations-09>.

     [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
                Control Message Protocol (ICMPv6) for the Internet
                Protocol Version 6 (IPv6) Specification", STD 89,
                RFC 4443, DOI 10.17487/RFC4443, March 2006,
                <https://www.rfc-editor.org/rfc/rfc4443>.

     [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
                RFC 5652, DOI 10.17487/RFC5652, September 2009,
                <https://www.rfc-editor.org/rfc/rfc5652>.

     [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
                Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
                DOI 10.17487/RFC6282, September 2011,
                <https://www.rfc-editor.org/rfc/rfc6282>.

     [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
                Bormann, "Neighbor Discovery Optimization for IPv6 over
                Low-Power Wireless Personal Area Networks (6LoWPANs)",
                RFC 6775, DOI 10.17487/RFC6775, November 2012,
                <https://www.rfc-editor.org/rfc/rfc6775>.

     [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
                Specifications and Registration Procedures", BCP 13,
                RFC 6838, DOI 10.17487/RFC6838, January 2013,
                <https://www.rfc-editor.org/rfc/rfc6838>.

     [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
                Constrained-Node Networks", RFC 7228,
                DOI 10.17487/RFC7228, May 2014,
                <https://www.rfc-editor.org/rfc/rfc7228>.





  Richardson, et al.       Expires 31 August 2026                [Page 57]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
                RFC 7950, DOI 10.17487/RFC7950, August 2016,
                <https://www.rfc-editor.org/rfc/rfc7950>.

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

     [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
                Autonomic Signaling Protocol (GRASP)", RFC 8990,
                DOI 10.17487/RFC8990, May 2021,
                <https://www.rfc-editor.org/rfc/rfc8990>.

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://www.rfc-editor.org/rfc/rfc9334>.

     [RFC9528]  Selander, G., Preuß Mattsson, J., and F. Palombini,
                "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
                DOI 10.17487/RFC9528, March 2024,
                <https://www.rfc-editor.org/rfc/rfc9528>.

     [RFC9595]  Veillette, M., Ed., Pelov, A., Ed., Petrov, I., Ed.,
                Bormann, C., and M. Richardson, "YANG Schema Item
                iDentifier (YANG SID)", RFC 9595, DOI 10.17487/RFC9595,
                July 2024, <https://www.rfc-editor.org/rfc/rfc9595>.

     [RFC9597]  Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in
                COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024,
                <https://www.rfc-editor.org/rfc/rfc9597>.

     [Thread]   Thread Group, Inc, "Thread Group website", February 2026,
                <https://www.threadgroup.org/>.

  Appendix A.  Software and Library Support for cBRSKI

     This appendix lists software and security libraries that may be
     useful for implementing cBRSKI functionality.

  A.1.  Open Source cBRSKI Implementations

     There are a few ongoing open source projects to support cBRSKI
     development and testing.  These include:

     *  OpenThread Registrar (OT Registrar) - a cBRSKI Registrar, test
        MASA server, and test Pledge written in Java.  Link
        (https://github.com/EskoDijk/ot-registrar)



  Richardson, et al.       Expires 31 August 2026                [Page 58]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     *  OpenThread CCM (pre-alpha) - a cBRSKI Pledge and Join Proxy for
        OpenThread-based IoT nodes, written in C/C++. OpenThread nodes
        implement the [Thread] protocol.  Link
        (https://github.com/EskoDijk/openthread/pull/7)

     *  OpenThread Network Simulator v2 (OTNS2) - a CLI + GUI simulator
        for OpenThread IoT nodes in 6LoWPAN [RFC6282] mesh networks, able
        to accurately simulate cBRSKI Pledges onboarding (pre-alpha
        functionality) to a Thread mesh network via an OT Registrar.  Link
        (https://github.com/EskoDijk/ot-ns/pull/165)

     *  Fountain - a BRSKI/6TiSCH Registrar with support for COSE-signed
        vouchers, written in Ruby.  Link (https://github.com/AnimaGUS-
        minerva/fountain)

  A.2.  Security Library Support

     For the implementation of BRSKI/cBRSKI, the use of a software library
     to manipulate PKIX certificates, establish secure (D)TLS connections,
     and use crypto algorithms is often beneficial.  Two C-based examples
     are OpenSSL and mbedtls.  Others more targeted to specific platforms
     or languages exist.  It is important to realize that the library
     interfaces differ significantly between libraries.

     Libraries do not support all known crypto algorithms.  Before
     deciding on a library, it is important to look at their supported
     crypto algorithms and the roadmap for future support.  Apart from
     availability, the library footprint, and the required execution
     cycles should be investigated beforehand.

     The handling of certificates usually includes the checking of a
     certificate chain.  In some libraries, chains are constructed and
     verified on the basis of a set of certificates, the trust anchor
     (usually a self signed root CA), and the target certificate.  In
     other libraries, the chain must be constructed beforehand and obey
     ordering criteria.  Verification always includes the checking of the
     signatures.  Less frequent is the checking the validity of the dates
     or checking the existence of a revoked certificate in the chain
     against a set of revoked certificates.  Checking the chain on the
     consistency of the certificate extensions which specify the use of
     the certificate usually needs to be programmed explicitly.

     A library can be used to construct a (D)TLS connection.  It is useful
     to realize that differences between (D)TLS implementations will occur
     due to the differences in the certificate checks supported by the
     library.  On top of that, checks between client and server
     certificates enforced by (D)TLS are not always helpful for a BRSKI
     implementation.  For example, the certificates of Pledge and



  Richardson, et al.       Expires 31 August 2026                [Page 59]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Registrar are usually not related when the BRSKI protocol is started.
     It must be verified that checks on the relation between client and
     server certificates do not hamper a succeful DTLS connection
     establishment.

  A.2.1.  OpensSSL Example Code

     From OpenSSL's apps/verify.c :

     <CODE BEGINS>
     X509 *x = NULL;
     int i = 0, ret = 0;
     X509_STORE_CTX *csc;
     STACK_OF(X509) *chain = NULL;
     int num_untrusted;

     x = load_cert(file, "certificate file");
     if (x == NULL)
         goto end;

     csc = X509_STORE_CTX_new();
     if (csc == NULL) {
         BIO_printf(bio_err, "error %s: X.509 store context"
                    "allocation failed\n",
                    (file == NULL) ? "stdin" : file);
         goto end;
     }

     X509_STORE_set_flags(ctx, vflags);
     if (!X509_STORE_CTX_init(csc, ctx, x, uchain)) {
         X509_STORE_CTX_free(csc);
         BIO_printf(bio_err,
                    "error %s: X.509 store context"
                    "initialization failed\n",
                    (file == NULL) ? "stdin" : file);
         goto end;
     }
     if (tchain != NULL)
         X509_STORE_CTX_set0_trusted_stack(csc, tchain);
     if (crls != NULL)
         X509_STORE_CTX_set0_crls(csc, crls);

     i = X509_verify_cert(csc);
     X509_STORE_CTX_free(csc);

     <CODE ENDS>





  Richardson, et al.       Expires 31 August 2026                [Page 60]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  A.2.2.  mbedTLS Example Code

     <CODE BEGINS>
     mbedtls_x509_crt cert;
     mbedtls_x509_crt caCert;
     uint32_t         certVerifyResultFlags;
     // ...
     int result = mbedtls_x509_crt_verify(&cert, &caCert, NULL, NULL,
                                  &certVerifyResultFlags, NULL, NULL);

     <CODE ENDS>

  A.3.  Generating Certificates with OpenSSL

     This informative appendix shows example Bash shell scripts to
     generate test PKIX certificates for the Pledge IDevID, the Registrar
     and the MASA.  The shell scripts cannot be run stand-alone because
     they depend on input files which are not all included in this
     appendix.  Nevertheless, these scripts may provide guidance on how
     OpenSSL can be configured for generating cBRSKI certificates.

     The scripts were tested with OpenSSL 3.0.2.  Older versions may not
     work -- OpenSSL 1.1.1 for example does not support all extensions
     used.



























  Richardson, et al.       Expires 31 August 2026                [Page 61]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     <CODE BEGINS>
     #!/bin/bash
     # File: create-cert-Pledge.sh
     # Create new cert for: Pledge IDevID

     # days certificate is valid - try to get close to the 802.1AR
     # specified 9999-12-31 end date.
     SECONDS1=`date +%s` # time now
     SECONDS2=`date --date="9999-12-31 23:59:59Z" +%s` # target end time
     let VALIDITY="(${SECONDS2}-${SECONDS1})/(24*3600)"
     echo "Using validity param -days ${VALIDITY}"

     NAME=pledge

     # create csr for device
     # conform to 802.1AR guidelines, using only CN + serialNumber when
     # manufacturer is already present as CA.
     # CN is not even mandatory, but just good practice.
     openssl req -new -key keys/privkey_pledge.pem -out $NAME.csr -subj \
                  "/CN=Stok IoT sensor Y-42/serialNumber=JADA123456789"

     # sign csr - it uses faketime only to get endtime to 23:59:59Z
     faketime '23:59:59Z' \
     openssl x509 -set_serial 32429 -CAform PEM -CA output/masa_ca.pem \
       -CAkey keys/privkey_masa_ca.pem -extfile x509v3.ext -extensions \
       pledge_ext -req -in $NAME.csr -out output/$NAME.pem \
       -days $VALIDITY -sha256

     # Note: alternative method using 'ca' command. Currently
     # doesn't work without 'country' subject field.
     # openssl ca -rand_serial -enddate 99991231235959Z -certform PEM \
     #  -cert output/masa_ca.pem -keyfile keys/privkey_masa_ca.pem \
     #  -extfile x509v3.ext -extensions pledge_ext -in $NAME.csr \
     #  -out $NAME.pem -outdir output

     # delete temp files
     rm -f $NAME.csr

     # convert to .der format
     openssl x509 -in output/$NAME.pem -inform PEM -out output/$NAME.der \
                  -outform DER

     <CODE ENDS>








  Richardson, et al.       Expires 31 August 2026                [Page 62]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     <CODE BEGINS>
     # File: x509v3.ext
     # This file contains all X509v3 extension definitions for OpenSSL
     # certificate generation. Each certificate has its own _ext
     # section below.

     [ req ]
     prompt = no

     [ masa_ca_ext ]
     subjectAltName=email:info@masa.stok.nl
     keyUsage = critical,digitalSignature, keyCertSign, cRLSign
     basicConstraints = critical,CA:TRUE,pathlen:3
     subjectKeyIdentifier=hash
     authorityKeyIdentifier=keyid

     [ pledge_ext ]
     keyUsage = critical,digitalSignature, nonRepudiation, \
                keyEncipherment, dataEncipherment
     # basicConstraints for a non-CA cert MAY be marked either
     # non-critical or critical.
     basicConstraints = CA:FALSE
     # Don't include subjectKeyIdentifier (SKI) - see 802.1AR-2018
     subjectKeyIdentifier = none
     authorityKeyIdentifier=keyid
     # Include the MASA URI
     1.3.6.1.5.5.7.1.32 = ASN1:IA5STRING:masa.stok.nl

     [ domain_ca_ext ]
     subjectAltName=email:help@custom-er.example.com
     keyUsage = critical, keyCertSign, digitalSignature, cRLSign
     basicConstraints=critical,CA:TRUE
     # RFC 5280 4.2.1.1 : AKI MAY be omitted, and MUST be non-critical;
     # SKI MUST be non-critical
     subjectKeyIdentifier=hash

     [ registrar_ext ]
     keyUsage = critical, digitalSignature, nonRepudiation, \
                keyEncipherment, dataEncipherment
     basicConstraints=CA:FALSE
     subjectKeyIdentifier=hash
     authorityKeyIdentifier=keyid
     # Set Registrar 'RA' flag along with TLS client/server usage
     #  see draft-ietf-anima-constrained-voucher#section-7.3
     #  see tools.ietf.org/html/rfc6402#section-2.10
     #  see www.openssl.org/docs/man1.1.1/man5/x509v3_config.html
     extendedKeyUsage = critical,1.3.6.1.5.5.7.3.28, serverAuth, \
                        clientAuth



  Richardson, et al.       Expires 31 August 2026                [Page 63]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     <CODE ENDS>

     <CODE BEGINS>
     #!/bin/bash
     # File: create-cert-Registrar.sh
     # Create new cert for: Registrar in a company domain

     # days certificate is valid
     VALIDITY=1095

     # cert filename
     NAME=registrar

     # create csr
     openssl req -new -key keys/privkey_registrar.pem -out $NAME.csr \
      -subj "/CN=Custom-ER Registrar/OU=Office dept/O=Custom-ER, Inc./\
     L=Ottowa/ST=ON/C=CA"

     # sign csr
     openssl x509 -set_serial 0xC3F62149B2E30E3E -CAform PEM -CA \
      output/domain_ca.pem -extfile x509v3.ext -extensions registrar_ext \
      -req -in $NAME.csr -CAkey keys/privkey_domain_ca.pem \
      -out output/$NAME.pem -days $VALIDITY -sha256

     # delete temp files
     rm -f $NAME.csr

     # convert to .der format
     openssl x509 -in output/$NAME.pem -inform PEM -out output/$NAME.der \
                  -outform DER

     <CODE ENDS>



















  Richardson, et al.       Expires 31 August 2026                [Page 64]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     <CODE BEGINS>
     #!/bin/bash
     # File: create-cert-MASA.sh
     # Create new cert for: MASA CA, self-signed CA certificate

     # days certificate is valid
     VALIDITY=3650

     NAME=masa_ca

     # create csr
     openssl req -new -key keys/privkey_masa_ca.pem -out $NAME.csr \
                 -subj "/CN=masa.stok.nl/O=vanderstok/L=Helmond/C=NL"

     # sign csr
     mkdir output >& /dev/null
     openssl x509 -set_serial 0xE39CDA17E1386A0A  -extfile x509v3.ext \
      -extensions masa_ca_ext -req -in $NAME.csr \
      -signkey keys/privkey_masa_ca.pem -out output/$NAME.pem \
      -days $VALIDITY -sha256

     # delete temp files
     rm -f $NAME.csr

     # convert to .der format
     openssl x509 -in output/$NAME.pem -inform PEM -out output/$NAME.der \
                  -outform DER

     <CODE ENDS>

  Appendix B.  cBRSKI Message Examples

     This appendix extends the EST-coaps message examples from Appendix A
     of [RFC9148] with cBRSKI messages.  The CoAP headers are only fully
     worked out for the first example, enrollstatus.

  B.1.  enrollstatus

     A coaps enrollstatus message from Pledge to Registrar can be as
     follows:

       REQ: POST /b/es
         Content-Format: 60 (application/cbor)
         Payload: <binary CBOR encoding of an enrollstatus map>

     The corresponding CoAP header fields for this request are shown
     below.




  Richardson, et al.       Expires 31 August 2026                [Page 65]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


       Ver = 1
       T = 0 (CON)
       TKL = 1
       Code = 0x02 (0.02 is POST method)
       Message ID = 0xab0f
       Token = 0x4d
       Options
        Option  (Uri-Path)
          Option Delta = 0xb   (option nr = 11)
          Option Length = 0x1
          Option Value = "b"
        Option  (Uri-Path)
          Option Delta = 0x0   (option nr = 11)
          Option Length = 0x2
          Option Value = "es"
        Option  (Content-Format)
          Option Delta = 0x1   (option nr = 12)
          Option Length = 0x1
          Option Value = 60    (application/cbor)
       Payload Marker = 0xFF
       Payload = A26776657273696F6E0166737461747573F5 (18 bytes binary)

     The Uri-Host and Uri-Port Options are omitted because they coincide
     with the transport protocol (UDP) destination address and port
     respectively.

     The above binary CBOR enrollstatus payload looks as follows in CBOR
     diagnostic notation, for the case of enrollment success:

       {
         "version": 1,
         "status": true
        }

     Alternatively the payload could look as follows in case of enrollment
     failure, using the 'reason' map item value to describe the failure:

       Payload = A36776657273696F6E0166737461747573F466726561736F6E782A3C
                 496E666F726D61746976652068756D616E207265616461626C652065
                 72726F72206D6573736167653E    (69 bytes binary)

       {
         "version": 1,
         "status": false,
         "reason": "<Informative human readable error message>"
       }





  Richardson, et al.       Expires 31 August 2026                [Page 66]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     To indicate successful reception of the enrollmentstatus telemetry
     report, a response from the Registrar may then be:

       2.04 Changed

     Which in case of a piggybacked response has the following CoAP header
     fields:

       Ver=1
       T=2 (ACK)
       TKL=1
       Code = 0x44 (2.04 Changed)
       Message ID = 0xab0f
       Token = 0x4d

  B.2.  voucher_status

     A coaps voucher_status message from Pledge to Registrar can be as
     follows:

       REQ: POST /.well-known/brski/vs
         Content-Format: 60 (application/cbor)
         Payload:
         A46776657273696F6E0166737461747573F466726561736F6E7828496E66
         6F726D61746976652068756D616E2D7265616461626C65206572726F7220
         6D6573736167656E726561736F6E2D636F6E74657874A100764164646974
         696F6E616C20696E666F726D6174696F6E

     The request payload above is binary CBOR but represented here in
     hexadecimal for readability.  Below is the equivalent CBOR diagnostic
     format.

       {
         "version": 1,
         "status": false,
         "reason": "Informative human-readable error message",
         "reason-context": { 0: "Additional information" }
       }

     A success response without payload will then be sent by the Registrar
     back to the Pledge to indicate reception of the telemetry report:

       RES: 2.04 Changed








  Richardson, et al.       Expires 31 August 2026                [Page 67]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  Appendix C.  COSE-signed Voucher (Request) Examples

     This appendix provides examples of COSE-signed voucher requests and
     vouchers.  First, the used test keys and PKIX certificates are
     described, followed by examples of a constrained PVR, RVR and
     voucher.

  C.1.  Pledge, Registrar and MASA Keys

     This section documents the public and private keys used for all
     examples in this appendix.  These keys are not used in any production
     system, and must only be used for testing purposes.

  C.1.1.  Pledge IDevID Private Key

     -----BEGIN EC PRIVATE KEY-----
     MHcCAQEEIMv+C4dbzeyrEH20qkpFlWIH2FFACGZv9kW7rNWtSlYtoAoGCCqGSM49
     AwEHoUQDQgAESH6OUiYFRhfIgWl4GG8jHoj8a+8rf6t5s1mZ/4SePlKom39GQ34p
     VYryJ9aHmboLLfz69bzICQFKbkoQ5oaiew==
     -----END EC PRIVATE KEY-----

     Private-Key: (256 bit)
     priv:
         cb:fe:0b:87:5b:cd:ec:ab:10:7d:b4:aa:4a:45:95:
         62:07:d8:51:40:08:66:6f:f6:45:bb:ac:d5:ad:4a:
         56:2d
     pub:
         04:48:7e:8e:52:26:05:46:17:c8:81:69:78:18:6f:
         23:1e:88:fc:6b:ef:2b:7f:ab:79:b3:59:99:ff:84:
         9e:3e:52:a8:9b:7f:46:43:7e:29:55:8a:f2:27:d6:
         87:99:ba:0b:2d:fc:fa:f5:bc:c8:09:01:4a:6e:4a:
         10:e6:86:a2:7b
     ASN1 OID: prime256v1
     NIST CURVE: P-256

  C.1.2.  Registrar Private Key

     -----BEGIN PRIVATE KEY-----
     MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgYJ/MP0dWA9BkYd4W
     s6oRY62hDddaEmrAVm5dtAXE/UGhRANCAAQgMIVb6EaRCz7LFcr4Vy0+tWW9xlSh
     Xvr27euqi54WCMXJEMk6IIaPyFBNNw8bJvqXWfZ5g7t4hj7amsvqUST2
     -----END PRIVATE KEY-----









  Richardson, et al.       Expires 31 August 2026                [Page 68]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Private-Key: (256 bit)
     priv:
         60:9f:cc:3f:47:56:03:d0:64:61:de:16:b3:aa:11:
         63:ad:a1:0d:d7:5a:12:6a:c0:56:6e:5d:b4:05:c4:
         fd:41
     pub:
         04:20:30:85:5b:e8:46:91:0b:3e:cb:15:ca:f8:57:
         2d:3e:b5:65:bd:c6:54:a1:5e:fa:f6:ed:eb:aa:8b:
         9e:16:08:c5:c9:10:c9:3a:20:86:8f:c8:50:4d:37:
         0f:1b:26:fa:97:59:f6:79:83:bb:78:86:3e:da:9a:
         cb:ea:51:24:f6
     ASN1 OID: prime256v1
     NIST CURVE: P-256

  C.1.3.  MASA Private Key

     -----BEGIN PRIVATE KEY-----
     MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgrbJ1oU+HIJ2SWYAk
     DkBTL+YNPxQG+gwsMsZB94N8mZ2hRANCAASS9NVlWJdztwNY81yPlH2UODYWhlYA
     ZfsqnEPSFZKnq8mq8gF78ZVbYi6q2FEg8kkORY/rpIU/X7SQsRuD+wMW
     -----END PRIVATE KEY-----

     Private-Key: (256 bit)
     priv:
         ad:b2:75:a1:4f:87:20:9d:92:59:80:24:0e:40:53:
         2f:e6:0d:3f:14:06:fa:0c:2c:32:c6:41:f7:83:7c:
         99:9d
     pub:
         04:92:f4:d5:65:58:97:73:b7:03:58:f3:5c:8f:94:
         7d:94:38:36:16:86:56:00:65:fb:2a:9c:43:d2:15:
         92:a7:ab:c9:aa:f2:01:7b:f1:95:5b:62:2e:aa:d8:
         51:20:f2:49:0e:45:8f:eb:a4:85:3f:5f:b4:90:b1:
         1b:83:fb:03:16
     ASN1 OID: prime256v1
     NIST CURVE: P-256

  C.2.  Pledge, Registrar, Domain CA and MASA Certificates

     All keys and PKIX certificates used for the examples have been
     generated with OpenSSL - see Appendix A.3 for more details on
     certificate generation.  Below the certificates are listed that
     accompany the keys shown above.  Each certificate description is
     followed by the hexadecimal representation of the X.509 ASN.1 DER
     encoded certificate.  This representation can be for example decoded
     using an online ASN.1 decoder.

  C.2.1.  Pledge IDevID Certificate




  Richardson, et al.       Expires 31 August 2026                [Page 69]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Certificate:
     Data:
      Version: 3 (0x2)
      Serial Number: 32429 (0x7ead)
      Signature Algorithm: ecdsa-with-SHA256
      Issuer: CN = masa.stok.nl, O = vanderstok, L = Helmond,
              C = NL
      Validity
        Not Before: Dec  9 12:50:47 2022 GMT
        Not After : Dec 31 12:50:47 9999 GMT
      Subject: CN = Stok IoT sensor Y-42, serialNumber = JADA123456789
      Subject Public Key Info:
        Public Key Algorithm: id-ecPublicKey
          Public-Key: (256 bit)
          pub:
            04:48:7e:8e:52:26:05:46:17:c8:81:69:78:18:6f:
            23:1e:88:fc:6b:ef:2b:7f:ab:79:b3:59:99:ff:84:
            9e:3e:52:a8:9b:7f:46:43:7e:29:55:8a:f2:27:d6:
            87:99:ba:0b:2d:fc:fa:f5:bc:c8:09:01:4a:6e:4a:
            10:e6:86:a2:7b
          ASN1 OID: prime256v1
          NIST CURVE: P-256
      X509v3 extensions:
        X509v3 Key Usage: critical
          Digital Signature, Non Repudiation, Key Encipherment,
                  Data Encipherment
        X509v3 Basic Constraints:
          CA:FALSE
        X509v3 Authority Key Identifier:
          CB:8D:98:CA:74:C5:1B:58:DD:E7:AC:EF:86:9A:94:43:A8:D6:66:A6
        1.3.6.1.5.5.7.1.32:
           hl=2 l=  12 prim: IA5STRING     :masa.stok.nl

     Signature Algorithm: ecdsa-with-SHA256
     Signature Value:
      30:45:02:20:4d:89:90:7e:03:fb:52:56:42:0c:3f:c1:b1:f1:
      47:b5:b3:93:65:45:2e:be:50:db:67:85:8f:23:89:a2:3f:9e:
      02:21:00:95:33:69:d1:c6:db:f0:f1:f6:52:24:59:d3:0a:95:
      4e:b2:f4:96:a1:31:3c:7b:d9:2f:28:b3:29:71:bb:60:df

     Below is the hexadecimal representation of the binary X.509 DER-
     encoded certificate:









  Richardson, et al.       Expires 31 August 2026                [Page 70]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     308201CE30820174A00302010202027EAD300A06082A8648CE3D040302304B31
     15301306035504030C0C6D6173612E73746F6B2E6E6C31133011060355040A0C
     0A76616E64657273746F6B3110300E06035504070C0748656C6D6F6E64310B30
     09060355040613024E4C3020170D3232313230393132353034375A180F393939
     39313233313132353034375A3037311D301B06035504030C1453746F6B20496F
     542073656E736F7220592D3432311630140603550405130D4A41444131323334
     35363738393059301306072A8648CE3D020106082A8648CE3D03010703420004
     487E8E5226054617C8816978186F231E88FC6BEF2B7FAB79B35999FF849E3E52
     A89B7F46437E29558AF227D68799BA0B2DFCFAF5BCC809014A6E4A10E686A27B
     A35A3058300E0603551D0F0101FF0404030204F030090603551D130402300030
     1F0603551D23041830168014CB8D98CA74C51B58DDE7ACEF869A9443A8D666A6
     301A06082B06010505070120040E160C6D6173612E73746F6B2E6E6C300A0608
     2A8648CE3D040302034800304502204D89907E03FB5256420C3FC1B1F147B5B3
     9365452EBE50DB67858F2389A23F9E022100953369D1C6DBF0F1F6522459D30A
     954EB2F496A1313C7BD92F28B32971BB60DF

  C.2.2.  Registrar Certificate


































  Richardson, et al.       Expires 31 August 2026                [Page 71]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Certificate:
     Data:
      Version: 3 (0x2)
      Serial Number:
        c3:f6:21:49:b2:e3:0e:3e
      Signature Algorithm: ecdsa-with-SHA256
      Issuer: CN = Custom-ER Global CA, OU = IT, O = "Custom-ER, Inc.",
              L = San Jose, ST = CA, C = US
      Validity
        Not Before: Dec  9 12:50:47 2022 GMT
        Not After : Dec  8 12:50:47 2025 GMT
      Subject: CN = Custom-ER Registrar, OU = Office dept, O = "Custom-ER,
              Inc.", L = Ottowa, ST = ON, C = CA
      Subject Public Key Info:
        Public Key Algorithm: id-ecPublicKey
          Public-Key: (256 bit)
          pub:
            04:20:30:85:5b:e8:46:91:0b:3e:cb:15:ca:f8:57:
            2d:3e:b5:65:bd:c6:54:a1:5e:fa:f6:ed:eb:aa:8b:
            9e:16:08:c5:c9:10:c9:3a:20:86:8f:c8:50:4d:37:
            0f:1b:26:fa:97:59:f6:79:83:bb:78:86:3e:da:9a:
            cb:ea:51:24:f6
          ASN1 OID: prime256v1
          NIST CURVE: P-256
      X509v3 extensions:
        X509v3 Key Usage: critical
          Digital Signature, Non Repudiation, Key Encipherment,
                  Data Encipherment
        X509v3 Basic Constraints:
          CA:FALSE
        X509v3 Subject Key Identifier:
          C9:08:0B:38:7D:8D:D8:5B:3A:59:E7:EC:10:0B:86:63:93:A9:CA:4C
        X509v3 Authority Key Identifier:
          92:EA:76:40:40:4A:8F:AB:4F:27:0B:F3:BC:37:9D:86:CD:72:80:F8
        X509v3 Extended Key Usage: critical
          CMC Registration Authority, TLS Web Server Authentication,
                  TLS Web Client Authentication
     Signature Algorithm: ecdsa-with-SHA256
     Signature Value:
      30:45:02:21:00:d8:4a:7c:69:2f:f9:58:6e:82:22:87:18:f6:
      3b:c3:05:f0:ae:b8:ae:ec:42:78:82:38:79:81:2a:5d:15:61:
      64:02:20:08:f2:3c:13:69:13:b0:2c:e2:63:09:d5:99:4f:eb:
      75:70:af:af:ed:98:cd:f1:12:11:c0:37:f7:18:4d:c1:9d

     Below is the hexadecimal representation of the binary X.509 DER-
     encoded certificate:





  Richardson, et al.       Expires 31 August 2026                [Page 72]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     3082026D30820213A003020102020900C3F62149B2E30E3E300A06082A8648CE
     3D0403023072311C301A06035504030C13437573746F6D2D455220476C6F6261
     6C204341310B3009060355040B0C02495431183016060355040A0C0F43757374
     6F6D2D45522C20496E632E3111300F06035504070C0853616E204A6F7365310B
     300906035504080C024341310B3009060355040613025553301E170D32323132
     30393132353034375A170D3235313230383132353034375A3079311C301A0603
     5504030C13437573746F6D2D4552205265676973747261723114301206035504
     0B0C0B4F6666696365206465707431183016060355040A0C0F437573746F6D2D
     45522C20496E632E310F300D06035504070C064F74746F7761310B3009060355
     04080C024F4E310B30090603550406130243413059301306072A8648CE3D0201
     06082A8648CE3D030107034200042030855BE846910B3ECB15CAF8572D3EB565
     BDC654A15EFAF6EDEBAA8B9E1608C5C910C93A20868FC8504D370F1B26FA9759
     F67983BB78863EDA9ACBEA5124F6A3818A308187300E0603551D0F0101FF0404
     030204F030090603551D1304023000301D0603551D0E04160414C9080B387D8D
     D85B3A59E7EC100B866393A9CA4C301F0603551D2304183016801492EA764040
     4A8FAB4F270BF3BC379D86CD7280F8302A0603551D250101FF0420301E06082B
     0601050507031C06082B0601050507030106082B06010505070302300A06082A
     8648CE3D0403020348003045022100D84A7C692FF9586E82228718F63BC305F0
     AEB8AEEC4278823879812A5D156164022008F23C136913B02CE26309D5994FEB
     7570AFAFED98CDF11211C037F7184DC19D

  C.2.3.  Domain CA Certificate

     The Domain CA certificate is the CA of the owner's domain.  It has
     signed the Registrar (RA) certificate.


























  Richardson, et al.       Expires 31 August 2026                [Page 73]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Certificate:
     Data:
      Version: 3 (0x2)
      Serial Number: 3092288576548618702 (0x2aea0413a42dc1ce)
      Signature Algorithm: ecdsa-with-SHA256
      Issuer: CN = Custom-ER Global CA, OU = IT, O = "Custom-ER, Inc.",
              L = San Jose, ST = CA, C = US
      Validity
        Not Before: Dec  9 12:50:47 2022 GMT
        Not After : Dec  6 12:50:47 2032 GMT
      Subject: CN = Custom-ER Global CA, OU = IT, O = "Custom-ER, Inc.",
              L = San Jose, ST = CA, C = US
      Subject Public Key Info:
        Public Key Algorithm: id-ecPublicKey
          Public-Key: (256 bit)
          pub:
            04:97:b1:ed:96:91:64:93:09:85:bb:b8:ac:9a:2a:
            f9:45:5c:df:ee:a4:b1:1d:e2:e7:9d:06:8b:fa:80:
            39:26:b4:00:52:51:b3:4f:1c:08:15:a4:cb:e0:3f:
            bd:1b:bc:b6:35:f6:43:1a:22:de:78:65:3b:87:b9:
            95:37:ec:e1:6c
          ASN1 OID: prime256v1
          NIST CURVE: P-256
      X509v3 extensions:
        X509v3 Subject Alternative Name:
          email:help@custom-er.example.com
        X509v3 Key Usage: critical
          Digital Signature, Certificate Sign, CRL Sign
        X509v3 Basic Constraints: critical
          CA:TRUE
        X509v3 Subject Key Identifier:
          92:EA:76:40:40:4A:8F:AB:4F:27:0B:F3:BC:37:9D:86:CD:72:80:F8
     Signature Algorithm: ecdsa-with-SHA256
     Signature Value:
      30:44:02:20:66:15:df:c3:70:11:f6:73:78:d8:fd:1c:2a:3f:
      bd:d1:3f:51:f6:b6:6f:2d:7c:e2:7a:13:18:21:bb:70:f0:c0:
      02:20:69:86:d8:d2:28:b2:92:6e:23:9e:19:0b:8f:18:25:c9:
      c1:4c:67:95:ff:a0:b3:24:bd:4d:ac:2e:cb:68:d7:13

     Below is the hexadecimal representation of the binary X.509 DER-
     encoded certificate:










  Richardson, et al.       Expires 31 August 2026                [Page 74]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     30820242308201E9A00302010202082AEA0413A42DC1CE300A06082A8648CE3D
     0403023072311C301A06035504030C13437573746F6D2D455220476C6F62616C
     204341310B3009060355040B0C02495431183016060355040A0C0F437573746F
     6D2D45522C20496E632E3111300F06035504070C0853616E204A6F7365310B30
     0906035504080C024341310B3009060355040613025553301E170D3232313230
     393132353034375A170D3332313230363132353034375A3072311C301A060355
     04030C13437573746F6D2D455220476C6F62616C204341310B3009060355040B
     0C02495431183016060355040A0C0F437573746F6D2D45522C20496E632E3111
     300F06035504070C0853616E204A6F7365310B300906035504080C024341310B
     30090603550406130255533059301306072A8648CE3D020106082A8648CE3D03
     01070342000497B1ED969164930985BBB8AC9A2AF9455CDFEEA4B11DE2E79D06
     8BFA803926B4005251B34F1C0815A4CBE03FBD1BBCB635F6431A22DE78653B87
     B99537ECE16CA369306730250603551D11041E301C811A68656C704063757374
     6F6D2D65722E6578616D706C652E636F6D300E0603551D0F0101FF0404030201
     86300F0603551D130101FF040530030101FF301D0603551D0E0416041492EA76
     40404A8FAB4F270BF3BC379D86CD7280F8300A06082A8648CE3D040302034700
     304402206615DFC37011F67378D8FD1C2A3FBDD13F51F6B66F2D7CE27A131821
     BB70F0C002206986D8D228B2926E239E190B8F1825C9C14C6795FFA0B324BD4D
     AC2ECB68D713

  C.2.4.  MASA Certificate

     The MASA CA certificate is the CA that signed the Pledge's IDevID
     certificate.



























  Richardson, et al.       Expires 31 August 2026                [Page 75]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Certificate:
     Data:
      Version: 3 (0x2)
      Serial Number:
        e3:9c:da:17:e1:38:6a:0a
      Signature Algorithm: ecdsa-with-SHA256
      Issuer: CN = masa.stok.nl, O = vanderstok, L = Helmond,
              C = NL
      Validity
        Not Before: Dec  9 12:50:47 2022 GMT
        Not After : Dec  6 12:50:47 2032 GMT
      Subject: CN = masa.stok.nl, O = vanderstok, L = Helmond,
              C = NL
      Subject Public Key Info:
        Public Key Algorithm: id-ecPublicKey
          Public-Key: (256 bit)
          pub:
            04:92:f4:d5:65:58:97:73:b7:03:58:f3:5c:8f:94:
            7d:94:38:36:16:86:56:00:65:fb:2a:9c:43:d2:15:
            92:a7:ab:c9:aa:f2:01:7b:f1:95:5b:62:2e:aa:d8:
            51:20:f2:49:0e:45:8f:eb:a4:85:3f:5f:b4:90:b1:
            1b:83:fb:03:16
          ASN1 OID: prime256v1
          NIST CURVE: P-256
      X509v3 extensions:
        X509v3 Subject Alternative Name:
          email:info@masa.stok.nl
        X509v3 Key Usage: critical
          Digital Signature, Certificate Sign, CRL Sign
        X509v3 Basic Constraints: critical
          CA:TRUE, pathlen:3
        X509v3 Subject Key Identifier:
          CB:8D:98:CA:74:C5:1B:58:DD:E7:AC:EF:86:9A:94:43:A8:D6:66:A6
     Signature Algorithm: ecdsa-with-SHA256
     Signature Value:
      30:46:02:21:00:94:3f:a5:26:51:68:16:38:5b:78:9a:d8:c3:
      af:8e:49:28:22:60:56:26:43:4a:14:98:3e:e1:e4:81:ad:ca:
      1b:02:21:00:ba:4d:aa:fd:fa:68:42:74:03:2b:a8:41:6b:e2:
      90:0c:9e:7b:b8:c0:9c:f7:0e:3f:b4:36:8a:b3:9c:3e:31:0e

     Below is the hexadecimal representation of the binary X.509 DER-
     encoded certificate:









  Richardson, et al.       Expires 31 August 2026                [Page 76]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     308201F130820196A003020102020900E39CDA17E1386A0A300A06082A8648CE
     3D040302304B3115301306035504030C0C6D6173612E73746F6B2E6E6C311330
     11060355040A0C0A76616E64657273746F6B3110300E06035504070C0748656C
     6D6F6E64310B3009060355040613024E4C301E170D3232313230393132353034
     375A170D3332313230363132353034375A304B3115301306035504030C0C6D61
     73612E73746F6B2E6E6C31133011060355040A0C0A76616E64657273746F6B31
     10300E06035504070C0748656C6D6F6E64310B3009060355040613024E4C3059
     301306072A8648CE3D020106082A8648CE3D0301070342000492F4D565589773
     B70358F35C8F947D9438361686560065FB2A9C43D21592A7ABC9AAF2017BF195
     5B622EAAD85120F2490E458FEBA4853F5FB490B11B83FB0316A3633061301C06
     03551D11041530138111696E666F406D6173612E73746F6B2E6E6C300E060355
     1D0F0101FF04040302018630120603551D130101FF040830060101FF02010330
     1D0603551D0E04160414CB8D98CA74C51B58DDE7ACEF869A9443A8D666A6300A
     06082A8648CE3D0403020349003046022100943FA526516816385B789AD8C3AF
     8E492822605626434A14983EE1E481ADCA1B022100BA4DAAFDFA684274032BA8
     416BE2900C9E7BB8C09CF70E3FB4368AB39C3E310E

  C.3.  COSE-signed Pledge Voucher Request (PVR)

     In this example, the voucher request (PVR) has been signed by the
     Pledge using the IDevID private key of Appendix C.1.1, and has been
     sent to the link-local constrained Join Proxy (JP) over CoAPS to JP's
     join port.  The join port happens to use the default CoAPS UDP port
     5684.

       REQ: POST coaps://[JP-link-local-address]/b/rv
         Content-Format: 836 (application/voucher+cose)
         Payload: <signed_pvr>

     When the Join Proxy receives the DTLS handshake messages from the
     Pledge, it will relay these messages to the Registrar.  The payload
     signed_voucher_request is shown as hexadecimal dump (with lf added)
     below:

     D28443A10126A0587EA11909C5A40102074823BFBBC9C2BCF2130C585B305930
     1306072A8648CE3D020106082A8648CE3D030107034200042030855BE846910B
     3ECB15CAF8572D3EB565BDC654A15EFAF6EDEBAA8B9E1608C5C910C93A20868F
     C8504D370F1B26FA9759F67983BB78863EDA9ACBEA5124F60D6D4A4144413132
     33343536373839584068987DE8B007F4E9416610BBE2D48E1D7EA1032092B8BF
     CE611421950F45B22F17E214820C07E777ADF86175E25D3205568404C25FCEEC
     1B817C7861A6104B3D

     The representation of signed_pvr in CBOR diagnostic format (with lf
     added) is:







  Richardson, et al.       Expires 31 August 2026                [Page 77]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     18([h'A10126', {}, h'A11909C5A40102074823BFBBC9C2BCF2130C585B3059301
     306072A8648CE3D020106082A8648CE3D030107034200042030855BE846910B3ECB1
     5CAF8572D3EB565BDC654A15EFAF6EDEBAA8B9E1608C5C910C93A20868FC8504D370
     F1B26FA9759F67983BB78863EDA9ACBEA5124F60D6D4A41444131323334353637383
     9', h'68987DE8B007F4E9416610BBE2D48E1D7EA1032092B8BFCE611421950F45B2
     2F17E214820C07E777ADF86175E25D3205568404C25FCEEC1B817C7861A6104B3D']
     )

     The COSE payload is the PVR voucher data, encoded as a CBOR byte
     string.  The diagnostic representation of it is shown below:

     {2501: {1: 2, 7: h'23BFBBC9C2BCF213', 12: h'3059301306072A8648CE3D02
     0106082A8648CE3D030107034200042030855BE846910B3ECB15CAF8572D3EB565BD
     C654A15EFAF6EDEBAA8B9E1608C5C910C93A20868FC8504D370F1B26FA9759F67983
     BB78863EDA9ACBEA5124F6', 13: "JADA123456789"}}

     The Pledge uses the 'proximity' (key '1', SID 2502, enum value 2)
     assertion together with an included 'proximity-registrar-pubk'
     attribute (key '12', SID 2513) to inform MASA about its proximity to
     the specific Registrar.

  C.4.  COSE-signed Registrar Voucher Request (RVR)

     In this example the Registrar's voucher request has been signed by
     the JRC (Registrar) using the private key from Appendix C.1.2.
     Contained within this voucher request is the voucher request PVR that
     was made by the Pledge to JRC.  Note that the RVR uses the HTTPS
     protocol (not CoAP) and corresponding long URI path names as defined
     in [RFC8995].  The Content-Type and Accept headers indicate the
     constrained voucher format that is defined in the present document.
     Because the Pledge used this format in the PVR, the JRC must also use
     this format in the RVR.

       REQ: POST https://masa.stok.nl/.well-known/brski/requestvoucher
         Content-Type: application/voucher+cose
         Accept: application/voucher+cose
         Body: <signed_rvr>

     The payload signed_rvr is shown as hexadecimal dump (with lf added):

     D28443A10126A11820825902843082028030820225A003020102020900C3F621
     49B2E30E3E300A06082A8648CE3D0403023072311C301A06035504030C134375
     73746F6D2D455220476C6F62616C204341310B3009060355040B0C0249543118
     3016060355040A0C0F437573746F6D2D45522C20496E632E3111300F06035504
     070C0853616E204A6F7365310B300906035504080C024341310B300906035504
     0613025553301E170D3232313230363131333735395A170D3235313230353131
     333735395A30818D3131302F06035504030C28437573746F6D2D455220436F6D
     6D65726369616C204275696C64696E6773205265676973747261723113301106



  Richardson, et al.       Expires 31 August 2026                [Page 78]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     0355040B0C0A4F6666696365206F707331183016060355040A0C0F437573746F
     6D2D45522C20496E632E310F300D06035504070C064F74746F7761310B300906
     035504080C024F4E310B30090603550406130243413059301306072A8648CE3D
     020106082A8648CE3D030107034200042030855BE846910B3ECB15CAF8572D3E
     B565BDC654A15EFAF6EDEBAA8B9E1608C5C910C93A20868FC8504D370F1B26FA
     9759F67983BB78863EDA9ACBEA5124F6A3818730818430090603551D13040230
     00300B0603551D0F0404030204F0301D0603551D0E04160414C9080B387D8DD8
     5B3A59E7EC100B866393A9CA4C301F0603551D2304183016801492EA7640404A
     8FAB4F270BF3BC379D86CD7280F8302A0603551D250101FF0420301E06082B06
     01050507031C06082B0601050507030106082B06010505070302300A06082A86
     48CE3D040302034900304602210091A2033692EB81503D53505FFC8DA326B1EE
     7DEA96F29174F0B3341A07812201022100FF7339288108B712F418530A18025A
     895408CC45E0BB678B46FBAB37DDB4D36B59024730820243308201E9A0030201
     0202082AEA0413A42DC1CE300A06082A8648CE3D0403023072311C301A060355
     04030C13437573746F6D2D455220476C6F62616C204341310B3009060355040B
     0C02495431183016060355040A0C0F437573746F6D2D45522C20496E632E3111
     300F06035504070C0853616E204A6F7365310B300906035504080C024341310B
     3009060355040613025553301E170D3232313230363131333735395A170D3332
     313230333131333735395A3072311C301A06035504030C13437573746F6D2D45
     5220476C6F62616C204341310B3009060355040B0C0249543118301606035504
     0A0C0F437573746F6D2D45522C20496E632E3111300F06035504070C0853616E
     204A6F7365310B300906035504080C024341310B300906035504061302555330
     59301306072A8648CE3D020106082A8648CE3D0301070342000497B1ED969164
     930985BBB8AC9A2AF9455CDFEEA4B11DE2E79D068BFA803926B4005251B34F1C
     0815A4CBE03FBD1BBCB635F6431A22DE78653B87B99537ECE16CA3693067300F
     0603551D130101FF040530030101FF30250603551D11041E301C811A68656C70
     40637573746F6D2D65722E6578616D706C652E636F6D300E0603551D0F0101FF
     040403020186301D0603551D0E0416041492EA7640404A8FAB4F270BF3BC379D
     86CD7280F8300A06082A8648CE3D0403020348003045022100D6D813B390BD3A
     7B4E85424BCB1ED933AD1E981F2817B59083DD6EC1C5E3FADF02202CEE440619
     2BC767E98D7CFAE044C6807481AD8564A7D569DCA3D1CDF1E5E843590124A119
     09C5A60102027818323032322D31322D30365432303A30343A31352E3735345A
     05581A041830168014CB8D98CA74C51B58DDE7ACEF869A9443A8D666A6074823
     BFBBC9C2BCF2130958C9D28443A10126A0587EA11909C5A40102074823BFBBC9
     C2BCF2130C585B3059301306072A8648CE3D020106082A8648CE3D0301070342
     00042030855BE846910B3ECB15CAF8572D3EB565BDC654A15EFAF6EDEBAA8B9E
     1608C5C910C93A20868FC8504D370F1B26FA9759F67983BB78863EDA9ACBEA51
     24F60D6D4A414441313233343536373839584068987DE8B007F4E9416610BBE2
     D48E1D7EA1032092B8BFCE611421950F45B22F17E214820C07E777ADF86175E2
     5D3205568404C25FCEEC1B817C7861A6104B3D0D6D4A41444131323334353637
     38395840B1DD40B10787437588AEAC9036899191C16CCDBECA31C197855CCB6B
     BA142D709FE329CBC3F76297D6063ACB6759EAB98E96EA4C4AA2135AA48A247B
     AC1D6A3F

     The representation of signed_rvr in CBOR diagnostic format (with lf
     added) is:





  Richardson, et al.       Expires 31 August 2026                [Page 79]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     18([h'A10126', {32: [h'3082028030820225A003020102020900C3F62149B2E30
     E3E300A06082A8648CE3D0403023072311C301A06035504030C13437573746F6D2D4
     55220476C6F62616C204341310B3009060355040B0C02495431183016060355040A0
     C0F437573746F6D2D45522C20496E632E3111300F06035504070C0853616E204A6F7
     365310B300906035504080C024341310B3009060355040613025553301E170D32323
     13230363131333735395A170D3235313230353131333735395A30818D3131302F060
     35504030C28437573746F6D2D455220436F6D6D65726369616C204275696C64696E6
     7732052656769737472617231133011060355040B0C0A4F6666696365206F7073311
     83016060355040A0C0F437573746F6D2D45522C20496E632E310F300D06035504070
     C064F74746F7761310B300906035504080C024F4E310B30090603550406130243413
     059301306072A8648CE3D020106082A8648CE3D030107034200042030855BE846910
     B3ECB15CAF8572D3EB565BDC654A15EFAF6EDEBAA8B9E1608C5C910C93A20868FC85
     04D370F1B26FA9759F67983BB78863EDA9ACBEA5124F6A3818730818430090603551
     D1304023000300B0603551D0F0404030204F0301D0603551D0E04160414C9080B387
     D8DD85B3A59E7EC100B866393A9CA4C301F0603551D2304183016801492EA7640404
     A8FAB4F270BF3BC379D86CD7280F8302A0603551D250101FF0420301E06082B06010
     50507031C06082B0601050507030106082B06010505070302300A06082A8648CE3D0
     40302034900304602210091A2033692EB81503D53505FFC8DA326B1EE7DEA96F2917
     4F0B3341A07812201022100FF7339288108B712F418530A18025A895408CC45E0BB6
     78B46FBAB37DDB4D36B', h'30820243308201E9A00302010202082AEA0413A42DC1
     CE300A06082A8648CE3D0403023072311C301A06035504030C13437573746F6D2D45
     5220476C6F62616C204341310B3009060355040B0C02495431183016060355040A0C
     0F437573746F6D2D45522C20496E632E3111300F06035504070C0853616E204A6F73
     65310B300906035504080C024341310B3009060355040613025553301E170D323231
     3230363131333735395A170D3332313230333131333735395A3072311C301A060355
     04030C13437573746F6D2D455220476C6F62616C204341310B3009060355040B0C02
     495431183016060355040A0C0F437573746F6D2D45522C20496E632E3111300F0603
     5504070C0853616E204A6F7365310B300906035504080C024341310B300906035504
     06130255533059301306072A8648CE3D020106082A8648CE3D0301070342000497B1
     ED969164930985BBB8AC9A2AF9455CDFEEA4B11DE2E79D068BFA803926B4005251B3
     4F1C0815A4CBE03FBD1BBCB635F6431A22DE78653B87B99537ECE16CA3693067300F
     0603551D130101FF040530030101FF30250603551D11041E301C811A68656C704063
     7573746F6D2D65722E6578616D706C652E636F6D300E0603551D0F0101FF04040302
     0186301D0603551D0E0416041492EA7640404A8FAB4F270BF3BC379D86CD7280F830
     0A06082A8648CE3D0403020348003045022100D6D813B390BD3A7B4E85424BCB1ED9
     33AD1E981F2817B59083DD6EC1C5E3FADF02202CEE4406192BC767E98D7CFAE044C6
     807481AD8564A7D569DCA3D1CDF1E5E843']}, h'A11909C5A601020278183230323
     22D31322D30365432303A30343A31352E3735345A05581A041830168014CB8D98CA7
     4C51B58DDE7ACEF869A9443A8D666A6074823BFBBC9C2BCF2130958C9D28443A1012
     6A0587EA11909C5A40102074823BFBBC9C2BCF2130C585B3059301306072A8648CE3
     D020106082A8648CE3D030107034200042030855BE846910B3ECB15CAF8572D3EB56
     5BDC654A15EFAF6EDEBAA8B9E1608C5C910C93A20868FC8504D370F1B26FA9759F67
     983BB78863EDA9ACBEA5124F60D6D4A414441313233343536373839584068987DE8B
     007F4E9416610BBE2D48E1D7EA1032092B8BFCE611421950F45B22F17E214820C07E
     777ADF86175E25D3205568404C25FCEEC1B817C7861A6104B3D0D6D4A41444131323
     3343536373839', h'B1DD40B10787437588AEAC9036899191C16CCDBECA31C19785
     5CCB6BBA142D709FE329CBC3F76297D6063ACB6759EAB98E96EA4C4AA2135AA48A24
     7BAC1D6A3F'])



  Richardson, et al.       Expires 31 August 2026                [Page 80]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  C.5.  COSE-signed Voucher from MASA

     The resulting voucher is created by the MASA and returned to the
     Registrar:

       RES: 200 OK
         Content-Type: application/voucher+cose
         Body: <signed_voucher>

     The Registrar then returns the voucher to the Pledge:

       RES: 2.04 Changed
         Content-Format: 836 (application/voucher+cose)
         Payload: <signed_voucher>

     It is signed by the MASA's private key (see Appendix C.1.3) and can
     be verified by the Pledge using the MASA's public key that it stores.

     Below is the binary signed_voucher, encoded in hexadecimal (with lf
     added):

     D28443A10126A0590288A1190993A60102027818323032322D31322D30365432
     303A32333A33302E3730385A03F4074857EED786AD4049070859024730820243
     308201E9A00302010202082AEA0413A42DC1CE300A06082A8648CE3D04030230
     72311C301A06035504030C13437573746F6D2D455220476C6F62616C20434131
     0B3009060355040B0C02495431183016060355040A0C0F437573746F6D2D4552
     2C20496E632E3111300F06035504070C0853616E204A6F7365310B3009060355
     04080C024341310B3009060355040613025553301E170D323231323036313133
     3735395A170D3332313230333131333735395A3072311C301A06035504030C13
     437573746F6D2D455220476C6F62616C204341310B3009060355040B0C024954
     31183016060355040A0C0F437573746F6D2D45522C20496E632E3111300F0603
     5504070C0853616E204A6F7365310B300906035504080C024341310B30090603
     550406130255533059301306072A8648CE3D020106082A8648CE3D0301070342
     000497B1ED969164930985BBB8AC9A2AF9455CDFEEA4B11DE2E79D068BFA8039
     26B4005251B34F1C0815A4CBE03FBD1BBCB635F6431A22DE78653B87B99537EC
     E16CA3693067300F0603551D130101FF040530030101FF30250603551D11041E
     301C811A68656C7040637573746F6D2D65722E6578616D706C652E636F6D300E
     0603551D0F0101FF040403020186301D0603551D0E0416041492EA7640404A8F
     AB4F270BF3BC379D86CD7280F8300A06082A8648CE3D04030203480030450221
     00D6D813B390BD3A7B4E85424BCB1ED933AD1E981F2817B59083DD6EC1C5E3FA
     DF02202CEE4406192BC767E98D7CFAE044C6807481AD8564A7D569DCA3D1CDF1
     E5E8430B6D4A4144413132333435363738395840DF31B21A6AD3F5AC7F4C8B02
     6F551BD28FBCE62330D3E262AC170F6BFEDDBA5F2E8FBAA2CAACFED9E8614EAC
     5BF2450DADC53AC29DFA30E8787A1400B2E7C832

     The representation of signed_voucher in CBOR diagnostic format (with
     lf added) is:




  Richardson, et al.       Expires 31 August 2026                [Page 81]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     18([h'A10126', {}, h'A1190993A60102027818323032322D31322D30365432303
     A32333A33302E3730385A03F4074857EED786AD4049070859024730820243308201E
     9A00302010202082AEA0413A42DC1CE300A06082A8648CE3D0403023072311C301A0
     6035504030C13437573746F6D2D455220476C6F62616C204341310B3009060355040
     B0C02495431183016060355040A0C0F437573746F6D2D45522C20496E632E3111300
     F06035504070C0853616E204A6F7365310B300906035504080C024341310B3009060
     355040613025553301E170D3232313230363131333735395A170D333231323033313
     1333735395A3072311C301A06035504030C13437573746F6D2D455220476C6F62616
     C204341310B3009060355040B0C02495431183016060355040A0C0F437573746F6D2
     D45522C20496E632E3111300F06035504070C0853616E204A6F7365310B300906035
     504080C024341310B30090603550406130255533059301306072A8648CE3D0201060
     82A8648CE3D0301070342000497B1ED969164930985BBB8AC9A2AF9455CDFEEA4B11
     DE2E79D068BFA803926B4005251B34F1C0815A4CBE03FBD1BBCB635F6431A22DE786
     53B87B99537ECE16CA3693067300F0603551D130101FF040530030101FF302506035
     51D11041E301C811A68656C7040637573746F6D2D65722E6578616D706C652E636F6
     D300E0603551D0F0101FF040403020186301D0603551D0E0416041492EA7640404A8
     FAB4F270BF3BC379D86CD7280F8300A06082A8648CE3D0403020348003045022100D
     6D813B390BD3A7B4E85424BCB1ED933AD1E981F2817B59083DD6EC1C5E3FADF02202
     CEE4406192BC767E98D7CFAE044C6807481AD8564A7D569DCA3D1CDF1E5E8430B6D4
     A414441313233343536373839', h'DF31B21A6AD3F5AC7F4C8B026F551BD28FBCE6
     2330D3E262AC170F6BFEDDBA5F2E8FBAA2CAACFED9E8614EAC5BF2450DADC53AC29D
     FA30E8787A1400B2E7C832'])

     In the above, the third element in the array is the voucher data
     encoded as a CBOR byte string.  When decoded, it can be represented
     by the following CBOR diagnostic notation:

     {2451: {1: 2, 2: "2022-12-06T20:23:30.708Z", 3: false, 7: h'57EED786
     AD404907', 8: h'30820243308201E9A00302010202082AEA0413A42DC1CE300A06
     082A8648CE3D0403023072311C301A06035504030C13437573746F6D2D455220476C
     6F62616C204341310B3009060355040B0C02495431183016060355040A0C0F437573
     746F6D2D45522C20496E632E3111300F06035504070C0853616E204A6F7365310B30
     0906035504080C024341310B3009060355040613025553301E170D32323132303631
     31333735395A170D3332313230333131333735395A3072311C301A06035504030C13
     437573746F6D2D455220476C6F62616C204341310B3009060355040B0C0249543118
     3016060355040A0C0F437573746F6D2D45522C20496E632E3111300F06035504070C
     0853616E204A6F7365310B300906035504080C024341310B30090603550406130255
     533059301306072A8648CE3D020106082A8648CE3D0301070342000497B1ED969164
     930985BBB8AC9A2AF9455CDFEEA4B11DE2E79D068BFA803926B4005251B34F1C0815
     A4CBE03FBD1BBCB635F6431A22DE78653B87B99537ECE16CA3693067300F0603551D
     130101FF040530030101FF30250603551D11041E301C811A68656C7040637573746F
     6D2D65722E6578616D706C652E636F6D300E0603551D0F0101FF040403020186301D
     0603551D0E0416041492EA7640404A8FAB4F270BF3BC379D86CD7280F8300A06082A
     8648CE3D0403020348003045022100D6D813B390BD3A7B4E85424BCB1ED933AD1E98
     1F2817B59083DD6EC1C5E3FADF02202CEE4406192BC767E98D7CFAE044C6807481AD
     8564A7D569DCA3D1CDF1E5E843', 11: "JADA123456789"}}





  Richardson, et al.       Expires 31 August 2026                [Page 82]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     The largest element in the voucher is identified by key 8, which
     decodes to SID 2459 (pinned-domain-cert) based on the delta encoding
     defined by [RFC9254].  It contains the complete PKIX (DER-encoded
     X.509v3) certificate of the Registrar's domain CA.  This certificate
     is shown in Appendix C.2.3.

  Appendix D.  Pledge Device Class Profiles

     cBRSKI allows implementers to select between various functional
     options for the Pledge, yielding different code size footprints and
     different requirements on Pledge hardware.  Thus for each product
     type an optimal trade-off between functionality, development/
     maintenance cost and hardware cost can be made.

     This appendix illustrates different selection outcomes by means of
     defining different example "profiles" of constrained Pledges.  In the
     following subsections, these profiles are defined and a comparison is
     provided.

  D.1.  Minimal Pledge

     The Minimal Pledge profile (Min) aims to reduce code size and
     hardware cost to a minimum.  This comes with some severe functional
     restrictions, in particular:

     *  No support for EST re-enrollment: whenever this would be needed, a
        factory reset followed by a new onboarding process is required.

     *  No support for change of Registrar: for this case, a factory reset
        followed by a new onboarding process is required.

     This profile would be appropriate for single-use devices which must
     be replaced rather than re-deployed.  That might include medical
     devices, but also sensors used during construction, such as concrete
     temperature sensors.

  D.2.  Typical Pledge

     The Typical Pledge profile (Typ) aims to support a typical cBRSKI
     feature set including EST re-enrollment support and Registrar
     changes.










  Richardson, et al.       Expires 31 August 2026                [Page 83]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  D.3.  Full-featured Pledge

     The Full-featured Pledge profile (Full) illustrates a Pledge category
     that supports multiple onboarding methods, hardware real-time clock,
     BRSKI/EST resource discovery, and CSR Attributes request/response.
     It also supports most of the optional features defined in this
     specification.

  D.4.  Comparison Chart of Pledge Classes

     The below table specifies the functions implemented in the three
     example Pledge classes Min (Appendix D.1), Typ (Appendix D.2) and
     Full (Appendix D.3).






































  Richardson, et al.       Expires 31 August 2026                [Page 84]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


      +============================================+=======+=====+======+
      | Functions Implemented                      |  Min  | Typ | Full |
      +============================================+=======+=====+======+
      | *General*                                  |       |     |      |
      +--------------------------------------------+-------+-----+------+
      | Support cBRSKI onboarding                  |   Y   |  Y  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | Support other onboarding method(s)         |   -   |  -  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | Real-time clock and cert time checks       |   -   |  -  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | *cBRSKI*                                   |       |     |      |
      +--------------------------------------------+-------+-----+------+
      | CoAP discovery for rt=brski*               |   -   |  -  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | Support pinned Registrar public key (RPK)  |   Y   |  -  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | Support pinned Registrar certificate       |   -   |  Y  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | Support pinned Domain CA                   |   -   |  Y  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | *EST-coaps*                                |       |     |      |
      +--------------------------------------------+-------+-----+------+
      | Explicit TA database size (#certs)         |   0   |  3  |  8   |
      +--------------------------------------------+-------+-----+------+
      | CoAP discovery for rt=ace.est*             |   -   |  -  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | GET /att and response parsing              |   -   |  -  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | GET /crts format 62 (multiple CA certs)    |   -   |  Y  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | GET /crts format 281 (multiple CA certs)   |   -   |  -  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | ETag handling support for GET /crts        |   -   |  Y  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | Re-enrollment supported                    | - (*) |  Y  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | Section 6.5.1 optimized procedure          |   Y   |  Y  |  -   |
      +--------------------------------------------+-------+-----+------+
      | Pro-active re-enrollment at own initiative |   -   |  -  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | Periodic trust anchor retrieval GET /crts  | - (*) |  Y  |  Y   |
      +--------------------------------------------+-------+-----+------+
      | Supports change of Registrar identity      | - (*) |  Y  |  Y   |
      +--------------------------------------------+-------+-----+------+

         Table 5: Comparison Chart of Pledge Classes Min, Typ and Full




  Richardson, et al.       Expires 31 August 2026                [Page 85]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Notes: (*) means only possible via a factory-reset followed by a new
     cBRSKI onboarding procedure.

  Appendix E.  Pledge Discovery of Onboarding and Enrollment Options

     The discovery functionality described in this section is informative
     only: it derives from the normative CoRE documents [RFC6690],
     [RFC7252] and from [RFC9148].  In typical cases, for a constrained
     Pledge that only supports a single onboarding and enrollment method,
     this functionality is not needed.

     Note that the full-featured Pledge class defined in Appendix D.3 does
     support CoAP discovery functionality.

  E.1.  Pledge Discovery Query for All cBRSKI Resources

     A Pledge that wishes to discover the available cBRSKI onboarding
     options/formats can do a discovery operation using CoAP discovery per
     Section 7 of [RFC7252] and Section 4 of [RFC6690].  It first sends a
     CoAP discovery query to the Registrar over the secured DTLS
     connection.  The Registrar then responds with a CoRE Link Format
     payload containing the requested resources, if any.

     For example, if the Registrar supports a cBRSKI base resource /b in
     addition to the longer /.well-known/brski base resource, and supports
     only the voucher format application/voucher+cose (836), and status
     reporting in both CBOR (60) and JSON (50) formats, a CoAP resource
     discovery request and response may look as follows:

       REQ: GET /.well-known/core?rt=brski*

       RES: 2.05 Content
         Content-Format: 40 (application/link-format)
         Payload:
           </b>;rt=brski,
           </b/rv>;rt=brski.rv;ct=836,
           </b/vs>;rt=brski.vs;ct="50 60",
           </b/es>;rt=brski.es;ct="50 60"

     In this case, the Registrar returns only the shorter URI paths
     matching the query filter, which are located under the /b base
     resource.  The /.well-known/brski based URI paths are not returned,
     as these are assumed to be well-known (i.e. mandatory to support for
     a Registrar that offers this functionality under /b.)







  Richardson, et al.       Expires 31 August 2026                [Page 86]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     The Registrar is however under no obligation to provide the shorter
     URLs under /b, and may respond to this query with only the /.well-
     known/brski/\<short-name\> resources for the short names as defined
     in Table 1, if these resources are not hosted anywhere else.  This
     case is shown in the below interaction:

       REQ: GET /.well-known/core?rt=brski*

       RES: 2.05 Content
         Content-Format: 40 (application/link-format)
         Payload:
           </.well-known/brski>;rt=brski,
           </.well-known/brski/rv>;rt=brski.rv;ct=836,
           </.well-known/brski/vs>;rt=brski.vs;ct="50 60",
           </.well-known/brski/es>;rt=brski.es;ct="50 60"

     When responding to a discovery request for cBRSKI resources, the
     Registrar may return the full resource paths for all <short-name>
     resources and the content-formats supported by these resources (using
     ct attributes) as shown in the above examples.  This is useful when
     multiple content-formats are supported for a particular resource on
     the Registrar and the discovering Pledge also supports multiple.

     Registrars that have implemented any cBRSKI or EST-coaps URI paths
     outside of /.well-known must process a request on the corresponding
     /.well-known/brski/\<short-name\> or /.well-known/est/\<short-name\>
     URI paths identically.  In particular, a Pledge may use the longer
     (well-known) and shorter URI paths in any combination.

     A Registrar may also be implemented without support for the
     (optional) CoAP discovery.  In that case, it may for example return a
     4.04 Not Found as shown in the example below, in case the Registrar
     does not host the resource /.well-known/core at all.  In such case,
     the Pledge cannot discover any onboarding/enrollment options and so
     it has to rely on the default cBRSKI resources under /.well-known/
     brski/... and /.well-known/est/....

       REQ: GET /.well-known/core?rt=brski*

       RES: 4.04 Not Found











  Richardson, et al.       Expires 31 August 2026                [Page 87]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


  E.2.  Pledge Discovery Query for the cBRSKI Base Resource

     In case the client queries for only rt=brski type resources, the
     Registrar responds with only the base path for the cBRSKI resources
     (rt=brski, resource /b in earlier examples) and no others.  (So, the
     query is "rt=brski", without the wildcard character.)  This is shown
     in the below example.  The Pledge in this case requests only the
     cBRSKI base resource of type rt=brski to check if cBRSKI is supported
     by the Registrar and if a shorter-length cBRSKI base resource path is
     supported or not.  In this case, the Pledge is not interested to
     check what voucher request formats, or status telemetry formats --
     other than the mandatory default formats -- are supported.  The
     compact response below then shows that the Registrar indeed supports
     a cBRSKI resource at /b:

       REQ: GET /.well-known/core?rt=brski

       RES: 2.05 Content
         Content-Format: 40 (application/link-format)
         Payload:
           </b>;rt=brski

     The Pledge can now start using any of the cBRSKI resources
     /b/\<short-name\> in a next CoAP request to the Registrar.  In above
     example, again the well-known resource present under /.well-known/
     brski is not returned because this is assumed to be well-known to the
     Pledge and mandatory to support for a Registrar that offers this
     functionality under /b.

     As a follow-up example, the Pledge can now start the onboarding by
     sending its PVR:

       REQ: POST /b/rv
         Content-Format: 836 (application/voucher+cose)
         Accept: 836 (application/voucher+cose)
         Payload: <binary COSE-signed PVR>

  E.3.  Usage of ct Attribute

     The return of multiple content-formats in the 'ct' link format
     attribute by the Registrar allows the Pledge to choose the most
     appropriate one for a particular operation, and allows extension with
     new voucher formats.  Note that only content-format 836 (application/
     voucher+cose) is defined in this document for the voucher request
     resource (/rv), both as request payload and as response payload.  If
     the 'ct' attribute is not indicated for the /rv resource in the CoRE
     Link Format description, this implies that at least format 836 is
     supported and maybe more.



  Richardson, et al.       Expires 31 August 2026                [Page 88]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Note that this specification allows for application/voucher+cose
     payloads to be transmitted over HTTPS, as well as for application/
     voucher-cms+json and other formats yet to be defined over CoAP.  The
     burden for this flexibility is placed upon the Registrar.  A Pledge
     on constrained hardware is expected to support a single format only.

     The Pledge needs to support one or more formats for the PVR and
     resulting voucher.  The MASA needs to support all formats that the
     associated Pledges use.

     In the below example, a Pledge queries specifically for the brski.rv
     resource type to learn what voucher formats are supported:

       REQ: GET /.well-known/core?rt=brski.rv

       RES: 2.05 Content
         Content-Format: 40 (application/link-format)
         Payload:
           </b/rv>;rt=brski.rv;ct="836 65123 65124"

     The Registrar returns 3 supported voucher formats: 836, 65123, and
     65124.  The first is the mandatory application/voucher+cose.  The
     other two are numbers from the Experimental Use number range of the
     CoAP Content-Formats sub-registry, which are used as mere examples.
     The Pledge can now make a selection between the supported formats.

     Note that if the Registrar only supports the default content-formats
     for each cBRSKI resource as specified by this document, it may omit
     the ct attributes in the discovery query response.  For example as in
     the following interaction:

       REQ: GET /.well-known/core?rt=brski*

       RES: 2.05 Content
         Content-Format: 40 (application/link-format)
         Payload:
           </b>;rt=brski,
           </b/rv>;rt=brski.rv,
           </b/vs>;rt=brski.vs,
           </b/es>;rt=brski.es

  E.4.  EST-coaps Resource Discovery

     The Pledge can also use CoAP discovery to identify enrollment
     options, for example enrollment using EST-coaps or other methods.
     The below example shows a Pledge that wants to identify EST-coaps
     enrollment options by sending a discovery query.  This is done either
     before or after the voucher has been validated.



  Richardson, et al.       Expires 31 August 2026                [Page 89]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


       REQ: GET /.well-known/core?rt=ace.est*

       RES: 2.05 Content
         Content-Format: 40 (application/link-format)
         Payload:
           </e/crts>;rt=ace.est.crts;ct="62 281 287",
           </e/sen>;rt=ace.est.sen;ct="281 287",
           </e/sren>;rt=ace.est.sren;ct="281 287",
           </e/att>;rt=ace.est.att,
           </e/skg>;rt=ace.est.skg,
           </e/skc>;rt=ace.est.skc

     The response from the Registrar indicates that EST-coaps enrollment
     (/sen) and re-enrollment (/sren) is supported, with a choice of two
     content-formats for the response payload: either a PKCS#7 container
     with a single LDevID certificate (application/pkcs7-mime;smime-
     type=certs-only, content-format 281) which is the BRSKI [RFC8995]
     encoding, or just a single LDevID certificate (application/pkix-cert,
     content-format 287) which is the default cBRSKI encoding.

     For the EST cacerts resource (/crts) there are three content-formats
     supported: an application/multipart-core container (62) per
     Section 6.5.5, a PKCS#7 container with all CA certificates (287), or
     a single (most relevant) CA certificate (281).

     The Pledge can now send a CoAP request to one of the discovered
     resources, with the Accept Option to indicate which return payload
     content-format the Pledge wants to receive.

  Acknowledgements

     We are very grateful to Jim Schaad for explaining COSE/CMS choices
     and for correcting early versions of the COSE_Sign1 objects.

     Michel Veillette did extensive work on _pyang_ to extend it to
     support the SID allocation process, and this document was among its
     first users.

     Russ Housley , Daniel Franke , Henk Birkholtz , Kathleen Moriarty ,
     Xufeng Liu and Karl Moberg provided review feedback.

     The BRSKI design team has met on many Tuesdays and Thursdays for
     document review.  The team includes the authors and: Aurelio
     Schellenbaum , David von Oheimb , Steffen Fries , Thomas Werner ,
     Bill Atwood and Toerless Eckert .

     Darrel Miller , Orie Steele and Manu Sporny provided review feedback
     on the registration of the +cose structured syntax suffix.



  Richardson, et al.       Expires 31 August 2026                [Page 90]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     Carsten Bormann suggested the use of CBOR Web Token (CWT) claims in
     the voucher's COSE header.

  Changelog

     -30: Require Pledge's DTLS cert chain to be included in RVR 'x5bag'
     (#343).  Add support for CoAP Uri-Path-Abbrev Option (#336).  Move
     'idevid-issuer' clarification text to draft-8366bis.  Update the
     duplicate serial number attack to focus only on the case where the
     attack could be successful (equal CAs).  Update section references
     draft-ietf-anima-8366bis to latest version.  Remove reference to the
     to-be-deprecated RFC 8366.  Align terms and notation with draft-ietf-
     anima-8366bis.  Editorial (wording) updates.

     -29: Clarify that each brski.jp link indicates a root resource (/)
     (#335).  Clarify that Pledge uses IP link-local address of JP's
     discovery response, instead of the UTF-8 encoded IP address literal
     (#334).  Add example of Join Proxy offering multiple Registrars
     (endpoints) (#333).  Updated CoAP request/response formatting of
     examples.  Updated acknowledgements (#331).  Editorial updates.

     -28: Cleanup of normative/informative references, setting each to
     right category.  Bugfix and clarification in text around EdDSA Curve
     selection.  Added section on additional information in COSE header
     with 'iat' CWT timestamp example.  Updates to BRSKI Well-Known URIs
     registry, including a rename of the "URI" column (#326).  Unify COSE
     header parameters terminology (#330).  Text formatting and editorial
     updates.

     -27: Clarify x5bag for storing signing chain and Registrar removes
     unprotected x5bag/x5chain (#324, #323, #230).  Clarify RPK use with
     "placeholder" certificate.  Merged the very similar BRSKI-MASA
     security considerations sections (#312).  Require CBOR format for
     Pledge's/EST-client's telemetry (#309, #317).  Removed figure
     captions from code examples for consistency (#315).  Add base
     resource type (rt) for "ace.est" and related terminology (#314).
     Update IEEE 802.1AR reference to 2018 version (#313).  Editorial
     updates.

     -26: Updated I-D/RFC references to newer versions.  Corrected "sub-
     registry" term to official "registry", in IANA section.  Explicitly
     imported terminology from [RFC7252].  Corrected "router" term in
     Thread/MLE section, with clarifications, and [Thread] reference fix.
     Moved references between "Informative" and "Normative" based on
     what's required to implement all the optional features.  Removal of
     some lingering legacy text.  Editorial improvements, bugfixes and
     typo corrections.




  Richardson, et al.       Expires 31 August 2026                [Page 91]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     -25: Moved all software/library support info into Appendix A and
     added "open source" section; Removed use of formal Extends/Amends
     Update-tags (#303, #304); Moved Section 14 to Appendix E (#302);
     Editorial improvements.

     -24: Rephrased well-known URL requirement in 14.1 (#292, #293); Added
     paragraph on future certificate formats like C509 (#281, #294); Add
     formal specification for CoAP discovery of Join Proxy by Pledge,
     instead of only showing examples (#296, #300); Enable mDNS discovery
     of Join Proxy by Pledge (also in mesh networks) and list service name
     to use (#297, #299); Add requirement to support content-format 287 in
     /sen and /sren response (#295, #298).

     -23: Removed Update tag for RFC 8366 (#285, #288); Introduced cBRSKI
     acronym (#284, #286); Added Update tag for RFC 9148 (#283, #289);
     Keep CoAP discovery as only mechanism and refer to future discovery
     work (#279, #282, #290); Introduce formal CBOR diagnostics ellipsis
     elision syntax (#281, #287); Support for multi-tier CAs by
     introducing multipart-core /crts format (#275, #291); Terminology
     updated for consistency with RFC 8366-bis (#274, #280); Rename
     voucher media type to application/voucher+cose and register +cose SSS
     (#264, #277); Editorial changes including section restructuring.

     -22: Streamlined text to focus mostly on the default flow, with
     optional functions moved to their own sections (#269, #273); For DTLS
     1.3 client, use the record_size_limit extensions RFC 8449 (#270);
     Editorial updates; Reference rfc6125bis updated to RFC 9525.

     -11 to -21: (For change details see GitHub issues https://github.com/
     anima-wg/constrained-voucher/issues , related Pull Requests and
     commits.)

     -10: Design considerations extended; Examples made consistent.

     -08: Examples for cose_sign1 are completed and improved.

     -06: New SID values assigned; regenerated examples.

     -04: voucher and request-voucher MUST be signed; examples for signed
     request are added in appendix; IANA SID registration is updated; SID
     values in examples are aligned; signed cms examples aligned with new
     SIDs.

     -03: Examples are inverted.







  Richardson, et al.       Expires 31 August 2026                [Page 92]


  Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026


     -02: Example of requestvoucher with unsigned application/cbor is
     added; attributes of voucher "refined" to optional; CBOR
     serialization of vouchers improved; Discovery port numbers are
     specified.

     -01: application/json is optional, application/cbor is compulsory;
     Cms and cose mediatypes are introduced.

     -00: Initial version.

  Authors' Addresses

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


     Peter van der Stok
     vanderstok consultancy
     Email: stokcons@kpnmail.nl


     Panos Kampanakis
     Cisco Systems
     Email: pkampana@cisco.com


     Esko Dijk
     IoTconsultancy.nl
     Email: esko.dijk@iotconsultancy.nl





















  Richardson, et al.       Expires 31 August 2026                [Page 93]


