# drafts

name: draft-ietf-lamps-rfc5274bis
rev: 11
title: Certificate Management Messages over CMS (CMC): Compliance Requirements
time: 2026-02-26T15:08:57Z
group_uri: /api/v1/group/group/2164/
expires: 2026-08-30T15:08:57Z
ad: /api/v1/person/person/123703/
shepherd: /api/v1/person/email/housley@vigilsec.com/
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014852+00:00
abstract:
This document provides a set of compliance statements about the CMC
   (Certificate Management over CMS) enrollment protocol.  The ASN.1
   structures and the transport mechanisms for the CMC enrollment
   protocol are covered in other documents.  This document provides the
   information needed to make a compliant version of CMC.

   This document obsoletes RFC 5274 and RFC 6402.

states:
["/api/v1/doc/state/1/", "/api/v1/doc/state/110/", "/api/v1/doc/state/113/", "/api/v1/doc/state/17/", "/api/v1/doc/state/117/", "/api/v1/doc/state/44/"]

full_text:
LAMPS Working Group                                        J. Mandel, Ed
Internet-Draft                                              AKAYLA, Inc.
Obsoletes: 5274, 6402 (if approved)                        S. Turner, Ed
Intended status: Standards Track                                   sn3rd
Expires: 30 August 2026                                 26 February 2026


Certificate Management Messages over CMS (CMC): Compliance Requirements
                     draft-ietf-lamps-rfc5274bis-11

Abstract

   This document provides a set of compliance statements about the CMC
   (Certificate Management over CMS) enrollment protocol.  The ASN.1
   structures and the transport mechanisms for the CMC enrollment
   protocol are covered in other documents.  This document provides the
   information needed to make a compliant version of CMC.

   This document obsoletes RFC 5274 and RFC 6402.

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

   Discussion of this document takes place on the WG LAMPS 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/TBD.

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







Mandel, Ed & Turner, Ed  Expires 30 August 2026                 [Page 1]

Internet-Draft               CMC: Compliance               February 2026


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

   This Internet-Draft will expire on 30 August 2026.

Copyright Notice

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

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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Requirements Terminology  . . . . . . . . . . . . . . . . . .   5
   4.  Changes since RFC 5274 and 6402 . . . . . . . . . . . . . . .   5
   5.  Requirements for All Entities . . . . . . . . . . . . . . . .   5
     5.1.  Cryptographic Algorithm Requirements  . . . . . . . . . .   6
     5.2.  Controls  . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.3.  CRMF Feature Requirements . . . . . . . . . . . . . . . .   9
   6.  Requirements for Clients  . . . . . . . . . . . . . . . . . .  10
   7.  Requirements for Servers  . . . . . . . . . . . . . . . . . .  10
   8.  Requirements for EEs  . . . . . . . . . . . . . . . . . . . .  10
   9.  Requirements for RAs  . . . . . . . . . . . . . . . . . . . .  10
   10. Requirements for CAs  . . . . . . . . . . . . . . . . . . . .  10



Mandel, Ed & Turner, Ed  Expires 30 August 2026                 [Page 2]

Internet-Draft               CMC: Compliance               February 2026


   11. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     13.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The CMC (Certificate Management over CMS) protocol is designed in
   terms of a client/server relationship.  In the simplest case, the
   client is the requestor of the certificate (i.e., the End-Entity
   (EE)) and the server is the issuer of the certificate (i.e., the
   Certification Authority (CA)).  The introduction of a Registration
   Authority (RA) into the set of agents complicates the picture only
   slightly.  The RA becomes the server with respect to the certificate
   requestor, and it becomes the client with respect to the certificate
   issuer.  Any number of RAs can be inserted into the picture in this
   manner.

   The RAs may serve specialized purposes that are not currently covered
   by this document.  One such purpose would be a Key Escrow agent.  As
   such, all certificate requests for encryption keys would be directed
   through this RA and it would take appropriate action to do the key
   archival.  Key recovery requests could be defined in the CMC
   methodology allowing for the Key Escrow agent to perform that
   operation acting as the final server in the chain of agents.

   If there are multiple RAs in the system, it is considered normal that
   not all RAs will see all certificate requests.  The routing between
   the RAs may be dependent on the content of the certificate requests
   involved.

   This document is divided into six sections, each section specifying
   the requirements that are specific to a class of agents in the CMC
   model.  These are 1) all Entities, 2) all Servers, 3) all Clients, 4)
   all End-Entities, 5) all Registration Authorities, 6) all
   Certification Authorities.

   This document obsoletes RFC 5274 [CMC-COMPv1] and RFC 6402
   [CMC-Updates].








Mandel, Ed & Turner, Ed  Expires 30 August 2026                 [Page 3]

Internet-Draft               CMC: Compliance               February 2026


2.  Terminology

   There are several different terms, abbreviations, and acronyms used
   in this document that we define here for convenience and consistency
   of usage:

   End-Entity (EE):  Refers to the entity that owns a key pair and for
      whom a certificate is issued.

   Registration Authority (RA) or Local RA (LRA):  Refers to an entity
      that acts as an intermediary between the EE and the CA.  Multiple
      RAs can exist between the End-Entity and the Certification
      Authority.  RAs may perform additional services such as key
      generation or key archival.  This document uses the term RA for
      both RA and LRA.

   Certification Authority (CA):  Refers to the entity that issues
      certificates.

   Client:  Refers to an entity that creates a PKI Request.  In this
      document, both RAs and EEs can be clients.

   Server:  Refers to the entities that process PKI Requests and create
      PKI Responses.  In this document both CAs and RAs can be servers.

   PKCS #10:  Refers to the Public Key Cryptography Standard #10
      [PKCS10], which defines a certification request syntax.

   CRMF:  Refers to the Certificate Request Message Format RFC [CRMF].
      CMC uses this certification request syntax defined in this
      document as part of the protocol.

   CMS:  Refers to the Cryptographic Message Syntax RFC [CMS].  This
      document provides for basic cryptographic services including
      encryption and signing with and without key management.

   PKI Request/Response:  Refers to the requests/responses described in
      this document.  PKI Requests include certification requests,
      revocation requests, etc.  PKI Responses include certs-only
      messages, failure messages, etc.

   Proof-of-Identity:  Refers to the client proving they are who they
      say that they are to the server.

   Proof-of-Possession (POP):  Refers to a value that can be used to
      prove that the private key corresponding to a public key is in the
      possession and can be used by an End-Entity.




Mandel, Ed & Turner, Ed  Expires 30 August 2026                 [Page 4]

Internet-Draft               CMC: Compliance               February 2026


   Transport wrapper:  Refers to the outermost CMS wrapping layer.

   Entity:  Refers to EE, RA (or LRA), or CA.

3.  Requirements 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.

4.  Changes since RFC 5274 and 6402

   Merged [CMC-Updates] text.

   Added RA Identity Proof Witness and Response Body Controls to CMC
   Controls Attribute table.

   Updated the Cryptographic Algorithm Requirements, and added section
   to maintain backwards compatability.

      Replaced SHA-1 for SHA-256

      Replaced HMAC-SHA-1 for HMAC-SHA-256

   Updated the Introduction section, changed "all agents" to "all
   entities" in the overview to maintain consistency throughout the
   document, and re-numbered the section headers.

5.  Requirements for All Entities

   All [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be
   adhered to unless specifically stated otherwise in this document.

   All entities MUST support Full PKI Requests, Simple PKI Responses,
   and Full PKI Responses.  Servers SHOULD support Simple PKI Requests.

   All entities MUST support the use of the CRMF syntax for
   certification requests.  Support for the PKCS #10 syntax for
   certification requests SHOULD be implemented by servers.

   The extendedFailInfo field SHOULD NOT be populated in the
   CMCStatusInfoV2 object; the failInfo field SHOULD be used to relay
   this information.  If the extendedFailInfo field is used, it is
   suggested that an additional CMCStatusInfoV2 item exist for the same
   body part with a failInfo field.




Mandel, Ed & Turner, Ed  Expires 30 August 2026                 [Page 5]

Internet-Draft               CMC: Compliance               February 2026


   All entities MUST implement the HTTP transport mechanism as defined
   in [CMC-TRANS].  Other transport mechanisms MAY be implemented.

5.1.  Cryptographic Algorithm Requirements

   All entities MUST verify RSA-SHA256 signatures in SignedData; (see
   [CMS-ALG2]).  Entities MAY verify other signature algorithms.

   All entities MUST generate RSA-SHA256 signatures for SignedData; (see
   [CMS-ALG2]).  Other signatures algorithms MAY be used for generation.

   All entities MUST support Advanced Encryption Standard (AES) as the
   content encryption algorithm for EnvelopedData; (see [CMS-AES]).
   Other content encryption algorithms MAY be implemented.

   All entities MUST support AES-Galois/Counter Mode (GCM) as the
   authenticated content encryption algorithm for AuthEnvelopedData;
   (see [CMS-AES-AE]).  They MUST also support a 12 octet nonce size and
   a 12 octet integrity check value (ICV) length.  Other content
   encryption algorithms MAY be implemented.

   All entities MUST support RSA as a key transport algorithm for
   EnvelopedData and AuthEnvelopedData; (see [CMS-ALG2]).  Other key
   transport algorithms MAY be implemented.

   If an entity supports key agreement for EnvelopedData or
   AuthEnvelopedData, it MUST support Diffie-Hellman; (see [CMS-DH]).

   If an entity supports PasswordRecipientInfo for EnvelopedData,
   AuthenticatedData, or AuthEnvelopedData it MUST support PBKDF2
   [PBKDF2] for key derivation algorithms.  It MUST support AES key wrap
   (see [AES-WRAP]) as the key encryption algorithm.

   If AuthenticatedData is supported, PasswordRecipientInfo MUST be
   supported.

   Algorithm requirements for the Identity Proof Version 2 control
   (Section 6.2.1 of [CMC-STRUCT]) are: SHA-256 MUST be implemented for
   hashAlgId.  HMAC-SHA256 MUST be implemented for macAlgId.

   Algorithm requirements for the Pop Link Witness Version 2 control
   (Section 6.3.1 of [CMC-STRUCT]) are: SHA-256 MUST be implemented for
   keyGenAlgorithm.  PBKDF2 [PBKDF2] MAY be implemented for
   keyGenAlgorithm.  HMAC-SHA256 MUST be implemented for macAlgorithm.







Mandel, Ed & Turner, Ed  Expires 30 August 2026                 [Page 6]

Internet-Draft               CMC: Compliance               February 2026


   Algorithm requirements for the Encrypted POP and Decrypted POP
   controls (Section 6.7 of [CMC-STRUCT]) are: SHA-256 MUST be
   implemented for witnessAlgID.  HMAC-SHA256 MUST be implemented for
   thePOPAlgID.

   Algorithm requirements for Publish Trust Anchors control
   (Section 6.15 of [CMC-STRUCT]) are: SHA-256 MUST be implemented for
   hashAlgorithm.

   If an EE generates DH keys for certification, it MUST support
   Section 4 of [DH-POP].  EEs MAY support Section 3 of [DH-POP].  CAs
   and RAs that do POP verification MUST support Section 4 of [DH-POP]
   and SHOULD support Section 3 of [DH-POP].

   EEs that need to use a signature algorithm for keys that cannot
   produce a signature MUST support Appendix C of [CMC-STRUCT] and MUST
   support the Encrypted/Decrypted POP controls.  CAs and RAs that do
   POP verification MUST support this signature algorithm and MUST
   support the Encrypted/Decrypted POP controls.

   For backwards compatibility with the previous version of CMC, servers
   MAY offer the algorithms specified therein, but SHOULD use the CMC
   requests to identify which certificates should be transitioned to
   more secure algorithms, if possible.

5.2.  Controls

   The following table lists the name and level of support required for
   each control.

      +============================+==========+==========+==========+
      | Control                    | EE       | RA       | CA       |
      +============================+==========+==========+==========+
      | Extended CMC Status Info   | MUST     | MUST     | MUST     |
      +----------------------------+----------+----------+----------+
      | CMC Status Info            | SHOULD   | SHOULD   | SHOULD   |
      +----------------------------+----------+----------+----------+
      | Identity Proof Version 2   | MUST     | MUST     | MUST     |
      +----------------------------+----------+----------+----------+
      | Identity Proof             | SHOULD   | SHOULD   | SHOULD   |
      +----------------------------+----------+----------+----------+
      | Identification             | MUST     | MUST     | MUST     |
      +----------------------------+----------+----------+----------+
      | POP Link Random            | MUST     | MUST     | MUST     |
      +----------------------------+----------+----------+----------+
      | POP Link Witness Version 2 | MUST     | MUST     | MUST     |
      +----------------------------+----------+----------+----------+
      | POP Link Witness           | SHOULD   | MUST     | MUST     |



Mandel, Ed & Turner, Ed  Expires 30 August 2026                 [Page 7]

Internet-Draft               CMC: Compliance               February 2026


      +----------------------------+----------+----------+----------+
      | Data Return                | MUST     | MUST     | MUST     |
      +----------------------------+----------+----------+----------+
      | Modify Cert Request        | N/A      | MUST     | (2)      |
      +----------------------------+----------+----------+----------+
      | Add Extensions             | N/A      | MAY      | (1)      |
      +----------------------------+----------+----------+----------+
      | Transaction ID             | MUST     | MUST     | MUST     |
      +----------------------------+----------+----------+----------+
      | Sender Nonce               | MUST     | MUST     | MUST     |
      +----------------------------+----------+----------+----------+
      | Recipient Nonce            | MUST     | MUST     | MUST     |
      +----------------------------+----------+----------+----------+
      | Encrypted POP              | (4)      | (5)      | SHOULD   |
      +----------------------------+----------+----------+----------+
      | Decrypted POP              | (4)      | (5)      | SHOULD   |
      +----------------------------+----------+----------+----------+
      | RA POP Witness             | N/A      | SHOULD   | (1)      |
      +----------------------------+----------+----------+----------+
      | Get Certificate            | optional | optional | optional |
      +----------------------------+----------+----------+----------+
      | Get CRL                    | optional | optional | optional |
      +----------------------------+----------+----------+----------+
      | Revocation Request         | SHOULD   | SHOULD   | MUST     |
      +----------------------------+----------+----------+----------+
      | Registration Info          | SHOULD   | SHOULD   | SHOULD   |
      +----------------------------+----------+----------+----------+
      | Response Information       | SHOULD   | SHOULD   | SHOULD   |
      +----------------------------+----------+----------+----------+
      | Query Pending              | MUST     | MUST     | MUST     |
      +----------------------------+----------+----------+----------+
      | Confirm Cert.  Acceptance  | MUST     | MUST     | MUST     |
      +----------------------------+----------+----------+----------+
      | Publish Trust Anchors      | (3)      | (3)      | (3)      |
      +----------------------------+----------+----------+----------+
      | Authenticate Data          | (3)      | (3)      | (3)      |
      +----------------------------+----------+----------+----------+
      | Batch Request              | N/A      | MUST     | (2)      |
      +----------------------------+----------+----------+----------+
      | Batch Responses            | N/A      | MUST     | (2)      |
      +----------------------------+----------+----------+----------+
      | Publication Information    | optional | optional | optional |
      +----------------------------+----------+----------+----------+
      | Control Processed          | N/A      | MUST     | (2)      |
      +----------------------------+----------+----------+----------+
      | RA Identity Proof Witness  | N/A      | MUST     | (2)      |
      +----------------------------+----------+----------+----------+
      | Response Body              | (6)      | (6)      | N/A.     |



Mandel, Ed & Turner, Ed  Expires 30 August 2026                 [Page 8]

Internet-Draft               CMC: Compliance               February 2026


      +----------------------------+----------+----------+----------+

                      Table 1: CMC Control Attributes

   Notes:

   1.  CAs SHOULD implement this control if designed to work with RAs.

   2.  CAs MUST implement this control if designed to work with RAs.

   3.  Implementation is optional for these controls.  We strongly
       suggest that they be implemented in order to populate client
       trust anchors.

   4.  EEs only need to implement this if (a) they support key agreement
       algorithms or (b) they need to operate in environments where the
       hardware keys cannot provide POP.

   5.  RAs SHOULD implement this if they implement RA POP Witness.

   6.  EE's SHOULD implement if designed to work with RAs and MUST
       implement if intended to be used in environments where RAs are
       used for identity validation or key generation.  RAs SHOULD
       implement and validate responses for consistency.

   Strong consideration should be given to implementing the Authenticate
   Data and Publish Trust Anchors controls as this gives a simple method
   for distributing trust anchors into clients without user
   intervention.

5.3.  CRMF Feature Requirements

   The following additional restrictions are placed on CRMF features:

   The registration control tokens id-regCtrl-regToken and id-regCtrl-
   authToken MUST NOT be used.  No specific CMC feature is used to
   replace these items, but generally the CMC controls identification
   and identityProof will perform the same service and are more
   specifically defined.

   The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be
   supported.  An alternative method is under development to provide
   this functionality.








Mandel, Ed & Turner, Ed  Expires 30 August 2026                 [Page 9]

Internet-Draft               CMC: Compliance               February 2026


   The behavior of id-regCtrl-oldCertID is not presently used.  It is
   replaced by issuing the new certificate and using the id-cmc-
   publishCert to remove the old certificate from publication.  This
   operation would not normally be accompanied by an immediate
   revocation of the old certificate; however, that can be accomplished
   by the id-cmc-revokeRequest control.

   The id-regCtrl-protocolEncrKey is not used.

6.  Requirements for Clients

   There are no additional requirements.

7.  Requirements for Servers

   There are no additional requirements.

8.  Requirements for EEs

   If an End-Entity implements Diffie-Hellman, it MUST implement either
   the DH-POP Proof-of-Possession as defined in Section 4 of [DH-POP] or
   the challenge-response POP controls id-cmc-encryptedPOP and id-cmc-
   decryptedPOP.

9.  Requirements for RAs

   RAs SHOULD be able to do delegated POP.  RAs implementing this
   feature MUST implement the id-cmc-lraPOPWitness control.

   All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as
   covered in Section 3.2.3 of [CMC-STRUCT].

10.  Requirements for CAs

   Providing for CAs to work in an environment with RAs is strongly
   suggested.  Implementation of such support is strongly suggested as
   this permits the delegation of substantial administrative interaction
   onto an RA rather than at the CA.

   CAs MUST perform at least minimal checks on all public keys before
   issuing a certificate.  At a minimum, a check for syntax would occur
   with the POP operation.  Additionally, CAs SHOULD perform simple
   checks for known bad keys such as small subgroups for DSA-SHA1 and DH
   keys [SMALL-SUB-GROUP] or known bad exponents for RSA keys.







Mandel, Ed & Turner, Ed  Expires 30 August 2026                [Page 10]

Internet-Draft               CMC: Compliance               February 2026


   CAs MUST enforce POP checking before issuing any certificate.  CAs
   MAY delegate the POP operation to an RA for those cases where 1) a
   challenge/response message pair must be used, 2) an RA performs
   escrow of a key and checks for POP in that manner, or 3) an unusual
   algorithm is used and that validation is done at the RA.

   CAs SHOULD implement both the DH-POP Proof-of-Possession as defined
   in Section 4 of [DH-POP] and the challenge-response POP controls id-
   cmc-encryptedPOP and id-cmc-decryptedPOP.

11.  Security Considerations

   This document uses [CMC-STRUCT] and [CMC-TRANS] as building blocks to
   this document.  The security sections of those two documents are
   included by reference.

   Knowledge of how an entity is expected to operate is vital in
   determining which sections of requirements are applicable to that
   entity.  Care needs to be taken in determining which sections apply
   and fully implementing the necessary code.

   Cryptographic algorithms have and will be broken or weakened.
   Implementers and users need to check that the cryptographic
   algorithms listed in this document make sense from a security level.
   The IETF from time to time may issue documents dealing with the
   current state of the art.  Two examples of such documents are
   [SMALL-SUB-GROUP] and [HASH-ATTACKS].

12.  IANA Considerations

   This document does not require action from IANA.

13.  References

13.1.  Normative References

   [AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption Standard
              (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
              September 2002, <https://www.rfc-editor.org/rfc/rfc3394>.

   [CMC-STRUCT]
              Mandel, J. and S. Turner, "Certificate Management over CMS
              (CMC)", Work in Progress, Internet-Draft, draft-ietf-
              lamps-rfc5272bis-10, 6 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              rfc5272bis-10>.





Mandel, Ed & Turner, Ed  Expires 30 August 2026                [Page 11]

Internet-Draft               CMC: Compliance               February 2026


   [CMC-TRANS]
              Mandel, J. and S. Turner, "Certificate Management over CMS
              (CMC): Transport Protocols", Work in Progress, Internet-
              Draft, draft-ietf-lamps-rfc5273bis-10, 6 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              rfc5273bis-10>.

   [CMS]      Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/rfc/rfc5652>.

   [CMS-AES]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
              Encryption Algorithm in Cryptographic Message Syntax
              (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
              <https://www.rfc-editor.org/rfc/rfc3565>.

   [CMS-AES-AE]
              Housley, R., "Using AES-CCM and AES-GCM Authenticated
              Encryption in the Cryptographic Message Syntax (CMS)",
              RFC 5084, DOI 10.17487/RFC5084, November 2007,
              <https://www.rfc-editor.org/rfc/rfc5084>.

   [CMS-ALG2] Turner, S., "Using SHA2 Algorithms with Cryptographic
              Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
              2010, <https://www.rfc-editor.org/rfc/rfc5754>.

   [CMS-DH]   Rescorla, E., "Diffie-Hellman Key Agreement Method",
              RFC 2631, DOI 10.17487/RFC2631, June 1999,
              <https://www.rfc-editor.org/rfc/rfc2631>.

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

   [DH-POP]   Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
              of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
              May 2013, <https://www.rfc-editor.org/rfc/rfc6955>.

   [PBKDF2]   Kario, A., "Use of Password-Based Message Authentication
              Code 1 (PBMAC1) in PKCS #12 Syntax", RFC 9879,
              DOI 10.17487/RFC9879, September 2025,
              <https://www.rfc-editor.org/rfc/rfc9879>.

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



Mandel, Ed & Turner, Ed  Expires 30 August 2026                [Page 12]

Internet-Draft               CMC: Compliance               February 2026


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

13.2.  Informative References

   [CMC-COMPv1]
              Schaad, J. and M. Myers, "Certificate Management Messages
              over CMS (CMC): Compliance Requirements", RFC 5274,
              DOI 10.17487/RFC5274, June 2008,
              <https://www.rfc-editor.org/rfc/rfc5274>.

   [CMC-Updates]
              Schaad, J., "Certificate Management over CMS (CMC)
              Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
              <https://www.rfc-editor.org/rfc/rfc6402>.

   [HASH-ATTACKS]
              Hoffman, P. and B. Schneier, "Attacks on Cryptographic
              Hashes in Internet Protocols", RFC 4270,
              DOI 10.17487/RFC4270, November 2005,
              <https://www.rfc-editor.org/rfc/rfc4270>.

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

   [SMALL-SUB-GROUP]
              Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
              Attacks on the Diffie-Hellman Key Agreement Method for S/
              MIME", RFC 2785, DOI 10.17487/RFC2785, March 2000,
              <https://www.rfc-editor.org/rfc/rfc2785>.

Acknowledgements

   Obviously, the authors of this version of the document would like to
   thank Jim Schaad and Michael Myers for their work on the previous
   version of this document.

   Thank you to Mike Bishop, Mohamed Boucadair, and Erik Kline for
   reviewing the document and providing comments.

   The acknowledgment from the previous version of this document
   follows:






Mandel, Ed & Turner, Ed  Expires 30 August 2026                [Page 13]

Internet-Draft               CMC: Compliance               February 2026


   The authors and the PKIX Working Group are grateful for the
   participation of Xiaoyi Liu and Jeff Weinstein in helping to author
   the original versions of this document.

   The authors would like to thank Brian LaMacchia for his work in
   developing and writing up many of the concepts presented in this
   document.  The authors would also like to thank Alex Deacon and Barb
   Fox for their contributions.

Contributors

   Jim Schaad
   August Cellars


   Michael Myers
   TraceRoute Security, Inc.


Authors' Addresses

   Joseph Mandel
   AKAYLA, Inc.
   Email: joe@akayla.com


   Sean Turner
   sn3rd
   Email: sean@sn3rd.com






















Mandel, Ed & Turner, Ed  Expires 30 August 2026                [Page 14]


name: draft-ietf-sshm-mlkem-hybrid-kex
rev: 10
title: PQ/T Hybrid Key Exchange with ML-KEM in SSH
time: 2026-02-26T19:46:29Z
group_uri: /api/v1/group/group/2430/
expires: 2026-08-30T18:19:56Z
ad: /api/v1/person/person/123703/
shepherd: /api/v1/person/email/stephen.farrell@cs.tcd.ie/
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014857+00:00
abstract:
This document defines Post-Quantum Traditional (PQ/T) Hybrid key
   exchange methods based on the quantum-resistant Module-Lattice-Based
   Key-Encapsulation Mechanism (ML-KEM) standard and traditional
   Elliptic-curve Diffie–Hellman (ECDH) key exchange schemes.  These
   methods are defined for use in the SSH Transport Layer Protocol.

states:
["/api/v1/doc/state/1/", "/api/v1/doc/state/103/", "/api/v1/doc/state/154/", "/api/v1/doc/state/115/", "/api/v1/doc/state/17/", "/api/v1/doc/state/117/", "/api/v1/doc/state/44/"]

full_text:
SSHM                                                       P. Kampanakis
Internet-Draft                                                       AWS
Intended status: Informational                                D. Stebila
Expires: 30 August 2026                           University of Waterloo
                                                               T. Hansen
                                                                     AWS
                                                        26 February 2026


              PQ/T Hybrid Key Exchange with ML-KEM in SSH
                  draft-ietf-sshm-mlkem-hybrid-kex-10

Abstract

   This document defines Post-Quantum Traditional (PQ/T) Hybrid key
   exchange methods based on the quantum-resistant Module-Lattice-Based
   Key-Encapsulation Mechanism (ML-KEM) standard and traditional
   Elliptic-curve Diffie–Hellman (ECDH) key exchange schemes.  These
   methods are defined for use in the SSH Transport Layer Protocol.

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 30 August 2026.

Copyright Notice

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










Kampanakis, et al.       Expires 30 August 2026                 [Page 1]

Internet-Draft                   PQ SSH                    February 2026


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  PQ/T Hybrid Key Exchange  . . . . . . . . . . . . . . . . . .   4
     2.1.  PQ/T Hybrid Key Exchange Method Abstraction . . . . . . .   4
     2.2.  PQ/T Hybrid Key Exchange Message Numbers  . . . . . . . .   5
     2.3.  PQ/T Hybrid Key Exchange Method Names . . . . . . . . . .   5
       2.3.1.  mlkem768nistp256-sha256 . . . . . . . . . . . . . . .   6
       2.3.2.  mlkem1024nistp384-sha384  . . . . . . . . . . . . . .   6
       2.3.3.  mlkem768x25519-sha256 . . . . . . . . . . . . . . . .   7
     2.4.  Shared Secret K . . . . . . . . . . . . . . . . . . . . .   7
     2.5.  Key Derivation  . . . . . . . . . . . . . . . . . . . . .   8
   3.  Message Size  . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Other Combiners  . . . . . . . . . . . . . . . . . .  14
   Appendix B.  FIPS . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Secure Shell (SSH) [RFC4251] performs key establishment using key
   exchange methods based on (Elliptic Curve) Diffie-Hellman style
   schemes defined in [RFC5656] and [RFC8731].  The cryptographic
   security of these key exchanges relies on certain instances of the
   discrete logarithm problem being computationally infeasible to solve
   for adversaries.

   However, if sufficiently large quantum computers become available,
   these instances would no longer be computationally infeasible
   rendering the current key exchange and authentication methods in SSH
   insecure.  While large quantum computers are not available today an
   adversary could record the encrypted communication sent between the
   client and server in an SSH session and later decrypt it when



Kampanakis, et al.       Expires 30 August 2026                 [Page 2]

Internet-Draft                   PQ SSH                    February 2026


   sufficiently large quantum computers become available.  This kind of
   attack is known as a 'harvest-now-decrypt-later' attack
   [I-D.ietf-pquip-pqc-engineers].

   This document addresses the problem by extending the SSH Transport
   Layer Protocol key exchange (Section 7 of [RFC4253]) with Post-
   Quantum Traditional (PQ/T) Hybrid [RFC9794] key exchange methods.  It
   follows the migration considerations laid out in Section 4.3 of
   [I-D.ietf-opsawg-rfc5706bis].  The security provided by each key
   exchange scheme in a PQ/T Hybrid key exchange method is independent.
   This means that the PQ/T Hybrid key exchange method will always be at
   least as secure as the most secure key exchange scheme executed as
   part of the exchange.  [PQ-PROOF] [PQ-PROOF2] contain proofs of
   security for such PQ/T Hybrid key exchange schemes.

   In the context of the [NIST_PQ], key exchange algorithms are
   formulated as key encapsulation mechanisms (KEMs), which consist of
   three algorithms:

   *  'KeyGen() -> (pk, sk)': A probabilistic key generation algorithm,
      which generates a public key 'pk' and a secret key 'sk'.

   *  'Encaps(pk) -> (ct, ss)': A probabilistic encapsulation algorithm,
      which takes as input a public key 'pk' and outputs a ciphertext
      'ct' and shared secret 'ss'.

   *  'Decaps(sk, ct) -> ss': A decapsulation algorithm, which takes as
      input a secret key 'sk' and ciphertext 'ct' and outputs a shared
      secret 'ss', or in some cases a distinguished error value.

   The main security property for KEMs is indistinguishability under
   adaptive chosen ciphertext attack (IND-CCA2), which means that shared
   secret values should be indistinguishable from random strings even
   given the ability to have arbitrary ciphertexts decapsulated.  IND-
   CCA2 corresponds to security against an active attacker, and the
   public key / secret key pair can be treated as a long-term key or
   reused.  A weaker security notion is indistinguishability under
   chosen plaintext attack (IND-CPA), which means that the shared secret
   values should be indistinguishable from random strings given a copy
   of the public key.  IND-CPA roughly corresponds to security against a
   passive attacker, and sometimes corresponds to one-time key exchange.










Kampanakis, et al.       Expires 30 August 2026                 [Page 3]

Internet-Draft                   PQ SSH                    February 2026


   The post-quantum KEM used in the document is ML-KEM.  ML-KEM was
   standardized in 2024 [FIPS203] with three parameter variants, ML-KEM-
   512, ML-KEM-768, and ML-KEM-1024.  This specification's PQ/T Hybrid
   key exchange message abstraction, key derivation, and input to the
   SSH hash calculation, H, align with the ones defined in
   [I-D.ietf-sshm-ntruprime-ssh] which uses a different quantum-
   resistant KEM.

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

2.  PQ/T Hybrid Key Exchange

2.1.  PQ/T Hybrid Key Exchange Method Abstraction

   This section defines the abstract structure of a PQ/T Hybrid key
   exchange method.  This structure must be instantiated with two key
   exchange schemes.  The byte and string types are to be interpreted in
   this document as described in [RFC4251].

   In a PQ/T Hybrid key exchange, instead of SSH_MSG_KEXDH_INIT
   [RFC4253] or SSH_MSG_KEX_ECDH_INIT [RFC5656], the client sends

          byte     SSH_MSG_KEX_HYBRID_INIT
          string   C_INIT

   where C_INIT is the concatenation of C_PK2 and C_PK1 (C_INIT =
   C_PK2 || C_PK1, where || depicts concatenation).  C_PK1 and C_PK2
   represent the ephemeral client public keys used for each key exchange
   of the PQ/T Hybrid mechanism.  Typically, C_PK1 represents a
   traditional / classical (i.e., ECDH) key exchange public key.  C_PK2
   represents the 'pk' output of the corresponding post-quantum KEM's
   'KeyGen' at the client.

   Instead of SSH_MSG_KEXDH_REPLY [RFC4253] or SSH_MSG_KEX_ECDH_REPLY
   [RFC5656], the server sends

          byte     SSH_MSG_KEX_HYBRID_REPLY
          string   K_S, server's public host key
          string   S_REPLY
          string   the signature on the exchange hash





Kampanakis, et al.       Expires 30 August 2026                 [Page 4]

Internet-Draft                   PQ SSH                    February 2026


   where S_REPLY is the concatenation of S_CT2 and S_PK1 (S_REPLY =
   S_CT2 || S_PK1).  Typically, S_PK1 represents the ephemeral (EC)DH
   server public key.  S_CT2 represents the ciphertext 'ct' output of
   the corresponding KEM's 'Encaps' algorithm generated by the server
   which encapsulates a secret to the client's public key C_PK2.  Before
   producing S_CT2, to prevent length extension attack attempts, the
   server MUST check that the length of the C_INIT is the sum of the
   expected length of each public key in the negotiated method, C_PK1
   and C_PK2.  It also MUST perform the encapsulation key checks defined
   in Section 7.2 of [FIPS203].  If any of these checks fail, the client
   MUST abort using a disconnect message (SSH_MSG_DISCONNECT) with a
   SSH_DISCONNECT_KEY_EXCHANGE_FAILED as the reason.

   C_PK1, S_PK1, C_PK2, and S_CT2 are used to establish two shared
   secrets, K_CL and K_PQ.  K_CL is the output from the classical ECDH
   exchange using C_PK1 and S_PK1.  K_PQ is the post-quantum shared
   secret decapsulated from S_CT2.  Before decapsulating, to prevent
   length extension attack attempts, the client MUST check that the
   length of the S_REPLY is the sum of the expected length of the
   traditional public key, S_PK1, and the ML-KEM ciphertext, S_CT2, in
   the negotiated method.  The client MUST abort using a disconnect
   message (SSH_MSG_DISCONNECT) with a
   SSH_DISCONNECT_KEY_EXCHANGE_FAILED as the reason if the check fails
   or decapsulation fails for any other reason.  K_CL and K_PQ are used
   together to generate the shared secret K according to Section 2.4.

   For all method names, both the client and server MUST process the
   ECDH and X25519 public keys (C_PK1, S_PK1) as described in Section 4
   of [RFC5656] and Section 3 of [RFC8731] respectively, including
   validity and length checks and SSH disconnect messages if the checks
   fail.

2.2.  PQ/T Hybrid Key Exchange Message Numbers

   The message numbers 30-49 are key exchange method specific as
   specified in [RFC4250].  These numbers may be redefined by any key
   exchange method [RFC4253] without requiring an IANA registration
   process.  This document defines the following key exchange message
   numbers:

         #define SSH_MSG_KEX_HYBRID_INIT               30
         #define SSH_MSG_KEX_HYBRID_REPLY              31

2.3.  PQ/T Hybrid Key Exchange Method Names

   The PQ/T Hybrid key exchange method names defined in this document
   (to be used in SSH_MSG_KEXINIT [RFC4253]) are




Kampanakis, et al.       Expires 30 August 2026                 [Page 5]

Internet-Draft                   PQ SSH                    February 2026


         mlkem768nistp256-sha256
         mlkem1024nistp384-sha384
         mlkem768x25519-sha256

   These instantiate the abstract PQ/T Hybrid key exchanges defined in
   Section 2.1.

2.3.1.  mlkem768nistp256-sha256

   mlkem768nistp256-sha256 defines that the traditional client and
   server public keys C_PK1, S_PK1 belong to the NIST P-256 curve
   [nist-sp800-186].  The private and public keys are generated as
   described therein.  The public keys are defined as octet strings for
   NIST P-256 as per [RFC5656]; point compression may be used.  The K_CL
   shared secret is generated from the exchanged C_PK1 and S_PK1 public
   keys as defined in [RFC5656] (key agreement method ecdh-
   sha2-nistp256).

   The post-quantum C_PK2 and S_CT2 represent ML-KEM-768 public key and
   ciphertext from the client and server respectively which are encoded
   as octet strings.  The K_PQ shared secret is decapsulated from the
   ciphertext S_CT2 using the client post-quantum KEM private key as
   defined in [FIPS203].

   The HASH function used in the key exchange [RFC4253] is SHA-256
   [nist-sha2] [RFC6234].

2.3.2.  mlkem1024nistp384-sha384

   mlkem1024nistp384-sha384 defines that the traditional client and
   server public keys C_PK1, S_PK1 belong to the NIST P-384 curve
   [nist-sp800-186].  The private and public keys are generated as
   described therein.  The public keys are defined as octet strings for
   NIST P-384 as per [RFC5656]; point compression may be used.  The K_CL
   shared secret is generated from the exchanged C_PK1 and S_PK1 public
   keys as defined in [RFC5656] (key agreement method ecdh-
   sha2-nistp384).

   The post-quantum C_PK2 and S_CT2 represent ML-KEM-1024 public key and
   ciphertext from the client and server respectively which are encoded
   as octet strings.  The K_PQ shared secret is decapsulated from the
   ciphertext S_CT2 using the client post-quantum KEM private key as
   defined in [FIPS203].

   The HASH function used in the key exchange [RFC4253] is SHA-384
   [nist-sha2] [RFC6234].





Kampanakis, et al.       Expires 30 August 2026                 [Page 6]

Internet-Draft                   PQ SSH                    February 2026


2.3.3.  mlkem768x25519-sha256

   mlkem768x25519-sha256 defines that the traditional client and server
   public keys C_PK1, S_PK1 belong to the Curve25519 curve [RFC7748].
   Private and public keys are generated as described therein.  The
   public keys are defined as strings of 32 bytes as per [RFC8731].  The
   K_CL shared secret is generated from the exchanged C_PK1 and S_PK1
   public keys as defined in [RFC8731] (key agreement method
   curve25519-sha256).

   The post-quantum C_PK2 and S_CT2 represent ML-KEM-768 public key and
   ciphertext from the client and server respectively which are encoded
   as octet strings.  The K_PQ shared secret is decapsulated from the
   ciphertext S_CT2 using the client post-quantum KEM private key as
   defined in [FIPS203].

   The HASH function used in the key exchange [RFC4253] is SHA-256
   [nist-sha2] [RFC6234].

2.4.  Shared Secret K

   The PQ/T Hybrid key exchange establishes K_CL and K_PQ from the ECDH
   and ML-KEM key exchanges respectively.  The shared secret, K, is the
   HASH output of the concatenation of the two shared secrets K_CL and
   K_PQ as

           K = HASH(K_PQ || K_CL)

   This is similar, but not the same (for efficiency), logic as in TLS
   1.3 [I-D.ietf-tls-hybrid-design].  In [I-D.ietf-tls-hybrid-design],
   the classical and post-quantum exchanged secrets are concatenated and
   used in the key schedule whereas in this document they are
   concatenated and hashed before being used in SSH's key derivation
   methodology.

   The ECDH shared secret was traditionally encoded as an integer
   (mpint) as per [RFC4253], [RFC5656], and [RFC8731] and used in
   deriving the key.  In this specification, the two shared secrets,
   K_PQ and K_CL, are fed into the hash function to derive K, but they
   are encoded as fixed-length byte arrays, not as integers.  Byte
   arrays are defined in Section 5 of [RFC4251].  Specifically for K_CL,
   the conversion from mpint to a byte array is done by taking the mpint
   that the corresponding standalone key exchange method would have
   output and re-encoding it as a fixed-size (32 bytes for Curve25519
   and secp256r1 or 48 bytes for secp384r1) byte array always big-
   endian.





Kampanakis, et al.       Expires 30 August 2026                 [Page 7]

Internet-Draft                   PQ SSH                    February 2026


2.5.  Key Derivation

   The derivation of encryption keys MUST be done from the shared secret
   K according to Section 7.2 in [RFC4253] with a modification on the
   exchange hash H.

   The PQ/T Hybrid key exchange hash H is the result of computing the
   HASH, where HASH is the hash algorithm specified in the named PQ/T
   Hybrid key exchange method name, over the concatenation of the
   following

         string V_C, client identification string (CR and LF excluded)
         string V_S, server identification string (CR and LF excluded)
         string I_C, payload of the client's SSH_MSG_KEXINIT
         string I_S, payload of the server's SSH_MSG_KEXINIT
         string K_S, server's public host key
         string C_INIT, client message octet string
         string S_REPLY, server message octet string
         string K, SSH shared secret

   K, the shared secret used in H, was traditionally encoded as an
   integer (mpint) as per [RFC4253], [RFC5656], and [RFC8731].  In this
   specification, K is the hash output of the two concatenated byte
   arrays (Section 2.4) which is not an integer.  Thus, K is encoded as
   a string using the process described in Section 5 of [RFC4251] and is
   then fed along with other data in H to the key exchange method's HASH
   function to generate encryption keys.

3.  Message Size

   An SSH implementation adhering to [RFC4253] must be able to support
   packets with an uncompressed payload length of 32768 bytes or less
   and a total packet size of 35000 bytes or less (including
   'packet_length', 'padding_length', 'payload', 'random padding', and
   'mac').  These numbers represent what must be minimally supported by
   SSH applications.  Although some post-quantum key exchange schemes
   could produce large messages, this document does not define method
   names (Section 2.3) which can lead to packets exceeding the minimally
   specified lengths in Section 6.1 of [RFC4253].  Thus, this document
   does not define new behavior for cases where a PQ/T Hybrid key
   exchange message causes a packet to exceed the minimally supported
   length.









Kampanakis, et al.       Expires 30 August 2026                 [Page 8]

Internet-Draft                   PQ SSH                    February 2026


4.  Acknowledgements

   The authors want to thank Gerardo Ravago from AWS for implementing
   the draft and finding issues.  We also want to thank Damien Miller
   and Markus Friedl for their feedback and for implementing some of the
   SSH key exchange methods in this document in OpenSSH.  Special
   acknowledgements go to Simon Tatham from Putty, Loganaden Velvindron,
   John Mattsson, Simon Josefsson, and Watson Ladd for their valuable
   suggestions.

5.  IANA Considerations

   This memo requests IANA to register new method names
   "mlkem768nistp256-sha256", "mlkem1024nistp384-sha384", and
   "mlkem768x25519-sha256" in the "Key Exchange Method Names" registry
   for SSH [IANA-SSH] with a "Reference" field to this RFC and the "OK
   to implement" field of "SHOULD".

6.  Security Considerations

   The security considerations given in [RFC5656] and [RFC8731] also
   apply to the ECDH part of the P/T Hybrid key exchange schemes defined
   in this document.

   As it is commonly done with (EC)DH keys today, generating an
   ephemeral key exchange keypair for ECDH and ML-KEM per connection is
   REQUIRED by this specification.  Additionally, implementations MUST
   NOT reuse randomness in the generation of ML-KEM ciphertexts.  As a
   reminder, the security properties of the protocol in this document,
   SSH itself, and the cryptographic algorithms used, including ML-KEM,
   depend on the availability and proper use of cryptographically secure
   random data.  The generation of quality random numbers for the
   traditional and ML-KEM keypairs and the ML-KEM ciphertext can be
   difficult; see Section 3.3 of [FIPS203] for additional information
   around randomness generation for ML-KEM.

   Implementations MUST use the encodings for K_PQ, K_CL, and K
   specified in this document to prevent potential side-channel attacks.
   The way a derived binary secret string is encoded (i.e., adding or
   removing zero bytes for encoding) before it is hashed may lead to a
   variable-length secret which raises the potential for a side-channel
   attack.  In broad terms, when the secret is longer, the hash function
   may need to process more blocks internally which could determine the
   length of what is hashed.  This could leak the most significant bit
   of the derived secret and/or allow detection of when the most
   significant bytes are zero.  In some unfortunate circumstances, this
   has led to timing attacks, e.g. the Lucky Thirteen [LUCKY13] and
   Raccoon [RACCOON] attacks.  In [RFC8731] and [RFC5656], the ECDH



Kampanakis, et al.       Expires 30 August 2026                 [Page 9]

Internet-Draft                   PQ SSH                    February 2026


   shared secrets were mpint and fixed-length integer encoded
   respectively which raised a potential for such side-channel attacks.
   This problem is addressed in this document by encoding K_PQ and K_CL
   as fixed-length byte arrays and K as a string.

   [PQ-PROOF] [PQ-PROOF2] contain proofs of security for PQ/T Hybrid key
   exchange schemes.  [PQ-PROOF2] discusses how the key combination to
   derive K and the derivation of SSH symmetric keys in this document
   can be proven IND-CPA and IND-CCA2 secure with some assumptions.
   IND-CPA is achieved if we assume the HASH calls perform as a KDF
   which is a reasonable assumption.  IND-CCA2 security is achieved by
   assuming the HASH is a random oracle which is a stronger assumption
   especially for variants of the SHA-2 family which introduce length
   extension risks.  To leverage a HASH which is more suitable as a
   random oracle, we could use SHAKE256 or introduce HMAC-SHA-256 as
   proposed in options (2b) and (2c) in Appendix A.  This document uses
   SHA-2 which is ubiquitous although it makes an IND-CCA2 proof need
   stronger assumptions because even SSH's traditional key derivation
   has not been proven to be IND-CCA2.

   X25519, the traditional elliptic curve key exchange used in one of
   the PQ/T hybrid methods specified in this document, is generally
   considered easier to implement securely without side-channels than
   its NIST counterparts (with P256, P384).  Historically,
   implementations of P256 and P384 have suffered various implementation
   issues which have been addressed over time.  Optimized X25119
   implementations are also more efficient than P256 and P384.  Thus,
   X25519 has seen more adoption than P256 and P384 across cryptographic
   use-cases.  NIST curves are sometimes preferred for regulatory
   compliance.

7.  References

7.1.  Normative References

   [FIPS203]  National Institute of Standards and Technology (NIST),
              "Module-Lattice-Based Key-Encapsulation Mechanism
              Standard", NIST Federal Information Processing Standards,
              13 August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.203.pdf>.

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






Kampanakis, et al.       Expires 30 August 2026                [Page 10]

Internet-Draft                   PQ SSH                    February 2026


   [RFC4251]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
              January 2006, <https://www.rfc-editor.org/info/rfc4251>.

   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
              January 2006, <https://www.rfc-editor.org/info/rfc4253>.

   [RFC5656]  Stebila, D. and J. Green, "Elliptic Curve Algorithm
              Integration in the Secure Shell Transport Layer",
              RFC 5656, DOI 10.17487/RFC5656, December 2009,
              <https://www.rfc-editor.org/info/rfc5656>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

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

   [RFC8731]  Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure
              Shell (SSH) Key Exchange Method Using Curve25519 and
              Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020,
              <https://www.rfc-editor.org/info/rfc8731>.

7.2.  Informative References

   [I-D.connolly-cfrg-xwing-kem]
              Connolly, D., Schwabe, P., and B. Westerbaan, "X-Wing:
              general-purpose hybrid post-quantum KEM", Work in
              Progress, Internet-Draft, draft-connolly-cfrg-xwing-kem-
              09, 1 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-connolly-
              cfrg-xwing-kem-09>.

   [I-D.hoffman-c2pq]
              Hoffman, P. E., "The Transition from Classical to Post-
              Quantum Cryptography", Work in Progress, Internet-Draft,
              draft-hoffman-c2pq-07, 26 May 2020,
              <https://datatracker.ietf.org/doc/html/draft-hoffman-c2pq-
              07>.

   [I-D.ietf-opsawg-rfc5706bis]
              Claise, B., Clarke, J., Farrel, A., Barguil, S.,
              Pignataro, C., and R. Chen, "Guidelines for Considering
              Operations and Management in IETF Specifications", Work in



Kampanakis, et al.       Expires 30 August 2026                [Page 11]

Internet-Draft                   PQ SSH                    February 2026


              Progress, Internet-Draft, draft-ietf-opsawg-rfc5706bis-02,
              19 February 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-opsawg-rfc5706bis-02>.

   [I-D.ietf-pquip-pqc-engineers]
              Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
              T., and M. Ounsworth, "Post-Quantum Cryptography for
              Engineers", Work in Progress, Internet-Draft, draft-ietf-
              pquip-pqc-engineers-14, 25 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
              pqc-engineers-14>.

   [I-D.ietf-sshm-ntruprime-ssh]
              Friedl, M., Mojzis, J., and S. Josefsson, "Secure Shell
              (SSH) Key Exchange Method Using Hybrid Streamlined NTRU
              Prime sntrup761 and X25519 with SHA-512:
              sntrup761x25519-sha512", Work in Progress, Internet-Draft,
              draft-ietf-sshm-ntruprime-ssh-06, 30 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sshm-
              ntruprime-ssh-06>.

   [I-D.ietf-tls-hybrid-design]
              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>.

   [I-D.josefsson-chempat]
              Josefsson, S., "Chempat: Generic Instantiated PQ/T Hybrid
              Key Encapsulation Mechanisms", Work in Progress, Internet-
              Draft, draft-josefsson-chempat-04, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-josefsson-
              chempat-04>.

   [IANA-SSH] IANA, "Secure Shell (SSH) Protocol Parameters", 2021,
              <https://www.iana.org/assignments/ssh-parameters/ssh-
              parameters.xhtml>.

   [LUCKY13]  Al Fardan, N.J. and K.G. Paterson, "Lucky Thirteen:
              Breaking the TLS and DTLS record protocols", 2013,
              <https://ieeexplore.ieee.org/
              iel7/6547086/6547088/06547131.pdf>.

   [nist-sha2]
              NIST, "FIPS PUB 180-4", 2015,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.



Kampanakis, et al.       Expires 30 August 2026                [Page 12]

Internet-Draft                   PQ SSH                    February 2026


   [NIST-SP-800-133r2]
              National Institute of Standards and Technology (NIST),
              "Recommendation for Cryptographic Key Generation", June
              2020, <https://doi.org/10.6028/NIST.SP.800-133r2>.

   [NIST-SP-800-135]
              National Institute of Standards and Technology (NIST),
              "Recommendation for Existing Application-Specific Key
              Derivation Functions", December 2011,
              <https://doi.org/10.6028/NIST.SP.800-135r1>.

   [NIST-SP-800-227]
              National Institute of Standards and Technology (NIST),
              "Recommendations for Key-Encapsulation Mechanisms",
              September 2025, <https://doi.org/10.6028/NIST.SP.800-227>.

   [NIST-SP-800-56C]
              National Institute of Standards and Technology (NIST),
              "Recommendation for Key-Derivation Methods in Key-
              Establishment Schemes", August 2020,
              <https://doi.org/10.6028/NIST.SP.800-56Cr2>.

   [nist-sp800-186]
              NIST, "SP 800-186", 2019,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-186-draft.pdf>.

   [NIST_PQ]  NIST, "Post-Quantum Cryptography", 2020,
              <https://csrc.nist.gov/projects/post-quantum-
              cryptography>.

   [PQ-PROOF] Campagna, M. and A. Petcher, "Security of Hybrid Key
              Encapsulation", 2020, <https://eprint.iacr.org/2020/1364>.

   [PQ-PROOF2]
              Petcher, A. and M. Campagna, "Security of Hybrid Key
              Establishment using Concatenation", 2023,
              <https://eprint.iacr.org/2023/972>.

   [RACCOON]  Merget, R., Brinkmann, M., Aviram, N., Somorovsky, J.,
              Mittmann, J., and J. Schwenk, "Raccoon Attack: Finding and
              Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)",
              September 2020, <https://raccoon-attack.com/>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.



Kampanakis, et al.       Expires 30 August 2026                [Page 13]

Internet-Draft                   PQ SSH                    February 2026


   [RFC4250]  Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Protocol Assigned Numbers", RFC 4250,
              DOI 10.17487/RFC4250, January 2006,
              <https://www.rfc-editor.org/info/rfc4250>.

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

   [RFC9794]  Driscoll, F., Parsons, M., and B. Hale, "Terminology for
              Post-Quantum Traditional Hybrid Schemes", RFC 9794,
              DOI 10.17487/RFC9794, June 2025,
              <https://www.rfc-editor.org/info/rfc9794>.

Appendix A.  Other Combiners

   Other combiners to derive K and the SSH keys were considered while
   working on this document.  These include

   (1)  K = K_PQ || K_CL.  All SSH keys are derived from K as defined in
        Section 7.2 in [RFC4253].

   (2)  All SSH keys are derived from K as defined in Section 7.2 in
        [RFC4253].

        (a)  K = HASH(K_PQ, K_CL).  This is the option adopted in this
             specification.

        (b)  K = HMAC-HASH(K_PQ, K_CL)

        (c)  K = HMAC-HASH(0, K_PQ || K_CL)

   (3)  K = HKDF-HASH_Extract(0, K_PQ || K_CL).  SSH keys are now
        derived from K using HKDF-HASH(K, H || session_id,
        6*sizeof(HASH)).

   Option (3) follows the Extract-and-Expand logic described in
   [NIST-SP-800-56C].  It deviates from existing SSH key derivation
   significantly and might be viewed as too far from the current SSH
   design.  It probably would be a good approach for SSH to move from
   basic hashing everywhere to use proper KDFs with extract/expand, but
   that should be a separate effort.









Kampanakis, et al.       Expires 30 August 2026                [Page 14]

Internet-Draft                   PQ SSH                    February 2026


   We also considered combiners like the ones proposed in
   [I-D.josefsson-chempat] and [I-D.connolly-cfrg-xwing-kem].
   [I-D.connolly-cfrg-xwing-kem] has a separate IND-CCA2 security proof.
   Although such combiners may be proven IND-CCA2 secure, to be IND-
   CCA2, the SSH key derivation would still require the assumptions laid
   out in [PQ-PROOF2] and discussed in Section 6.

Appendix B.  FIPS

   [NIST-SP-800-56C] and [NIST-SP-800-135] give NIST recommendations for
   key derivation methods in key exchange protocols.  Some PQ/T Hybrid
   combinations may combine the shared secret from a NIST-approved
   algorithm (e.g., ECDH using the nistp256/secp256r1 curve or ML-KEM)
   with a shared secret from a non-approved algorithm (e.g., X25519).
   [NIST-SP-800-227] lists simple concatenation as an approved way of
   producing a PQ/T Hybrid shared secret in which one of the constituent
   secrets is from an approved algorithm (i.e., secp256r1, secp384r1,
   ML-KEM) and using it in a key derivation/combination method approved
   by [NIST-SP-800-56C] or [NIST-SP-800-133r2].  Although the SSH key
   derivation function does not follow [NIST-SP-800-56C] or
   [NIST-SP-800-133r2], it is approved by [NIST-SP-800-135].  This
   method is the same used in this document to derive SSH keys from the
   quantum-resistant shared secret.  Thus, the SSH key combiner in this
   document appears to be FIPS-approved although it is not specifically
   called out in [NIST-SP-800-227].

Authors' Addresses

   Panos Kampanakis
   AWS
   Email: kpanos@amazon.com


   Douglas Stebila
   University of Waterloo
   Email: dstebila@uwaterloo.ca


   Torben Hansen
   AWS
   Email: htorben@amazon.com










Kampanakis, et al.       Expires 30 August 2026                [Page 15]


name: draft-ietf-lake-edhoc-psk
rev: 06
title: EDHOC Authenticated with Pre-Shared Keys (PSK)
time: 2025-11-21T17:26:07Z
group_uri: /api/v1/group/group/2249/
expires: 2026-04-23T17:50:56Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/145/"]
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014862+00:00
abstract:
This document specifies a Pre-Shared Key (PSK) authentication method
   for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange
   protocol.  The PSK method enhances computational efficiency while
   providing mutual authentication, ephemeral key exchange, identity
   protection, and quantum resistance.  It is particularly suited for
   systems where nodes share a PSK provided out-of-band (external PSK)
   and enables efficient session resumption with less computational
   overhead when the PSK is provided from a previous EDHOC session
   (resumption PSK).  This document details the PSK method flow, key
   derivation changes, message formatting, processing, and security
   considerations.

full_text:
LAKE Working Group                                        E. Lopez-Perez
Internet-Draft                                                     Inria
Intended status: Standards Track                             G. Selander
Expires: 23 April 2026                                 J. Preuß Mattsson
                                                                Ericsson
                                                          R. Marin-Lopez
                                                          F. Lopez-Gomez
                                                    University of Murcia
                                                         20 October 2025


             EDHOC Authenticated with Pre-Shared Keys (PSK)
                      draft-ietf-lake-edhoc-psk-06

Abstract

   This document specifies a Pre-Shared Key (PSK) authentication method
   for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange
   protocol.  The PSK method enhances computational efficiency while
   providing mutual authentication, ephemeral key exchange, identity
   protection, and quantum resistance.  It is particularly suited for
   systems where nodes share a PSK provided out-of-band (external PSK)
   and enables efficient session resumption with less computational
   overhead when the PSK is provided from a previous EDHOC session
   (resumption PSK).  This document details the PSK method flow, key
   derivation changes, message formatting, processing, and security
   considerations.

About This Document

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

   The latest revision of this draft can be found at https://lake-
   wg.github.io/psk/#go.draft-ietf-lake-edhoc-psk.html.  Status
   information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc-psk/.

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

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







Lopez-Perez, et al.       Expires 23 April 2026                 [Page 1]

Internet-Draft                  EDHOC-PSK                   October 2025


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 23 April 2026.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Credentials . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  ID_CRED_PSK . . . . . . . . . . . . . . . . . . . . .   5
       3.1.2.  CRED_I and CRED_R . . . . . . . . . . . . . . . . . .   6
       3.1.3.  Encoding and processing guidelines  . . . . . . . . .   7
     3.2.  Message Flow of EDHOC-PSK . . . . . . . . . . . . . . . .   7
   4.  Key Derivation  . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Message Formatting and Processing . . . . . . . . . . . . . .  10
     5.1.  Message 1 . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Message 2 . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.2.1.  Formatting of Message 2 . . . . . . . . . . . . . . .  10
       5.2.2.  Responder Composition of Message 2  . . . . . . . . .  10
       5.2.3.  Initiator Processing of Message 2 . . . . . . . . . .  10



Lopez-Perez, et al.       Expires 23 April 2026                 [Page 2]

Internet-Draft                  EDHOC-PSK                   October 2025


     5.3.  Message 3 . . . . . . . . . . . . . . . . . . . . . . . .  11
       5.3.1.  Formatting of Message 3 . . . . . . . . . . . . . . .  11
       5.3.2.  Initiator Composition of Message 3  . . . . . . . . .  11
       5.3.3.  Responder Processing of Message 3 . . . . . . . . . .  12
     5.4.  Message 4 . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  PSK usage for Session Resumption  . . . . . . . . . . . . . .  13
     6.1.  Cipher Suite Requirements for Resumption  . . . . . . . .  14
     6.2.  Privacy Considerations for Resumption . . . . . . . . . .  14
     6.3.  Security Considerations for Resumption  . . . . . . . . .  14
   7.  EDHOC-PSK and Extensible Authentication Protocol (EAP)  . . .  15
   8.  EDHOC-PSK and OSCORE  . . . . . . . . . . . . . . . . . . . .  15
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     9.1.  Identity Protection . . . . . . . . . . . . . . . . . . .  16
     9.2.  Mutual Authentication . . . . . . . . . . . . . . . . . .  16
     9.3.  Protection of External Authorization Data (EAD) . . . . .  17
     9.4.  Cryptographic strength  . . . . . . . . . . . . . . . . .  17
     9.5.  Downgrade Protection  . . . . . . . . . . . . . . . . . .  17
     9.6.  Post Quantum Considerations . . . . . . . . . . . . . . .  17
     9.7.  Confidentiality . . . . . . . . . . . . . . . . . . . . .  18
     9.8.  Independence of Session Keys  . . . . . . . . . . . . . .  18
     9.9.  Unified Approach and Recommendations  . . . . . . . . . .  18
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     10.1.  EDHOC Method Type Registry . . . . . . . . . . . . . . .  19
     10.2.  EDHOC Exporter Label Registry  . . . . . . . . . . . . .  19
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     11.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Appendix A.  CDDL Definitions . . . . . . . . . . . . . . . . . .  22
   Appendix B.  Test Vectors . . . . . . . . . . . . . . . . . . . .  23
     B.1.  message_1 . . . . . . . . . . . . . . . . . . . . . . . .  23
     B.2.  message_2 . . . . . . . . . . . . . . . . . . . . . . . .  24
     B.3.  message_3 . . . . . . . . . . . . . . . . . . . . . . . .  26
     B.4.  message_4 . . . . . . . . . . . . . . . . . . . . . . . .  28
     B.5.  PRK_out and PRK_exporter  . . . . . . . . . . . . . . . .  29
     B.6.  rPSK and rKID . . . . . . . . . . . . . . . . . . . . . .  29
   Appendix C.  Change Log . . . . . . . . . . . . . . . . . . . . .  29
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  30
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30

1.  Introduction

   This document defines a Pre-Shared Key (PSK) authentication method
   for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange
   protocol [RFC9528].  The PSK method balances the complexity of
   credential distribution with computational efficiency.  While
   symmetric key distribution is more complex than asymmetric
   approaches, PSK authentication offers greater computational
   efficiency compared to the methods outlined in [RFC9528].  The PSK



Lopez-Perez, et al.       Expires 23 April 2026                 [Page 3]

Internet-Draft                  EDHOC-PSK                   October 2025


   method retains mutual authentication, asymmetric ephemeral key
   exchange, and identity protection established by [RFC9528].

   EDHOC with PSK authentication benefits use cases where two nodes
   share a Pre-Shared Key (PSK) provided out-of-band (external PSK).
   Examples include the Authenticated Key Management Architecture (AKMA)
   in mobile systems or the Peer and Authenticator in Extensible
   Authentication Protocol (EAP) systems.  The PSK method enables the
   nodes to perform ephemeral key exchange, achieving Perfect Forward
   Secrecy (PFS).  This ensures that even if the PSK is compromised,
   past communications remain secure against active attackers, while
   future communications are protected against passive attackers.
   Additionally, by leveraging the PSK for both authentication and key
   derivation, the method provides quantum-resistant key exchange and
   authentication even when used with ECDHE.

   Another important use case of PSK authentication in the EDHOC
   protocol is session resumption.  This allows previously connected
   parties to quickly reestablish secure communication using pre-shared
   keys from a prior session, reducing the overhead associated with key
   exchange and asymmetric authentication.  By using PSK authentication,
   EDHOC allows session keys to be refreshed with significantly lower
   computational overhead compared to public-key authentication.  In
   this case, the resumption PSK is provisioned after the establishment
   of a previous EDHOC session by using EDHOC_Exporter.  Thus, the
   external PSK serves as a long-term credential while the resumption
   PSK acts as a session key.

   Section 3 provides an overview of the PSK method flow and
   credentials.  Section 4 outlines the changes to key derivation
   compared to [RFC9528].  Section 5 details message formatting and
   processing, and Section 6 describes the usage of PSK for resumption.
   Section 7 defines the use of EDHOC-PSK with OSCORE.  Security
   considerations are described in Section 8, and Section 9 outlines the
   IANA considerations.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.








Lopez-Perez, et al.       Expires 23 April 2026                 [Page 4]

Internet-Draft                  EDHOC-PSK                   October 2025


   Readers are expected to be familiar with the terms and concepts
   described in EDHOC [RFC9528], CBOR [RFC8949], CBOR Sequences
   [RFC8742], COSE Structures and Processing [RFC9052], COSE Algorithms
   [RFC9053], CWT and CCS [RFC8392], and the Concise Data Definition
   Language (CDDL) [RFC8610], which is used to express CBOR data
   structures.

3.  Protocol

   This document specifies a new EDHOC authentication method (see
   Section 3.2 of [RFC9528]) referred to as the Pre-Shared Key method
   (EDHOC-PSK).  This method shares some features with, and differs in
   other respects from, the authentication methods previously defined in
   EDHOC.

   Authentication is based on a Pre-Shared Key (PSK) shared between the
   Initiator and the Responder.  As in the methods defined in [RFC9528],
   CRED_I and CRED_R are authentication credentials containing
   identifying information for the Initiator and Responder,
   respectively.  However, unlike those methods, there is a single
   shared authentication credential identifier, ID_CRED_PSK, which the
   Responder uses to retrieve the PSK and the associated authentication
   credentials.

3.1.  Credentials

   The Initiator and Responder are assumed to share a PSK (either an
   external PSK or a resumption PSK) with high entropy that meets the
   following requirements:

   *  Only the Initiator and the Responder have access to the PSK.

   *  The Responder can retrieve the PSK, CRED_I, and CRED_R, using
      ID_CRED_PSK.

3.1.1.  ID_CRED_PSK

   ID_CRED_PSK is a COSE header map containing header parameters that
   can identify a pre-shared key.  For example:

   ID_CRED_PSK = {4 : h'0f' }; 4 = 'kid'

   The purpose of ID_CRED_PSK is to facilitate retrieval of the correct
   PSK.  While ID_CRED_PSK use encoding and representation patterns from
   [RFC9528], it differs fundamentally in that it identifies a symmetric
   key rather than a public authentication key.





Lopez-Perez, et al.       Expires 23 April 2026                 [Page 5]

Internet-Draft                  EDHOC-PSK                   October 2025


   It is RECOMMENDED that ID_CRED_PSK uniquely or stochastically
   identifies the corresponding PSK.  Uniqueness avoids ambiguity that
   could require the recipient to try multiple keys, while stochasticity
   reduces the risk of identifier collisions and supports stateless
   processing.  These properties align with the requirements for rKID in
   session resumption.

3.1.2.  CRED_I and CRED_R

   CRED_I and CRED_R are authentication credentials associated with the
   PSK.  The notation CRED_x refers to either CRED_I or CRED_R.
   Authentication is achieved implicitly through the successful use of
   the PSK to derive keying material, and to encrypt and subsequently
   decrypt protected messages.

   When using an external PSK, a common representation of CRED_I and
   CRED_R is a CBOR Web Token (CWT) or CWT Claims Set (CCS) [RFC8392],
   where the 'cnf' claim includes the confirmation method COSE_Key.  An
   example of CRED_I and CRED_R is shown below:

   {                                               /CCS/
     2 : "42-50-31-FF-EF-37-32-39",                /sub/
     8 : {                                         /cnf/
       1 : {                                       /COSE_Key/
          1 : 4,                                   /kty/
          2 : h'0f',                               /kid/
       }
     }
   }

   {                                               /CCS/
     2 : "23-11-58-AA-B3-7F-10",                   /sub/
     8 : {                                         /cnf/
       1 : {                                       /COSE_Key/
          1 : 4,                                   /kty/
          2 : h'0f',                               /kid/
       }
     }
   }

   Alternative formats for CRED_I and CRED_R MAY be used.  When a
   resumption PSK is employed, CRED_I and CRED_R MUST be the same
   credentials used in the initial EDHOC exchange, for example, public-
   key credentials such as X.509 certificates.

   Implementations MUST ensure that CRED_I and CRED_R are distinct, for
   example by including different identities in their sub-claims (e.g.,
   "42-50-31-FF-EF-37-32-39" and "23-11-58-AA-B3-7F-10").  Ensuring



Lopez-Perez, et al.       Expires 23 April 2026                 [Page 6]

Internet-Draft                  EDHOC-PSK                   October 2025


   distinct credentials simplifies correct party identification and
   prevents reflection and misbinding attacks, as described in
   Appendix D.2 of [RFC9528].

3.1.3.  Encoding and processing guidelines

   The following guidelines apply to the encoding and handling of CRED_x
   and ID_CRED_PSK.  Requirements on CRED_x applies both to CRED_I and
   to CRED_R.

   *  If CRED_x is CBOR-encoded, it SHOULD use deterministic encoding as
      specified in Sections 4.2.1 and 4.2.2. of [RFC8949].
      Deterministic encoding ensures consistent identification and
      avoids interoperability issues caused by non-deterministic CBOR
      variants.

   *  If CRED_x is provisioned out-of-band and transported by value, it
      SHOULD be used as received without re-encoding.  Re-encoding can
      cause mismatches when comparing identifiers such as hash values or
      'kid' references.

   *  ID_CRED_PSK SHOULD uniquely identify the corresponding PSK to
      avoid ambiguity.  When ID_CRED_PSK contains a key identifier, care
      must be taken to ensure that 'kid' is unique for the PSK.

   *  When ID_CRED_PSK consists solely of a 'kid' parameter (i.e., { 4 :
      kid }), the compact encoding optimization defined in
      Section 3.5.3.2 of [RFC9528] MUST be applied in plaintext fields
      (such as PLAINTEXT_3A).  For example:

      -  { 4 : h'0f' } encoded as h'0f' (CBOR byte string)

      -  { 4 : 21 } encoded as 0x15 (CBOR integer)

   These optimizations MUST NOT be applied in COSE header parameters or
   in other contexts where the full map structure is required.

   *  To mitigate misbinding attacks, identity information such as a
      'sub' (subject) claim MUST be included in both CRED_I and CRED_R.

3.2.  Message Flow of EDHOC-PSK

   The message flow of EDHOC-PSK follows the structure defined in
   [RFC9528], with authentication based on symmetric keys rather than
   public keys.  For identity protection, credential-related message
   fields appear first in message_3.





Lopez-Perez, et al.       Expires 23 April 2026                 [Page 7]

Internet-Draft                  EDHOC-PSK                   October 2025


   ID_CRED_PSK is encrypted using a key derived from a shared secret
   obtained through the first two messages.  If Diffie-Hellman key
   exchange is used, G_X and G_Y are the ephemeral public keys, and the
   shared secret G_XY is the DH shared secret, as in [RFC9528].  If the
   Diffie-Hellman procedure is replaced by a KEM, then G_X and G_Y are
   encapsulation key and ciphertext, respectively, and the shared secret
   G_XY is derived by the KEM, see [I-D.spm-lake-pqsuites].

   The Responder authenticates the Initiator first.  Figure 1
   illustrates the message flow of the EDHOC-PSK authentication method.

   Initiator                                                   Responder
   |                  METHOD, SUITES_I, G_X, C_I, EAD_1                |
   +------------------------------------------------------------------>|
   |                             message_1                             |
   |                                                                   |
   |                      G_Y, Enc( C_R, EAD_2 )                       |
   |<------------------------------------------------------------------+
   |                             message_2                             |
   |                                                                   |
   |                   Enc( ID_CRED_PSK, AEAD( EAD_3 ) )               |
   +------------------------------------------------------------------>|
   |                             message_3                             |
   |                                                                   |
   |                           AEAD( EAD_4 )                           |
   |<------------------------------------------------------------------+
   |                             message_4                             |

              Figure 1: Overview of Message Flow of EDHOC-PSK.

   This approach provides identity protection against passive attackers
   for both Initiator and Responder.  EDHOC message_4 remains OPTIONAL,
   but is needed to authenticate the Responder and achieve mutual
   authentication in EDHOC when external applications (e.g., OSCORE) are
   not relied upon.  In either case, the inclusion of a fourth message
   provides mutual authentication and explicit key confirmation (see
   Section 5.4).

4.  Key Derivation

   The pseudorandom keys (PRKs) used in the EDHOC-PSK authentication
   method are derived with EDHOC_Extract, as in [RFC9528].

   PRK  = EDHOC_Extract( salt, IKM )

   where salt and input keying material (IKM) are defined for each key.
   The definition of EDHOC_Extract depends on the EDHOC hash algorithm
   selected in the cipher suite, see Section 4.1.1 of [RFC9528].



Lopez-Perez, et al.       Expires 23 April 2026                 [Page 8]

Internet-Draft                  EDHOC-PSK                   October 2025


   To maintain a uniform key schedule across all EDHOC authentication
   methods, the same pseudorandom key notation (PRK_2e, PRK_3e2m, and
   PRK_4e3m) is retained.  The index notation is preserved for
   consistency with other EDHOC authentication variants, even though it
   does not fully reflect the functional role of the keys in this
   method; for example, no MACs are used in EDHOC-PSK.

   PRK_2e is extracted as in [RFC9528] with

   *  salt = TH_2, and

   *  IKM = G_XY,

   where the transcript hash TH_2 = H( G_Y, H(message_1) ) is defined in
   Section 5.3.2 of [RFC9528].

   SALT_4e3m is derived from PRK_3e2m and TH_3, as shown in Figure 6 of
   [RFC9528].

   The other PRKs and transcript hashes are modified as specified below.
   Figure 2 lists the key derivations that differ from Section 4.1.2 of
   [RFC9528].

    PRK_3e2m     = PRK_2e
    KEYSTREAM_2A = EDHOC_KDF( PRK_2e,   0, TH_2,  plaintext_length_2a )
    PRK_4e3m     = EDHOC_Extract( SALT_4e3m, PSK )
    KEYSTREAM_3A = EDHOC_KDF( PRK_3e2m, 12, TH_3, plaintext_length_3a )
    K_3          = EDHOC_KDF( PRK_4e3m, 3, TH_3, key_length )
    IV_3         = EDHOC_KDF( PRK_4e3m, 4, TH_3, iv_length )

                   Figure 2: Key Derivation of EDHOC-PSK.

   where:

   *  KEYSTREAM_2A is used to encrypt PLAINTEXT_2A in message_2.

      -  plaintext_length_2a is the length of PLAINTEXT_2A in message_2.

   *  KEYSTREAM_3A is used to encrypt PLAINTEXT_3A (the concatenation of
      ID_CRED_PSK and CIPHERTEXT_3B) in message_3.

      -  plaintext_length_3a is the length of PLAINTEXT_3A in message_3.

   *  TH_3 = H( TH_2, PLAINTEXT_2A ).

   The definition of the transcript hash TH_4 is modified as follows:

   *  TH_4 = H( TH_3, ID_CRED_PSK, PLAINTEXT_3B, CRED_I, CRED_R )



Lopez-Perez, et al.       Expires 23 April 2026                 [Page 9]

Internet-Draft                  EDHOC-PSK                   October 2025


5.  Message Formatting and Processing

   This section specifies the differences in message formatting and
   processing compared to Section 5 of [RFC9528].  Note that if any
   processing step fails, then the Responder MUST send an EDHOC error
   message back as defined in Section 6 of [RFC9528], and the EDHOC
   session MUST be aborted.

5.1.  Message 1

   Message 1 is formatted and processed as specified in Section 5.2 of
   [RFC9528].

5.2.  Message 2

5.2.1.  Formatting of Message 2

   Message 2 is formatted as specified in Section 5.3.1 of [RFC9528].

5.2.2.  Responder Composition of Message 2

   CIPHERTEXT_2A is calculated with a binary additive stream cipher,
   using a keystream generated with EDHOC_Expand, and the following
   plaintext:

   *  PLAINTEXT_2A = ( C_R, ? EAD_2 )

   *  CIPHERTEXT_2A = PLAINTEXT_2A XOR KEYSTREAM_2A

   C_R, EAD_2 are defined in Section 5.3.2 of [RFC9528].  In contrast to
   [RFC9528], ID_CRED_R, MAC_2, and Signature_or_MAC_2 are not included
   in message_2.  This omission is the primary difference from the
   signature and MAC-based authentication methods defined in [RFC9528],
   as authentication in EDHOC-PSK relies solely on the shared PSK and
   the successful decryption of protected messages.  KEYSTREAM_2A is
   defined in Section 4.

5.2.3.  Initiator Processing of Message 2

   Upon receiving message_2, the Initiator processes it as follows:

   *  Compute KEYSTREAM_2A as defined in Section 4.

   *  Decrypt CIPHERTEXT_2A using binary XOR, i.e., PLAINTEXT_2A =
      CIPHERTEXT_2A XOR KEYSTREAM_2A






Lopez-Perez, et al.       Expires 23 April 2026                [Page 10]

Internet-Draft                  EDHOC-PSK                   October 2025


   In contrast to Section 5.3.3 of [RFC9528], ID_CRED_R is not made
   available to the application in step 4, and steps 5 and 6 are
   skipped.

5.3.  Message 3

5.3.1.  Formatting of Message 3

   Message 3 is formatted as specified in Section 5.4.1 of [RFC9528].

5.3.2.  Initiator Composition of Message 3

   *  CIPHERTEXT_3A is computed using a binary additive stream cipher
      with a keystream generated by EDHOC_Expand, applied to the
      following plaintext:

      -  PLAINTEXT_3A = ( ID_CRED_PSK / bstr / -24..23, CIPHERTEXT_3B )

         o  If ID_CRED_PSK contains a single 'kid' parameter, i.e.,
            ID_CRED_PSK = { 4 : kid_PSK }, then the compact encoding is
            applied, see Section 3.5.3.2 of [RFC9528].

         o  For the case of plaintext_length exceeding the EDHOC_KDF
            output size, see Appendix G of [RFC9528].

      -  Compute KEYSTREAM_3A as in Section 4.

      -  CIPHERTEXT_3A = PLAINTEXT_3A XOR KEYSTREAM_3A

   *  CIPHERTEXT_3B is the 'ciphertext' of COSE_Encrypt0 object as
      defined in Section 5.2 and Section 5.3 of [RFC9528], with the
      EDHOC AEAD algorithm of the selected cipher suite, using the
      encryption key K_3, the initialization vector IV_3 (if used by the
      AEAD algorithm), the parameters described in Section 5.2 of
      [RFC9528], plaintext PLAINTEXT_3B and the following parameters as
      input:

      -  protected = h''

      -  external_aad = << ID_CRED_PSK, TH_3, CRED_I, CRED_R >>

      -  K_3 and IV_3 as defined in Section 4

      -  PLAINTEXT_3B = ( ? EAD_3 )

   The Initiator computes TH_4 as defined in Section 4.





Lopez-Perez, et al.       Expires 23 April 2026                [Page 11]

Internet-Draft                  EDHOC-PSK                   October 2025


   There is no need for MAC_3 or signature, since AEAD's built-in
   integrity and the use of PSK-based key derivation provides implicit
   authentication of the Initiator.

5.3.3.  Responder Processing of Message 3

   Upon receiving message_3, the Responder proceeds as follows:

   *  Derive K_3 and IV_3 as defined in Section 4.

   *  Parse the structure of message_3, which consists of a stream-
      cipher encrypted structure, CIPHERTEXT_3A = PLAINTEXT_3A XOR
      KEYSTREAM_3A, where PLAINTEXT_3A = ( ID_CRED_PSK, CIPHERTEXT_3B )
      and CIPHERTEXT_3B is the inner AEAD-encrypted object.

   *  Generate KEYSTREAM_3A with the same method the Initiator used.

   *  Decrypt CIPHERTEXT_3A using binary XOR with KEYSTREAM_3A to
      recover PLAINTEXT_3A.

   *  Use ID_CRED_PSK to identify the authentication credentials and
      retrieve PSK.

   *  AEAD-decrypt CIPHERTEXT_3B using:

      -  K_3, IV_3

      -  external_aad = << ID_CRED_PSK, TH_3, CRED_I, CRED_R >>

      -  protected = h''

      -  AEAD algorithm from cipher suite

   If AEAD verification fails, this indicates a processing problem or
   that the message was tampered with.  If it succeeds, the Responder
   concludes that the Initiator possesses the PSK, correctly derived
   TH_3, and is actively participating in the protocol.

   Finally, the Responder computes TH_4 as defined in Section 4.

   No MAC_3 or signature is needed, as the AEAD tag guarantees both
   integrity and authenticity in this symmetric setting.

5.4.  Message 4

   Message 4 is formatted and processed as specified in Section 5.5 of
   [RFC9528].




Lopez-Perez, et al.       Expires 23 April 2026                [Page 12]

Internet-Draft                  EDHOC-PSK                   October 2025


   After successfully verifying message_4, or another fourth message
   from the Responder protected with an exported application key such as
   an OSCORE message, the Initiator is assured that the Responder has
   derived PRK_out (key confirmation) and that no other party can derive
   this key.

   The Initiator MUST NOT persistently store PRK_out or application keys
   until it has successfully verified such a fourth message and the
   application has authenticated the Responder.

   Compared to [RFC9528], the fourth message not only provides key
   confirmation but also authenticates the Responder.  For mutual
   authentication a fourth message is therefore mandatory.

6.  PSK usage for Session Resumption

   This section specifies how EDHOC-PSK is used for session resumption
   in EDHOC.  The EDHOC_Exporter, as defined in Section 4.2 of
   [RFC9528], is used to derive the resumption parameters rPSK and rKID:

     rPSK         = EDHOC_Exporter( TBD2, h'', resumption_psk_length )
     rKID         = EDHOC_Exporter( TBD3, h'', id_cred_psk_length )
     rID_CRED_PSK = { 4 : rKID }

                      Figure 3: Resumption Parameters.

   where:

   *  resumption_psk_length defaults to the key_length, i.e., the length
      of the encryption key of the EDHOC AEAD algorithm in the selected
      cipher suite of the session where the EDHOC_Exporter is invoked.

   *  id_cred_psk_length defaults to 2 bytes.

   A peer that has successfully completed an EDHOC session, regardless
   of the authentication method used or whether the session was a PSK
   resumption, MUST generate a resumption key for the next resumption
   within the current "session series", provided that PSK resumption is
   supported.

   To ensure both peers share the same resumption key, when a resumption
   session is run using rPSK_i as the resumption key:

   *  The Responder MAY delete the previous resumption key rPSK_(i-1),
      if present, after successfully verifying message_3.  At that point
      the Responder can be certain that the Initiator has access to the
      current resumption key rPSK_i.




Lopez-Perez, et al.       Expires 23 April 2026                [Page 13]

Internet-Draft                  EDHOC-PSK                   October 2025


   *  The Initiator MAY delete rPSK_i after successfully verifying the
      fourth message.  At that point, the Initiator can be certain that
      the Responder already has derived the next resumption key,
      rPSK_(i+1).

   *  The Responder MAY delete rPSK_i after successfully verifying a
      fifth message from the Initiator protected with an exported
      application key such as an OSCORE message, if present.  At that
      point, the Initiator can be certain that the Responder already has
      derived the next resumption key, rPSK_(i+1).

6.1.  Cipher Suite Requirements for Resumption

   When using a resumption PSK derived from a previous EDHOC exchange:

   1.  The resumption PSK MUST only be used with the same cipher suite
       from which it was derived, or with a cipher suite that provides
       stronger security guarantees.

   2.  Implementations MUST maintain a mapping between each resumption
       PSK and its originating cipher suite to enforce this requirement.

   3.  If a resumption PSK is offered with a cipher suite that provides
       weaker security, the Responder MUST reject the ongoing EDHOC
       session.

6.2.  Privacy Considerations for Resumption

   When using resumption PSKs:

   *  ID_CRED_PSK is not exposed to passive attackers, and under normal
      operation it is not reused.  Reuse of the same ID_CRED_PSK can
      occur due to transmission errors or when a peer loses its stored
      resumption key.  An active attacker can obtain the value of
      ID_CRED_PSK and force its reuse.  This aligns with the security
      goals of EDHOC-PSK, which are to provide identity protection
      against passive attackers, but not against active attackers.

6.3.  Security Considerations for Resumption

   *  Resumption PSKs MUST NOT be used for purposes other than EDHOC
      session resumption.

   *  Resumption PSKs MUST be securely stored with the same level of
      protection as the session keys.

   *  Parties SHOULD prevent excessive reuse of the same resumption PSK.




Lopez-Perez, et al.       Expires 23 April 2026                [Page 14]

Internet-Draft                  EDHOC-PSK                   October 2025


7.  EDHOC-PSK and Extensible Authentication Protocol (EAP)

   EDHOC with PSK authentication has several important use cases within
   the Extensible Authentication Protocol (EAP).

   One use case is the resumption of a session established with the EAP
   method EAP-EDHOC [I-D.ietf-emu-eap-edhoc], regardless of the EDHOC-
   based authentication method originally used in that session.  This is
   similar to the resumption mechanism in EAP-TLS 1.3 [RFC9190].
   Resumption reduces the number of round trips and allows the EAP-EDHOC
   server to avoid database lookups that might be required during an
   initial handshake.  If the server accepts resumption, the resumed
   session is considered authenticated and securely bound to the prior
   authentication or resumption.

   The use of resumption with EAP-EDHOC is optional for the peer, but it
   is RECOMMENDED whenever a valid rPSK is available.  On the server
   side, resumption acceptance is also optional, but it is RECOMMENDED
   if the rPSK remains valid.  The server may, however, require a new
   initial handshake by refusing resumption.  It is further RECOMMENDED
   to use Network Access Identifiers (NAIs) with the same realm in the
   identity response during both the full handshake and resumption.  For
   example, the NAI @realm can safely be reused since it does not expose
   information that links a user’s resumption attempt with the original
   full handshake.

   EAP-EDHOC-PSK also provides a significant improvement over EAP-PSK
   [RFC4764], which lacks support for identity protection, cryptographic
   agility, and ephemeral key exchange, now considered essential for
   meeting current security requirements.  Without perfect forward
   secrecy, compromise of the PSK enables a passive attacker to decrypt
   both past and future sessions.  Note that PSK authentication is not
   allowed in EAP-TLS [RFC9190].

8.  EDHOC-PSK and OSCORE

   Before sending message_3 the Initiator can derive PRK_out and create
   an OSCORE-protected request.  The request payload MAY convey both an
   EDHOC message_3 and OSCORE-protected data combined together, as
   described in Section 3 of [RFC9668].

9.  Security Considerations

   The EDHOC-PSK authentication method introduces deviations from the
   initial specification of EDHOC [RFC9528].  This section analyzes the
   security implications of these changes and discusses the security
   properties of EDHOC authenticated with PSK.




Lopez-Perez, et al.       Expires 23 April 2026                [Page 15]

Internet-Draft                  EDHOC-PSK                   October 2025


9.1.  Identity Protection

   In EDHOC-PSK, the ID_CRED_PSK in message_3 is encrypted with a
   keystream derived from the ephemeral shared secret G_XY.  As a
   result, EDHOC-PSK protects both the Initiator and the Responder
   identities against passive attackers.  This contrasts with the
   asymmetric authentication methods in Section 9.1 of [RFC9528], which
   protect the Initiator’s identity against active attackers and the
   Responder’s identity against passive ones.

   However, EDHOC-PSK does not satisfy the stronger identity protection
   notion defined by Cottier and Pointcheval [Cottier-Pointcheval],
   which requires security against an active Man-in-the-Middle (MitM)
   attacker.  Under this stronger notion, an active attacker must not
   only be prevented from learning the identity but also from forcing a
   specific identity to be used in a way that allows them to later
   distinguish between the legitimate owner of a secret (the PSK) and
   any other user.  Because message_3 is sent before the key material
   used for the keystream is cryptographically bound to the
   authenticated identities, the MitM retains full control over the
   communication channel and can conduct a distinguisher attack.
   Specifically, the attacker can intercept message_3 and perform a
   chosen-plaintext attack by manipulating the ciphertext.  By observing
   the protocol's subsequent behavior, such as the Responder's failure
   to retrieve a valid PSK and aborting the session, the attacker can
   link the Initiator's identity to the specific (coerced) ID_CRED_PSK
   value, thereby breaking the strong guarantee of anonymity that would
   otherwise be expected under an active threat model.

9.2.  Mutual Authentication

   EDHOC-PSK provides mutual authentication and explicit key
   confirmation through an additional message that demonstrates
   possession of the PSK.  This may be message_4 or an application
   message (e.g., an OSCORE message) protected with a key derived from
   EDHOC.

   To mitigate reflection or Selfie attacks, the identities in CRED_I
   and CRED_R MUST be distinct.

   EDHOC-PSK does not provide Key Compromise Impersonation (KCI)
   protection.  Compromise of the long-term PSK enables an attacker to
   impersonate either the Initiator or the Responder to the other party.
   While compromise of the ephemeral Diffie-Hellman secret only affects
   the specific session in which it is used, compromise of the PSK
   allows full active impersonation in all future sessions that rely on
   the compromised key.




Lopez-Perez, et al.       Expires 23 April 2026                [Page 16]

Internet-Draft                  EDHOC-PSK                   October 2025


9.3.  Protection of External Authorization Data (EAD)

   As in [RFC9528], EDHOC-PSK ensures the confidentiality and integrity
   of External Authorization Data (EAD).  The security guarantees for
   EAD fields remain unchanged from the original EDHOC specification.

9.4.  Cryptographic strength

   EDHOC-PSK provides a minimum of 64-bit security against online brute
   force attacks and, provided the PSK has sufficient entropy, a minimum
   of 128-bit security against offline brute force attacks.  If the PSK
   entropy is lower, the effective offline security is limited by the
   entropy of the PSK.  To break 64-bit security against online brute
   force, an attacker would on average have to send 4.3 billion messages
   per second for 68 years, which is infeasible in constrained IoT radio
   technologies.  A successful forgery of the AEAD authentication tag in
   EDHOC-PSK breaks the security of all future application data derived
   from the session, while a forgery in the subsequent application
   protocol (e.g., OSCORE [RFC8613]) typically only breaks the security
   of the forged packet.

9.5.  Downgrade Protection

   Following [RFC9528], EDHOC-PSK must support cryptographic agility,
   including modularity and negotiation of preferred cryptographic
   primitives.  In message 1, the Initiator sends an ordered list of
   supported cipher suites (SUITES_I).  The Responder verifies that the
   suite selected by the Initiator is the most preferred option in
   SUITES_I that is mutually supported.  If this condition is not met,
   the Responder MUST abort the session.

9.6.  Post Quantum Considerations

   Advances in quantum computing suggest that a Cryptographically
   Relevant Quantum Computer (CRQC) may eventually be realized.  Such a
   machine would render many asymmetric algorithms, including Elliptic
   Curve Diffie-Hellman (ECDH), insecure.

   EDHOC-PSK derives authentication and session keys primarily from a
   symmetric PSK, which provides quantum resistance even when combined
   with ECDHE.  However, if a CRQC is realized, the ECDHE contribution
   degenerates to providing only randomness.  In that case, EDHOC-PSK
   with ECDHE offers neither identity protection nor Perfect Forward
   Secrecy (PFS) against quantum adversaries.  Moreover, if the PSK is
   compromised, a passive quantum attacker could decrypt both past and
   future sessions.





Lopez-Perez, et al.       Expires 23 April 2026                [Page 17]

Internet-Draft                  EDHOC-PSK                   October 2025


   By contrast, combining EDHOC-PSK with a quantum-resistant Key
   Encapsulation Mechanism (KEM), such as ML-KEM, ensures both identity
   protection and PFS even against quantum-capable attackers.  Future
   EDHOC cipher suites incorporating ML-KEM are expected to be
   registered; see [I-D.spm-lake-pqsuites].

9.7.  Confidentiality

   The primary security goal of EDHOC-PSK is to establish a shared
   secret known only to the authenticated Initiator and Responder.  The
   protocol ensures key indistinguishability by relying on the security
   of the PSK and the ephemeral key shares, making it computationally
   infeasible for an adversary to distinguish the true session secret
   from a random value.

9.8.  Independence of Session Keys

   NIST requires that an ephemeral private key be used in only one key-
   establishment transaction ([SP-800-56A], Section 5.6.3.3).  This
   requirement preserves session key independence and forward secrecy,
   and EDHOC-PSK complies with it.  By deriving the final shared secret
   from a fresh, session-specific ephemeral secret (G_XY), the protocol
   ensures that even if the PSK is compromised, an attacker is unable to
   decrypt the past sessions.  Similarly, if a session secret were to be
   compromised, future session secrets remain protected by fresh
   ephemeral keys.

   In other protocols, reuse of ephemeral keys, especially when combined
   with missing public key validation, has led to severe
   vulnerabilities, enabling attackers to recover “ephemeral” private
   keys and compromise both past and future sessions between two
   legitimate parties.  Assuming breach and minimizing the impact of
   compromise are fundamental principles of zero-trust security.

9.9.  Unified Approach and Recommendations

   For use cases where application data is transmitted, it can be sent
   together with message_3, maintaining efficiency.  In applications
   such as EAP-EDHOC [I-D.ietf-emu-eap-edhoc], where no application data
   is exchanged between Initiator and Responder, message_4 is mandatory.
   In such cases, EDHOC-PSK does not increase the total number of
   messages.  Other implementations may replace message_4 with an
   OSCORE-protected message.  In this case, the following requirement
   applies: The Initiator SHALL NOT persistently store PRK_out or
   derived application keys until successfully verifying message_4 or a
   message protected with an exported application key (e.g., an OSCORE
   message).  This ensures that key material is stored only after its
   authenticity is confirmed, thereby strengthening privacy by



Lopez-Perez, et al.       Expires 23 April 2026                [Page 18]

Internet-Draft                  EDHOC-PSK                   October 2025


   preventing premature storage of potentially compromised keys.
   Finally, the order of authentication (i.e., whether the Initiator or
   the Responder authenticates first) is not relevant in EDHOC-PSK.
   While this ordering affects privacy properties in the asymmetric
   methods of [RFC9528], it has no significant impact in EDHOC-PSK.

10.  IANA Considerations

   This document requires the following IANA actions.

10.1.  EDHOC Method Type Registry

   IANA is requested to register the following entry in the "EDHOC
   Method Type" registry under the group name "Ephemeral Diffie-Hellman
   Over COSE (EDHOC)".

       +=======+==============================+====================+
       | Value | Initiator Authentication Key | Responder          |
       |       |                              | Authentication Key |
       +=======+==============================+====================+
       | TBD4  | PSK                          | PSK                |
       +-------+------------------------------+--------------------+

            Table 1: Addition to the EDHOC Method Type Registry.

   NOTE: Suggested value: TBD4 = 4.  RFC Editor: Remove this note.

10.2.  EDHOC Exporter Label Registry

   IANA is requested to register the following entry in the "EDHOC
   Exporter Label" registry under the group name "Ephemeral Diffie-
   Hellman Over COSE (EDHOC)".

        +=======+================+===================+===========+
        | Label | Description    | Change Controller | Reference |
        +=======+================+===================+===========+
        | TBD2  | Resumption PSK | IETF              | Section 7 |
        +-------+----------------+-------------------+-----------+
        | TBD3  | Resumption kid | IETF              | Section 7 |
        +-------+----------------+-------------------+-----------+

         Table 2: Additions to the EDHOC Exporter Label Registry.

   NOTE: Suggested values: TBD2 = 2, TBD3 = 3.  RFC Editor: Remove this
   note.

11.  References




Lopez-Perez, et al.       Expires 23 April 2026                [Page 19]

Internet-Draft                  EDHOC-PSK                   October 2025


11.1.  Normative References

   [Cottier-Pointcheval]
              Cottier, B. and D. Pointcheval, "Security Analysis of
              Improved EDHOC Protocol", FPS International Symposium on
              Foundations and Practice of Security, December 2022,
              <https://doi.org/10.1007/978-3-031-30122-3_1>.

   [I-D.ietf-emu-eap-edhoc]
              Garcia-Carrillo, D., Marin-Lopez, R., Selander, G.,
              Mattsson, J. P., and F. Lopez-Gomez, "Using the Extensible
              Authentication Protocol (EAP) with Ephemeral Diffie-
              Hellman over COSE (EDHOC)", Work in Progress, Internet-
              Draft, draft-ietf-emu-eap-edhoc-06, 15 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-
              edhoc-06>.

   [I-D.spm-lake-pqsuites]
              Selander, G. and J. P. Mattsson, "Quantum-Resistant Cipher
              Suites for EDHOC", Work in Progress, Internet-Draft,
              draft-spm-lake-pqsuites-00, 6 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-spm-lake-
              pqsuites-00>.

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

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

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

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

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/rfc/rfc8613>.




Lopez-Perez, et al.       Expires 23 April 2026                [Page 20]

Internet-Draft                  EDHOC-PSK                   October 2025


   [RFC8742]  Bormann, C., "Concise Binary Object Representation (CBOR)
              Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8742>.

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

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

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

   [RFC9668]  Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
              G. Selander, "Using Ephemeral Diffie-Hellman Over COSE
              (EDHOC) with the Constrained Application Protocol (CoAP)
              and Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 9668, DOI 10.17487/RFC9668, November 2024,
              <https://www.rfc-editor.org/rfc/rfc9668>.

   [SP-800-56A]
              Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
              Davis, "Recommendation for Pair-Wise Key-Establishment
              Schemes Using Discrete Logarithm Cryptography",
              NIST Special Publication 800-56A Revision 3, April 2018,
              <https://doi.org/10.6028/NIST.SP.800-56Ar3>.

11.2.  Informative References

   [RFC4764]  Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
              Pre-Shared Key Extensible Authentication Protocol (EAP)
              Method", RFC 4764, DOI 10.17487/RFC4764, January 2007,
              <https://www.rfc-editor.org/rfc/rfc4764>.

   [RFC9190]  Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
              Extensible Authentication Protocol with TLS 1.3",
              RFC 9190, DOI 10.17487/RFC9190, February 2022,
              <https://www.rfc-editor.org/rfc/rfc9190>.



Lopez-Perez, et al.       Expires 23 April 2026                [Page 21]

Internet-Draft                  EDHOC-PSK                   October 2025


Appendix A.  CDDL Definitions

   This section compiles the CDDL definitions for convenience,
   incorporating errata filed against [RFC9528].

   suites = [ 2* int ] / int

   ead = (
     ead_label : int,
     ? ead_value : bstr,
   )

   EAD_1 = (1* ead)
   EAD_2 = (1* ead)
   EAD_3 = (1* ead)
   EAD_4 = (1* ead)

   message_1 = (
     METHOD : int,
     SUITES_I : suites,
     G_X : bstr,
     C_I : bstr / -24..23,
     ? EAD_1,
   )

   message_2 = (
     G_Y_CIPHERTEXT_2 : bstr,
   )

   PLAINTEXT_2A = (
     C_R : bstr / -24..23,
     ? EAD_2,
   )

   message_3 = (
     CIPHERTEXT_3 : bstr,
   )

   PLAINTEXT_3A = (
     ID_CRED_PSK : header_map / bstr / -24..23,
     CIPHERTEXT_3B : bstr,
   )

   PLAINTEXT_3B = (
     ? EAD_3
   )

   message_4 = (



Lopez-Perez, et al.       Expires 23 April 2026                [Page 22]

Internet-Draft                  EDHOC-PSK                   October 2025


     CIPHERTEXT_4 : bstr,
   )

   PLAINTEXT_4 = (
     ? EAD_4,
   )

   error = (
     ERR_CODE : int,
     ERR_INFO : any,
   )

   info = (
     info_label : int,
     context : bstr,
     length : uint,
   )

Appendix B.  Test Vectors

B.1.  message_1

   Both endpoints are authenticated with Pre-Shared Keys (METHOD = 4)

   NOTE: Assuming TBD4 = 4, to be confirmed by IANA.  RFC Editor: Remove
   this note.

   METHOD (CBOR Data Item) (1 byte)
   04

   The initiator selects cipher suite 02.  A single cipher suite is
   encoded as an int:

   SUITES_I (CBOR Data Item) (1 byte)
   02

   The Initiator creates an ephemeral key pair for use with the EDHOC
   key exchange algorithm:

   Initiator's ephemeral private key
   X (Raw Value) (32 bytes)
   09 97 2D FE F1 EA AB 92 6E C9 6E 80 05 FE D2 9F
   70 FF BF 4E 36 1C 3A 06 1A 7A CD B5 17 0C 10 E5

   Initiator's ephemeral public key
   G_X (Raw Value) (32 bytes)
   7E C6 81 02 94 06 02 AA B5 48 53 9B F4 2A 35 99
   2D 95 72 49 EB 7F 18 88 40 6D 17 8A 04 C9 12 DB



Lopez-Perez, et al.       Expires 23 April 2026                [Page 23]

Internet-Draft                  EDHOC-PSK                   October 2025


   The Initiator selects its connection identifier C_I to be the byte
   string 0xA, which is encoded as 0xA since it is represented by the
   1-byte CBOR int 10:

   Connection identifier chosen by the Initiator
   C_I (CBOR Data Item) (1 byte)
   0A

   No external authorization data

   EAD_1 (CBOR Sequence) (0 bytes)

   The Initiator constructs message_1:

   message_1 (CBOR Sequence) (37 bytes)
   04 02 58 20 7E C6 81 02 94 06 02 AA B5 48 53 9B
   F4 2A 35 99 2D 95 72 49 EB 7F 18 88 40 6D 17 8A
   04 C9 12 DB 0A

B.2.  message_2

   The Responder supports the most preferred and selected cipher suite
   02, so SUITES_I is acceptable.

   The Responder creates an ephemeral key pair for use with the EDHOC
   key exchange algorithm:

   Responder's ephemeral private key
   Y (Raw Value) (32 bytes)
   1E 1C 8F 2D F1 AA 71 10 B3 9F 33 BA 5E A8 DC CF
   31 41 1E B3 3D 4F 9A 09 4C F6 51 92 D3 35 A7 A3

   Responder's ephemeral public key
   G_Y (Raw Value) (32 bytes)
   ED 15 6A 62 43 E0 AF EC 9E FB AA BC E8 42 9D 5A
   D5 E4 E1 C4 32 F7 6A 6E DE 8F 79 24 7B B9 7D 83

   The Responder selects its connection identifier C_R to be the byte
   string 0x05, which is encoded as 0x05 since it is represented by the
   1-byte CBOR int 05:

   Connection identifier chosen by the Responder
   C_R (CBOR Data Item) (1 byte)
   05

   The transcript hash TH_2 is calculated using the EDHOC hash
   algorithm: TH_2 = H( G_Y, H(message_1) ), where H(message_1) is:




Lopez-Perez, et al.       Expires 23 April 2026                [Page 24]

Internet-Draft                  EDHOC-PSK                   October 2025


   H(message_1) (Raw Value) (32 bytes)
   19 CC 2D 2A 95 7E DD 80 10 90 42 FD E6 CC 20 C2
   4B 6A 34 BC 21 C6 D4 9F EA 89 5D 4C 75 92 34 0E

   H(message_1) (CBOR Data Item) (34 bytes)
   58 20 19 CC 2D 2A 95 7E DD 80 10 90 42 FD E6 CC 20
   C2 4B 6A 34 BC 21 C6 D4 9F EA 89 5D 4C 75 92 34 0E

   TH_2 (Raw Value) (32 bytes)
   5B 48 34 AE 63 0A 8A 0E D0 B0 C6 F3 66 42 60 4D
   01 64 78 C4 BC 81 87 BB 76 4D D4 0F 2B EE 3D DE

   TH_2 (CBOR Data Item) (34 bytes)
   58 20 5B 48 34 AE 63 0A 8A 0E D0 B0 C6 F3 66 42 60
   4D 01 64 78 C4 BC 81 87 BB 76 4D D4 0F 2B EE 3D DE

   PRK_2e is specified in Section 4.1.2 of [RFC9528].  To compute it,
   the Elliptic Curve Diffie-Hellman (ECDH) shared secret G_XY is
   needed.  It is computed from G_X and Y or G_Y and X:

   G_XY (Raw Value) (ECDH shared secret) (32 bytes)
   2F 4A 79 9A 5A B0 C5 67 22 0C B6 72 08 E6 CF 8F
   4C A5 FE 38 5D 1B 11 FD 9A 57 3D 41 60 F3 B0 B2

   Then, PRK_2e is calculated as defined in Section 4.1.2 of [RFC9528]

   PRK_2e (Raw Value) (32 bytes)
   D0 39 D6 C3 CF 35 EC A0 CD F8 19 E3 25 79 C7 7E
   1F 30 3E FC C4 36 20 50 99 48 A9 FD 47 FB D9 29

   Since the Responder authenticates using PSK, PRK_3e2m = PRK_2e.

   PRK_3e2m (Raw Value) (32 bytes)
   D0 39 D6 C3 CF 35 EC A0 CD F8 19 E3 25 79 C7 7E
   1F 30 3E FC C4 36 20 50 99 48 A9 FD 47 FB D9 29

   No external authorization data:

   EAD_2 (CBOR Sequence) (0 bytes)

   The Responder constructs PLAINTEXT_2A:

   PLAINTEXT_2A (CBOR Sequence) (1 byte)
   05

   The Responder computes KEYSTREAM_2 as defined in Section 4.1.2 of
   [RFC9528]




Lopez-Perez, et al.       Expires 23 April 2026                [Page 25]

Internet-Draft                  EDHOC-PSK                   October 2025


   KEYSTREAM_2A (Raw Value) (1 byte)
   EC

   The Responder calculates CIPHERTEXT_2B as XOR between PLAINTEXT_2A
   and KEYSTREAM_2:

   CIPHERTEXT_2B (CBOR Sequence) (1 byte)
   E9

   The Responder constructs message_2 as defined in Section 5.3.1 of
   [RFC9528]:

   message_2 (CBOR Sequence) (35 bytes)
   58 21 ED 15 6A 62 43 E0 AF EC 9E FB AA BC E8 42
   9D 5A D5 E4 E1 C4 32 F7 6A 6E DE 8F 79 24 7B B9
   7D 83 E9

B.3.  message_3

   The Initiator computes PRK_4e3m, as described in Section 4, using
   SALT_4e3m and PSK:

   SALT_4e3m (Raw Value) (32 bytes)
   ED E0 76 12 14 83 19 EB 72 59 52 71 2A 54 2C 20
   97 61 0A 13 9C 4A 14 1C 8E C5 7A 5F 62 E5 E9 DD

   PSK (Raw Value) (16 bytes)
   50 93 0F F4 62 A7 7A 35 40 CF 54 63 25 DE A2 14

   PRK_4e3m (Raw Value) (32 bytes)
   C6 2C C0 4F 55 D0 08 CF EB 8A 68 1E 84 63 FD DD
   A2 FF 6C A8 4B 9E D6 11 6C 86 5C D8 1E 06 24 60

   The transcript hash TH_3 is calculated using the EDHOC hash
   algorithm:

   TH_3 = H( TH_2, PLAINTEXT_2A )

   TH_3 (Raw Value) (32 bytes)
   38 6A 9D 05 2B 25 59 92 EE E5 FF B5 94 34 7D 32
   74 18 A2 EA 51 83 48 6C 0C 9E 20 42 6E 0B CA 2F

   TH_3 (CBOR Data Item) (34 bytes)
   58 20 38 6A 9D 05 2B 25 59 92 EE E5 FF B5 94 34 7D
   32 74 18 A2 EA 51 83 48 6C 0C 9E 20 42 6E 0B CA 2F

   No external authorization data:




Lopez-Perez, et al.       Expires 23 April 2026                [Page 26]

Internet-Draft                  EDHOC-PSK                   October 2025


   EAD_3 (CBOR Sequence) (0 bytes)

   The Initiator constructs firstly PLAINTEXT_3B as defined in
   Section 5.3.1.:

   PLAINTEXT_3B (CBOR Sequence) (0 bytes)

   It then computes CIPHERTEXT_3B as defined in Section 5.3.2.  It uses
   ID_CRED_PSK, CRED_I, CRED_R and TH_3 as external_aad:

   ID_CRED_PSK (CBOR Data Item) (1 byte)
   10

   CRED_I (Raw Value) (38 bytes)
   A2 02 69 69 6E 69 74 69 61 74 6F 72 08 A1 01 A3
   01 04 02 41 10 20 50 50 93 0F F4 62 A7 7A 35 40
   CF 54 63 25 DE A2 14

   CRED_R (Raw Value) (38 bytes)
   A2 02 69 72 65 73 70 6F 6E 64 65 72 08 A1 01 A3
   01 04 02 41 10 20 50 50 93 0F F4 62 A7 7A 35 40
   CF 54 63 25 DE A2 14

   TH_3 (Raw Value) (32 bytes)
   38 6A 9D 05 2B 25 59 92 EE E5 FF B5 94 34 7D 32
   74 18 A2 EA 51 83 48 6C 0C 9E 20 42 6E 0B CA 2F

   The Initiator computes K_3 and IV_3

   K_3 (Raw Value) (16 bytes)
   96 6A 57 9C EA 26 CA 3C EB 44 2A C7 27 EA B2 32

   IV_3 (Raw Value) (13 bytes)
   5B F1 AD 0E 4F FB 96 76 D7 8D F2 3F 6E

   It then computes CIPHERTEXT_3B:

   CIPHERTEXT_3B (CBOR Sequence) (9 bytes)
   48 04 88 B7 F2 A6 66 B6 29

   The Initiator computes KEYSTREAM_3A as defined in Section 4:

   KEYSTREAM_3A (Raw Value) (10 bytes)
   03 E5 D1 57 1B BC 93 32 47 1B

   It then calculates PLAINTEXT_3A as stated in Section 5.3.2.:





Lopez-Perez, et al.       Expires 23 April 2026                [Page 27]

Internet-Draft                  EDHOC-PSK                   October 2025


   PLAINTEXT_3A (CBOR Sequence) (10 bytes)
   10 48 04 88 B7 F2 A6 66 B6 29

   It then uses KEYSTREAM_3A to derive CIPHERTEXT_3A:

   CIPHERTEXT_3A (CBOR Sequence) (10 bytes)
   13 AD D5 DF AC 4E 35 54 F1 32

   The Initiator computes message_3 as defined in Section 5.3.2.:

   message_3 (CBOR Sequence) (11 bytes)
   4A 13 AD D5 DF AC 4E 35 54 F1 32

   The transcript hash TH_4 is calculated using the EDHOC hash
   algorithm: TH_4 = H( TH_3, ID_CRED_PSK, ? EAD_3, CRED_I, CRED_R )

   TH_4 (Raw Value) (32 bytes)
   11 48 1B 9A FE F9 5C 67 9A 52 03 82 17 EE DD 0E
   0C E0 8F AA 86 5B DC 82 55 11 CA 6D C3 91 94 13

   TH_4 (CBOR Data Item) (34 bytes)
   58 20 11 48 1B 9A FE F9 5C 67 9A 52 03 82 17 EE DD
   0E 0C E0 8F AA 86 5B DC 82 55 11 CA 6D C3 91 94 13

B.4.  message_4

   No external authorization data:

   EAD_4 (CBOR Sequence) (0 bytes)

   The Responder constructs PLAINTEXT_4:

   PLAINTEXT_4 (CBOR Sequence) (0 bytes)

   The Responder computes K_4 and IV_4:

   K_4 (Raw Value) (16 bytes)
   BC AB 1D F0 13 8D C0 5C 88 5F D3 71 E9 50 C6 7F

   IV_4 (Raw Value) (13 bytes)
   41 11 34 D0 E0 C5 08 D9 5D A7 C3 AC DC

   The Responder computes message_4:

   message_4 (CBOR Sequence) (9 bytes)
   48 8A DD 93 DB 40 48 59 F9





Lopez-Perez, et al.       Expires 23 April 2026                [Page 28]

Internet-Draft                  EDHOC-PSK                   October 2025


B.5.  PRK_out and PRK_exporter

   After the exchange, the following PRK_out and PRK_exporter are
   derived by both entities:

   PRK_out (Raw Value) (32 bytes)
   BB A6 DE D3 B0 38 D2 32 37 74 D8 92 14 A5 13 A2
   49 16 F0 42 29 6C 7C 72 9C D1 A6 7B 43 6F B4 14

   PRK_exporter (Raw Value) (32 bytes)
   2F CD 08 C0 C0 10 77 C6 D6 48 6B 9F 9B 67 70 20
   E8 D6 8F 04 BC DC CE 71 5D D2 77 ED 25 93 1B EF

B.6.  rPSK and rKID

   Both peers generate a resumption key for use in the next resumption
   attempt, as explained in Section 6:

   rPSK (Raw Value) (16 bytes)
   5B 0B C7 63 F6 EA D1 7E 0E EA ED FD D3 36 A5 EE

   rKID (Raw Value) (1 byte)
   55

Appendix C.  Change Log

   RFC Editor: Please remove this appendix.

   *  From -04 to -05

      -  Fixed misbinding attacks and resumption

      -  Updated privacy considerations

      -  Added EDHOC-PSK and EAP section

      -  Editorial changes

      -  Fixed test vectors

   *  From -03 to -04

      -  Test Vectors

      -  Editorial changes

   *  From -02 to -03




Lopez-Perez, et al.       Expires 23 April 2026                [Page 29]

Internet-Draft                  EDHOC-PSK                   October 2025


      -  Updated abstract and Introduction

      -  Changed message_3 to hide the identity length from passive
         attackers

      -  CDDL Definitions

      -  Security considerations of independence of Session Keys

      -  Editorial changes

   *  From -01 to -02

      -  Changes to message_3 formatting and processing

   *  From -00 to -01

      -  Editorial changes and corrections

Acknowledgments

   The authors want to thank Christian Amsüss, Scott Fluhrer, Charlie
   Jacomme, and Marco Tiloca for reviewing and commenting on
   intermediate versions of the draft.

   This work has been partly funded by PID2023-148104OB-C43 funded by
   MICIU/AEI/10.13039/501100011033 (ONOFRE4), FEDER/UE EU HE CASTOR
   under Grant Agreement No 101167904 and EU CERTIFY under Grant
   Agreement No 101069471.

   This work was supported partially by Vinnova - the Swedish Agency for
   Innovation Systems - through the EUREKA CELTIC-NEXT project CYPRESS.

   This work has been partially supported by the French National
   Research Agency under the France 2030 label (NF-HiSec ANR-22-PEFT-
   0009)

Authors' Addresses

   Elsa Lopez-Perez
   Inria
   Email: elsa.lopez-perez@inria.fr


   Göran Selander
   Ericsson
   Email: goran.selander@ericsson.com




Lopez-Perez, et al.       Expires 23 April 2026                [Page 30]

Internet-Draft                  EDHOC-PSK                   October 2025


   John Preuß Mattsson
   Ericsson
   Email: john.mattsson@ericsson.com


   Rafael Marin-Lopez
   University of Murcia
   Email: rafa@um.es


   Francisco Lopez-Gomez
   University of Murcia
   Email: francisco.lopezg@um.es






































Lopez-Perez, et al.       Expires 23 April 2026                [Page 31]


name: draft-yusef-lamps-rfc7030-renewal-recommendation
rev: 03
title: Certificate Renewal Recommendations for Enrollment over Secure Transport
time: 2026-01-24T17:16:47Z
group_uri: /api/v1/group/group/2164/
expires: 2026-04-06T17:46:09Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/36/"]
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014867+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: 6 April 2026                           Sandelman Software Works
                                                            M. Ounsworth
                                                         Entrust Limited
                                                          3 October 2025


Certificate Renewal Recommendations for Enrollment over Secure Transport
          draft-yusef-lamps-rfc7030-renewal-recommendation-03

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-yusef-lamps-rfc7030-renewal-
   recommendation/.

   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/mcr/rfc7030-renewal-recommendation.

Status of This Memo

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







Shekh-Yusef, et al.       Expires 6 April 2026                  [Page 1]

Internet-Draft                  est-renew                   October 2025


   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 6 April 2026.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   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






Shekh-Yusef, et al.       Expires 6 April 2026                  [Page 2]

Internet-Draft                  est-renew                   October 2025


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.

   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:






Shekh-Yusef, et al.       Expires 6 April 2026                  [Page 3]

Internet-Draft                  est-renew                   October 2025


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

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.




Shekh-Yusef, et al.       Expires 6 April 2026                  [Page 4]

Internet-Draft                  est-renew                   October 2025


   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.

   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.







Shekh-Yusef, et al.       Expires 6 April 2026                  [Page 5]

Internet-Draft                  est-renew                   October 2025


   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]

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







Shekh-Yusef, et al.       Expires 6 April 2026                  [Page 6]

Internet-Draft                  est-renew                   October 2025


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

   [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 6 April 2026                  [Page 7]


name: draft-ietf-lamps-private-key-stmt-attr
rev: 09
title: An Attribute for Statement of Possession of a Private Key
time: 2025-10-13T03:40:45Z
group_uri: /api/v1/group/group/2164/
expires: 2025-12-28T15:45:41Z
ad: /api/v1/person/person/123703/
shepherd: /api/v1/person/email/tim.hollebeek@digicert.com/
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014873+00:00
abstract:
This document specifies an attribute for a statement of possession of
   a private key by a certificate subject.  As part of X.509 certificate
   enrollment, a Certification Authority (CA) typically demands proof
   that the subject possesses the private key that corresponds to the
   to-be-certified public key.  In some cases, a CA might accept a
   signed statement from the certificate subject.  For example, when a
   certificate subject needs separate certificates for signature and key
   establishment, a statement that can be validated with the previously
   issued signature certificate for the same subject might be adequate
   for subsequent issuance of the key establishment certificate.

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

full_text:
Network Working Group                                         R. Housley
Internet-Draft                                            Vigil Security
Intended status: Standards Track                            26 June 2025
Expires: 28 December 2025


       An Attribute for Statement of Possession of a Private Key
               draft-ietf-lamps-private-key-stmt-attr-09

Abstract

   This document specifies an attribute for a statement of possession of
   a private key by a certificate subject.  As part of X.509 certificate
   enrollment, a Certification Authority (CA) typically demands proof
   that the subject possesses the private key that corresponds to the
   to-be-certified public key.  In some cases, a CA might accept a
   signed statement from the certificate subject.  For example, when a
   certificate subject needs separate certificates for signature and key
   establishment, a statement that can be validated with the previously
   issued signature certificate for the same subject might be adequate
   for subsequent issuance of the key establishment certificate.

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 28 December 2025.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights



Housley                 Expires 28 December 2025                [Page 1]

Internet-Draft     Statement of Private Key Possession         June 2025


   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Attribute for Statement of Possession of a Private Key  . . .   4
   4.  Conventions for PKCS#10 . . . . . . . . . . . . . . . . . . .   6
   5.  Conventions for CRMF  . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .   9
   Appendix B.  Example use of the privateKeyPossessionStatement
           Attribute . . . . . . . . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  19
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   This document specifies an attribute for a statement of possession of
   a private key by a certificate subject.  X.509 certificate [RFC5280]
   enrollment often depends on PKCS#10 [RFC2986] or the Certificate
   Request Message Format (CRMF) [RFC4211].  As part of enrollment, a
   Certification Authority (CA) typically demands proof that the subject
   possesses the private key that corresponds to the to-be-certified
   public key.  Alternatively, a CA may accept a signed statement from
   the certificate subject claiming knowledge of that private key.  When
   a certificate subject needs separate certificates for signature and
   key establishment, a signed statement that can be validated with the
   previously issued signature certificate for the same subject might be
   adequate for subsequent issuance of the key establishment
   certificate.











Housley                 Expires 28 December 2025                [Page 2]

Internet-Draft     Statement of Private Key Possession         June 2025


   For example, a subject may need a signature certificate that contains
   a ML-DSA (Module-Lattice-Based Digital Signature Algorithm) public
   key and a key establishment certificate that contains a ML-KEM
   (Module-Lattice-Based Key-Encapsulation Mechanism) public key.  For
   another example, a subject may need a signature certificate that
   contains a ECDSA (Elliptic Curve Digital Signature Algorithm) public
   key and a key establishment certificate that contains a ECDH
   (Elliptic Curve Diffie-Hellman) public key.

   A statement of possession may be used in lieu of the usual proof of
   possession mechanisms.  The statement is simply a signed assertion
   that the requestor of a key establishment certificate has possession
   of the key establishment private key, and that statement is signed
   using a signature private key that was previously shown to be in the
   possession of the same certificate subject.  If allowed by the
   Certificate Policy [RFC3647], the CA is permitted to accept this
   statement in lieu of proof that the requestor has possession of the
   private key, such as [RFC6955].

   Note that [RFC6955] offers some algorithms that provide proof of
   possession for Diffie-Hellman private keys; however, these algorithms
   are not suitable for use with PKCS#10 [RFC2986].  In addition, the
   algorithms in [RFC6955] do not support key encapsulation mechanism
   algorithms, such as ML-KEM.  The attribute specified in this
   document, on the other hand, is suitable for use with both PKCS#10
   and the CRMF [RFC4211].

1.1.  ASN.1

   The attribute defined in this document is generated using ASN.1
   [X680], using the Distinguished Encoding Rules (DER) [X690].

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

2.  Overview

   When using the attribute defined in this document to make a statement
   about the possession of the key establishment private key, the
   process to obtain two certificates with PKCS#10 is:

   1.  The subject generates the signature key pair.




Housley                 Expires 28 December 2025                [Page 3]

Internet-Draft     Statement of Private Key Possession         June 2025


   2.  The subject composes a PKCS#10 Certificate Signing Request (CSR)
       in the usual manner.  It includes a signature that is produced
       with the private key from step 1.

   3.  The subject sends the CSR to the CA, and it gets back a signature
       certificate.  The signature certificate includes a key usage of
       digitalSignature, nonRepudiation, or both (see Section 4.2.1.3 of
       [RFC5280]).

   4.  The subject generates the key establishment key pair.

   5.  The subject composes a PKCS#10 CSR containing the key
       establishment public key.  The CSR attributes include the
       attribute specified in Section 3 of this document.  The subject
       name matches the one from step 3.  The CSR includes a signature
       that is produced with the private key from step 1.

   6.  The subject sends the CSR to the CA, and it gets back a key
       establishment certificate.  The key establishment certificate
       includes a key usage of keyEncipherment or keyAgreement (see
       Section 4.2.1.3 of [RFC5280]).

   In general, the issuer of the key establishment certificate will be
   the same as the issuer of the signature certificate.  If the issuers
   of the two certificates will be different, then the certificate
   policy of the issuer of the key establishment certificate MUST
   explain the procedure that is used to verify the subject and subject
   alternative names.

3.  Attribute for Statement of Possession of a Private Key

   The attribute for statement of possession of a private key is
   included in a certificate request to make the following statement:

      The subject of the signature certificate that is used to validate
      the signature on this certificate request states, without
      providing proof, that it has possession of the private key that
      corresponds to the public key in the certificate request.

   The CA MUST perform certification path validation for the signature
   certificate as specified in Section 6 of [RFC5280].  If the
   certification path is not valid, then the CA MUST reject the request
   for the key establishment certificate.

   The CA MUST validate the signature on the certificate request using
   the public key from the signature certificate.  If the signature is
   not valid, then the CA MUST reject the certificate request.




Housley                 Expires 28 December 2025                [Page 4]

Internet-Draft     Statement of Private Key Possession         June 2025


   The subject in the signature certificate SHOULD be the same as the
   subject name in the certificate request.  If they are different, the
   certificate policy MUST describe how the CA can determine that the
   two subject names identify the same entity.  If the CA is unable to
   determine that the two subject names identify the same entity, then
   the CA MUST reject the certificate request.

   If subject alternative names are present in the certificate request,
   they SHOULD match subject alternative names in the signature
   certificate.  If they are different, the certificate policy MUST
   describe how the CA can determine that the two subject alternative
   names identify the same entity.  If the CA is unable to determine
   that each of subject alternative names identifies the same entity as
   is named in the signature certificate, then the CA MUST reject the
   certificate request.

   When the CA rejects a certificate request for any of the reasons
   listed above, the CA should provide information to the requester
   about the reason for the rejection to aid with diagnostic efforts.
   Likewise, the CA should log the rejection events.

   The attribute for statement of possession of a private key has the
   following structure:

      id-at-statementOfPossession OBJECT IDENTIFIER ::=
        { 1 3 6 1 4 1 22112 2 1 }

      privateKeyPossessionStatement ATTRIBUTE ::= {
        TYPE PrivateKeyPossessionStatement
        IDENTIFIED BY id-at-statementOfPossession }

      PrivateKeyPossessionStatement ::= SEQUENCE {
        signer  IssuerAndSerialNumber,
        cert    Certificate OPTIONAL }

   The components of the PrivateKeyStatement SEQUENCE have the following
   semantics:

      signer:  the issuer name and certificate serial number of the
         signature certificate.

      cert:  the signature certificate.  If the issuer of the key
         establishment certificate will be the same as the issuer of the
         signature certificate, then this component MAY be omitted.
         When the signature certificate is omitted, the signer is
         assuming that the CA has a mechanism to obtain all valid
         certificates that it issued.




Housley                 Expires 28 December 2025                [Page 5]

Internet-Draft     Statement of Private Key Possession         June 2025


4.  Conventions for PKCS#10

   This section specifies the conventions for using the attribute for
   statement of possession of a private key with PKCS#10 [RFC2986] when
   requesting a key establishment certificate.

   The PKCS#10 CertificationRequest always has three components, as
   follows:

      certificationRequestInfo:  the subject name SHOULD be the same as
         the subject name in the signature certificate, the
         subjectPKInfo MUST contain the public key for the key
         establishment algorithm, and the attributes MUST include
         privateKeyPossessionStatement attribute as specified in
         Section 3 of this document.

      signatureAlgorithm:  the signature algorithm MUST be one that can
         be validated with the public key in the signature certificate.

      signature:  the signature over certificationRequestInfo MUST
         validate with the public key in the signature certificate, and
         certification path validation for the signature certificate
         MUST be successful as specified in Section 6 of [RFC5280].

5.  Conventions for CRMF

   This section specifies the conventions for using the attribute for
   statement of possession of a private key with the CRMF [RFC4211] when
   requesting a key establishment certificate.

   The following ASN.1 types are defined for use with CRMF.  They have
   exactly the same semantics and syntax as the attribute discussed
   above, but they offer a similar naming convention to the Registration
   Controls in [RFC4211].

     regCtrl-privateKeyPossessionStatement ATTRIBUTE ::=
       privateKeyPossessionStatement

     id-regCtrl-statementOfPossession OBJECT IDENTIFIER ::=
       id-at-statementOfPossession

   The CRMF CertificationRequest always has three components, as
   follows:

      certReq:  the certTemplate MUST include the subject and the
         publicKey components.  The same subject name SHOULD match the
         subject name in the signature certificate, and publicKey MUST
         contain the public key for the key establishment algorithm.



Housley                 Expires 28 December 2025                [Page 6]

Internet-Draft     Statement of Private Key Possession         June 2025


      popo:  the ProofOfPossession MUST use the signature CHOICE, the
         poposkInput MUST be present, POPOSigningKeyInput.authInfo MUST
         use the sender CHOICE, the sender SHOULD be set to the subject
         name that appears in the signature certificate, the publicKey
         MUST contain a copy of the public key from the certTemplate,
         the algorithmIdentifier MUST identify a signature algorithm
         that can be validated with the public key in the signature
         certificate, signature over the poposkInput MUST validate with
         the public key in the signature certificate, and certification
         path validation for the signature certificate MUST be
         successful as specified in Section 6 of [RFC5280].

      regInfo:  the attributes MUST include
         privateKeyPossessionStatement attribute as specified in
         Section 3 of this document.

6.  Security Considerations

   The privateKeyPossessionStatement attribute MUST NOT be used to
   obtain a signature certificate.  Performing proof of possession of
   the signature private key is easily accomplished by signing the
   certificate request.

   The subject is signing privateKeyPossessionStatement attribute to
   tell the CA that it has possession of the key establishment private
   key.  This is being done instead of providing technical proof of
   possession.  If the subject has lost control of the signature private
   key, then the signed privateKeyPossessionStatement attribute could be
   generated by some other party.  Timely revocation of the compromised
   signature certificate is the only protection against such loss of
   control.

   If the CA revokes a compromised signature certificate, then the CA
   SHOULD also revoke all key establishment certificates that were
   obtained with privateKeyPossessionStatement attributes signed by that
   compromised signature certificate.

   The signature key pair and the key establishment key pair are
   expected to have roughly the same security strength.  To ensure that
   the signature on the statement is not the weakest part of the
   certificate enrollment, the signature key pair SHOULD be at least as
   strong as the key establishment key pair.

   If a CA allows subject in the key establishment certificate to be
   different than the subject name in the signature certificate, then
   certificate policy MUST describe how to determine that the two
   subject names identify the same entity.  Likewise, if a CA allows
   subject alternative names in the key establishment certificate that



Housley                 Expires 28 December 2025                [Page 7]

Internet-Draft     Statement of Private Key Possession         June 2025


   are not present in the signature certificate, then certificate policy
   MUST describe how to determine that the subject alternative names
   identify the same entity as is named in the signature certificate.

7.  IANA Considerations

   For the ASN.1 Module in the Appendix A of this document, IANA is
   requested to assign an object identifier (OID) for the module
   identifier (TBD0) with a Description of "id-mod-private-key-
   possession-stmt-2025".  The OID for the module should be allocated in
   the "SMI Security for PKIX Module Identifier" registry
   (1.3.6.1.5.5.7.0).

8.  References

8.1.  Normative References

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

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

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

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

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

   [RFC6268]  Schaad, J. and S. Turner, "Additional New ASN.1 Modules
              for the Cryptographic Message Syntax (CMS) and the Public
              Key Infrastructure Using X.509 (PKIX)", RFC 6268,
              DOI 10.17487/RFC6268, July 2011,
              <https://www.rfc-editor.org/rfc/rfc6268>.



Housley                 Expires 28 December 2025                [Page 8]

Internet-Draft     Statement of Private Key Possession         June 2025


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

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

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

8.2.  Informative References

   [RFC3647]  Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
              Wu, "Internet X.509 Public Key Infrastructure Certificate
              Policy and Certification Practices Framework", RFC 3647,
              DOI 10.17487/RFC3647, November 2003,
              <https://www.rfc-editor.org/rfc/rfc3647>.

   [RFC6955]  Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
              of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
              May 2013, <https://www.rfc-editor.org/rfc/rfc6955>.

Appendix A.  ASN.1 Module

   This ASN.1 Module uses the conventions established by [RFC5912] and
   [RFC6268].

   <CODE BEGINS>
   PrivateKeyPossessionStatement-2025
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-private-key-possession-stmt-2025(TBD0) }

   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   EXPORTS ALL;

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



Housley                 Expires 28 December 2025                [Page 9]

Internet-Draft     Statement of Private Key Possession         June 2025


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

     IssuerAndSerialNumber
     FROM CryptographicMessageSyntax-2010 -- [RFC6268]
       { iso(1) member-body(2) us(840) rsadsi(113549)
          pkcs(1) pkcs-9(9) smime(16) modules(0)
          id-mod-cms-2009(58) } ;

   --
   -- Private Key Possession Statement Attribute
   --

   id-at-statementOfPossession OBJECT IDENTIFIER ::=
     { 1 3 6 1 4 1 22112 2 1 }

   privateKeyPossessionStatement ATTRIBUTE ::= {
     TYPE PrivateKeyPossessionStatement
     IDENTIFIED BY id-at-statementOfPossession }

   PrivateKeyPossessionStatement ::= SEQUENCE {
     signer  IssuerAndSerialNumber,
     cert    Certificate OPTIONAL }

   --
   -- Registration Control Support
   --

   RegControlSet ATTRIBUTE ::=
     { regCtrl-privateKeyPossessionStatement, ... }

   regCtrl-privateKeyPossessionStatement ATTRIBUTE ::=
     privateKeyPossessionStatement

   id-regCtrl-statementOfPossession OBJECT IDENTIFIER ::=
     id-at-statementOfPossession

   END
   <CODE ENDS>

Appendix B.  Example use of the privateKeyPossessionStatement Attribute

   In this example, the self-signed certificate for the CA is:





Housley                 Expires 28 December 2025               [Page 10]

Internet-Draft     Statement of Private Key Possession         June 2025


   -----BEGIN CERTIFICATE-----
   MIIB7DCCAXKgAwIBAgIUL149AUxHunELBZMELEQm+isgKCQwCgYIKoZIzj0EAwMw
   NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh
   LmV4YW1wbGUwHhcNMjUwMTAzMjAyNzA5WhcNMzUwMTAzMjAyNzA5WjA3MQswCQYD
   VQQGEwJVUzETMBEGA1UEChMKRXhhbXBsZSBDQTETMBEGA1UEAxMKY2EuZXhhbXBs
   ZTB2MBAGByqGSM49AgEGBSuBBAAiA2IABDxZdB/Glcxdk1p6Jf1j5en6QfliY9OS
   fjZbtje/w6M58PN8Sb3VFln1rPdvD17UXeazSG9Hr/Dq3enbsHHO0pPntcFOgb8n
   r8R8LUGhxRzjlxkaEJN+pa6Nf7qk49JDeaM/MD0wDwYDVR0TAQH/BAUwAwEB/zAL
   BgNVHQ8EBAMCAgQwHQYDVR0OBBYEFD6YvLLv3DQbvnGS0qP6bbzyZkCqMAoGCCqG
   SM49BAMDA2gAMGUCMGfb61IigoJ3QDnlsRdoktREHe0Dpm6DKw3qOyLL6A0cFK9Z
   g8m11xIwvptlran52gIxAK1VrOjzRsFiHRptO+gFXstTXnQkKBb2/3WQz2SqcIS/
   BWEp+siJ19OXOlz6APDB7w==
   -----END CERTIFICATE-----

   Alice generates her ECDSA signature key pair.  Then, Alice composes a
   PKCS#10 Certificate Signing Request (CSR) in the usual manner as
   specified in [RFC2986].  The CSR includes a signature that is
   produced with her ECDSA private key.  The CSR is:

   -----BEGIN CERTIFICATE REQUEST-----
   MIIBhTCCAQsCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH
   EwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB2MBAGByqGSM49AgEGBSuBBAAiA2IA
   BIAc+6lXN1MIM/82QeWNb55H0zr+lVgWVeF0bf4jzxCb5MCjVaM0eFEvcjXMV5p4
   kzqiJTHC0V2JAoqYMX/DMFIcwZ7xP9uQd9ep6KZ+RXut211L8+W1QI1QJSDNxANR
   saBQME4GCSqGSIb3DQEJDjFBMD8wDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCB4Aw
   IgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wCgYIKoZIzj0EAwMD
   aAAwZQIwPa2rOCe60edAF43C/t57IW8liyy+69FE04hMAFgw3Ga+nR+8zDuUsVLw
   xXGAHtcDAjEA6LbvNkZjo6j2z5xRIjrHzEbGgiV4MF4xtnpfSSRI4dB0zT52bWkj
   TZsuS1YWIkjt
   -----END CERTIFICATE REQUEST-----

   The CA issues a signature certificate to Alice:

   -----BEGIN CERTIFICATE-----
   MIICJzCCAa6gAwIBAgIUf3Sj/ANs4hR4XFlhTm+N8kxHqHkwCgYIKoZIzj0EAwMw
   NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh
   LmV4YW1wbGUwHhcNMjUwMTA5MTcwMzQ4WhcNMjYwMTA5MTcwMzQ4WjA8MQswCQYD
   VQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNVBAcTB0hlcm5kb24xDjAMBgNVBAMT
   BUFsaWNlMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEgBz7qVc3Uwgz/zZB5Y1vnkfT
   Ov6VWBZV4XRt/iPPEJvkwKNVozR4US9yNcxXmniTOqIlMcLRXYkCipgxf8MwUhzB
   nvE/25B316nopn5Fe63bXUvz5bVAjVAlIM3EA1Gxo3YwdDAMBgNVHRMBAf8EAjAA
   MAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A0f7tCzkQEZgYzH3NcM2L05IwHwYD
   VR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJmQKowFwYDVR0gBBAwDjAMBgpghkgB
   ZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/Uypd7BaVnUjB36UtX9m5ZmPi78y5
   1RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIwRJ6U91048NAb3nicHcrGFf1UYrhb
   DlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u
   -----END CERTIFICATE-----




Housley                 Expires 28 December 2025               [Page 11]

Internet-Draft     Statement of Private Key Possession         June 2025


   Alice generates her ECDH key establishment key pair.  Then, Alice
   composes a PKCS#10 CSR.  The CSR attributes include the
   privateKeyPossessionStatement attribute, which points to her ECDSA
   signature certificate.  The CSR includes her ECDH public key and a
   signature that is produced with her ECDSA private key.  The CSR is:

   -----BEGIN CERTIFICATE REQUEST-----
   MIIEMTCCA7gCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH
   EwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB0MA4GBSuBBAEMBgUrgQQAIgNiAAQB
   RyQTH+cq1s5F94uFqFe7l1LqGdEC8Tm+e5VYBCfKAC8MJySQMj1GixEEXL+1Wjtg
   23XvnJouCDoxSpDCSMqf3kvp5+naM37uxa3ZYgD6DPY3me5EZvyZPvSRJTFl/Bag
   ggL9MGcGCSqGSIb3DQEJDjFaMFgwDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCAwgw
   IgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wFwYDVR0gBBAwDjAM
   BgpghkgBZQMCATAwMIICkAYKKwYBBAGBrGACATGCAoAwggJ8ME8wNzELMAkGA1UE
   BhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNhLmV4YW1wbGUC
   FH90o/wDbOIUeFxZYU5vjfJMR6h5MIICJzCCAa6gAwIBAgIUf3Sj/ANs4hR4XFlh
   Tm+N8kxHqHkwCgYIKoZIzj0EAwMwNzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4
   YW1wbGUgQ0ExEzARBgNVBAMTCmNhLmV4YW1wbGUwHhcNMjUwMTA5MTcwMzQ4WhcN
   MjYwMTA5MTcwMzQ4WjA8MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNV
   BAcTB0hlcm5kb24xDjAMBgNVBAMTBUFsaWNlMHYwEAYHKoZIzj0CAQYFK4EEACID
   YgAEgBz7qVc3Uwgz/zZB5Y1vnkfTOv6VWBZV4XRt/iPPEJvkwKNVozR4US9yNcxX
   mniTOqIlMcLRXYkCipgxf8MwUhzBnvE/25B316nopn5Fe63bXUvz5bVAjVAlIM3E
   A1Gxo3YwdDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A
   0f7tCzkQEZgYzH3NcM2L05IwHwYDVR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJm
   QKowFwYDVR0gBBAwDjAMBgpghkgBZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/
   Uypd7BaVnUjB36UtX9m5ZmPi78y51RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIw
   RJ6U91048NAb3nicHcrGFf1UYrhbDlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u
   MAoGCCqGSM49BAMDA2cAMGQCL2TNHPULWcCS2DqZCCiQeSwx2JPLMI14Vi977bzy
   rImq5p0H3Bel6fAS8BnQ00WNAjEAhHDAlcbRuHhqdW6mOgDd5kWEGGqgixIuvEEc
   fVbnNCEyEE4n0mQ99PHURnXoHwqF
   -----END CERTIFICATE REQUEST-----

   The CSR decodes to:

      0 1073: SEQUENCE {
      4  952:  SEQUENCE {
      8    1:   INTEGER 0
     11   60:   SEQUENCE {
     13   11:    SET {
     15    9:     SEQUENCE {
     17    3:      OBJECT IDENTIFIER countryName (2 5 4 6)
     22    2:      PrintableString 'US'
            :       }
            :      }
     26   11:    SET {
     28    9:     SEQUENCE {
     30    3:      OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8)
     35    2:      PrintableString 'VA'



Housley                 Expires 28 December 2025               [Page 12]

Internet-Draft     Statement of Private Key Possession         June 2025


            :       }
            :      }
     39   16:    SET {
     41   14:     SEQUENCE {
     43    3:      OBJECT IDENTIFIER localityName (2 5 4 7)
     48    7:      PrintableString 'Herndon'
            :       }
            :      }
     57   14:    SET {
     59   12:     SEQUENCE {
     61    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
     66    5:      PrintableString 'Alice'
            :       }
            :      }
            :     }
     73  116:   SEQUENCE {
     75   14:    SEQUENCE {
     77    5:     OBJECT IDENTIFIER ECDH (1 3 132 1 12)
     84    5:     OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
            :      }
     91   98:    BIT STRING
            :     04 01 47 24 13 1F E7 2A D6 CE 45 F7 8B 85 A8 57
            :     BB 97 52 EA 19 D1 02 F1 39 BE 7B 95 58 04 27 CA
            :     00 2F 0C 27 24 90 32 3D 46 8B 11 04 5C BF B5 5A
            :     3B 60 DB 75 EF 9C 9A 2E 08 3A 31 4A 90 C2 48 CA
            :     9F DE 4B E9 E7 E9 DA 33 7E EE C5 AD D9 62 00 FA
            :     0C F6 37 99 EE 44 66 FC 99 3E F4 91 25 31 65 FC
            :     16
            :     }
    191  765:   [0] {
    195  103:    SEQUENCE {
    197    9:     OBJECT IDENTIFIER
            :      extensionRequest (1 2 840 113549 1 9 14)
    208   90:     SET {
    210   88:      SEQUENCE {
    212   12:       SEQUENCE {
    214    3:        OBJECT IDENTIFIER
            :         basicConstraints (2 5 29 19)
    219    1:        BOOLEAN TRUE
    222    2:        OCTET STRING, encapsulates {
    224    0:         SEQUENCE {}
            :          }
            :         }
    226   11:       SEQUENCE {
    228    3:        OBJECT IDENTIFIER keyUsage (2 5 29 15)
    233    4:        OCTET STRING, encapsulates {
    235    2:         BIT STRING 3 unused bits
            :          '10000'B (bit 4)



Housley                 Expires 28 December 2025               [Page 13]

Internet-Draft     Statement of Private Key Possession         June 2025


            :          }
            :         }
    239   34:       SEQUENCE {
    241    3:        OBJECT IDENTIFIER subjectAltName (2 5 29 17)
    246   27:        OCTET STRING, encapsulates {
    248   25:         SEQUENCE {
    250   23:          [1] 'alice@email.example.com'
            :           }
            :          }
            :         }
    275   23:       SEQUENCE {
    277    3:        OBJECT IDENTIFIER
            :         certificatePolicies (2 5 29 32)
    282   16:        OCTET STRING, encapsulates {
    284   14:         SEQUENCE {
    286   12:          SEQUENCE {
    288   10:           OBJECT IDENTIFIER
            :            testCertPolicy (2 16 840 1 101 3 2 1 48 48)
            :            }
            :           }
            :          }
            :         }
            :        }
            :       }
            :      }
    300  656:    SEQUENCE {
    304   10:     OBJECT IDENTIFIER
            :      statementOfPossession (1 3 6 1 4 1 22112 2 1)
    316  640:     SET {
    320  636:      SEQUENCE {
    324   79:       SEQUENCE {
    326   55:        SEQUENCE {
    328   11:         SET {
    330    9:          SEQUENCE {
    332    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
    337    2:           PrintableString 'US'
            :            }
            :           }
    341   19:         SET {
    343   17:          SEQUENCE {
    345    3:           OBJECT IDENTIFIER
            :            organizationName (2 5 4 10)
    350   10:           PrintableString 'Example CA'
            :            }
            :           }
    362   19:         SET {
    364   17:          SEQUENCE {
    366    3:           OBJECT IDENTIFIER commonName (2 5 4 3)



Housley                 Expires 28 December 2025               [Page 14]

Internet-Draft     Statement of Private Key Possession         June 2025


    371   10:           PrintableString 'ca.example'
            :            }
            :           }
            :          }
    383   20:        INTEGER
            :      7F 74 A3 FC 03 6C E2 14 78 5C 59 61 4E 6F 8D F2
            :      4C 47 A8 79
            :         }
    405  551:       SEQUENCE {
    409  430:        SEQUENCE {
    413    3:         [0] {
    415    1:          INTEGER 2
            :           }
    418   20:         INTEGER
            :      7F 74 A3 FC 03 6C E2 14 78 5C 59 61 4E 6F 8D F2
            :      4C 47 A8 79
    440   10:         SEQUENCE {
    442    8:          OBJECT IDENTIFIER
            :           ecdsaWithSHA384 (1 2 840 10045 4 3 3)
            :           }
    452   55:         SEQUENCE {
    454   11:          SET {
    456    9:           SEQUENCE {
    458    3:            OBJECT IDENTIFIER
            :             countryName (2 5 4 6)
    463    2:            PrintableString 'US'
            :             }
            :            }
    467   19:          SET {
    469   17:           SEQUENCE {
    471    3:            OBJECT IDENTIFIER
            :             organizationName (2 5 4 10)
    476   10:            PrintableString 'Example CA'
            :             }
            :            }
    488   19:          SET {
    490   17:           SEQUENCE {
    492    3:            OBJECT IDENTIFIER
            :             commonName (2 5 4 3)
    497   10:            PrintableString 'ca.example'
            :             }
            :            }
            :           }
    509   30:         SEQUENCE {
    511   13:          UTCTime 09/01/2025 17:03:48 GMT
    526   13:          UTCTime 09/01/2026 17:03:48 GMT
            :           }
    541   60:         SEQUENCE {



Housley                 Expires 28 December 2025               [Page 15]

Internet-Draft     Statement of Private Key Possession         June 2025


    543   11:          SET {
    545    9:           SEQUENCE {
    547    3:            OBJECT IDENTIFIER
            :             countryName (2 5 4 6)
    552    2:            PrintableString 'US'
            :             }
            :            }
    556   11:          SET {
    558    9:           SEQUENCE {
    560    3:            OBJECT IDENTIFIER
            :             stateOrProvinceName (2 5 4 8)
    565    2:            PrintableString 'VA'
            :             }
            :            }
    569   16:          SET {
    571   14:           SEQUENCE {
    573    3:            OBJECT IDENTIFIER
            :             localityName (2 5 4 7)
    578    7:            PrintableString 'Herndon'
            :             }
            :            }
    587   14:          SET {
    589   12:           SEQUENCE {
    591    3:            OBJECT IDENTIFIER
            :             commonName (2 5 4 3)
    596    5:            PrintableString 'Alice'
            :             }
            :            }
            :           }
    603  118:         SEQUENCE {
    605   16:          SEQUENCE {
    607    7:           OBJECT IDENTIFIER
            :            ecPublicKey (1 2 840 10045 2 1)
    616    5:           OBJECT IDENTIFIER
            :            secp384r1 (1 3 132 0 34)
            :            }
    623   98:          BIT STRING
            :      04 80 1C FB A9 57 37 53 08 33 FF 36 41 E5 8D 6F
            :      9E 47 D3 3A FE 95 58 16 55 E1 74 6D FE 23 CF 10
            :      9B E4 C0 A3 55 A3 34 78 51 2F 72 35 CC 57 9A 78
            :      93 3A A2 25 31 C2 D1 5D 89 02 8A 98 31 7F C3 30
            :      52 1C C1 9E F1 3F DB 90 77 D7 A9 E8 A6 7E 45 7B
            :      AD DB 5D 4B F3 E5 B5 40 8D 50 25 20 CD C4 03 51
            :      B1
            :           }
    723  118:         [3] {
    725  116:          SEQUENCE {
    727   12:           SEQUENCE {



Housley                 Expires 28 December 2025               [Page 16]

Internet-Draft     Statement of Private Key Possession         June 2025


    729    3:            OBJECT IDENTIFIER
            :             basicConstraints (2 5 29 19)
    734    1:            BOOLEAN TRUE
    737    2:            OCTET STRING, encapsulates {
    739    0:             SEQUENCE {}
            :              }
            :             }
    741   11:           SEQUENCE {
    743    3:            OBJECT IDENTIFIER
            :             keyUsage (2 5 29 15)
    748    4:            OCTET STRING, encapsulates {
    750    2:             BIT STRING 7 unused bits
            :              '1'B (bit 0)
            :              }
            :             }
    754   29:           SEQUENCE {
    756    3:            OBJECT IDENTIFIER
            :             subjectKeyIdentifier (2 5 29 14)
    761   22:            OCTET STRING, encapsulates {
    763   20:             OCTET STRING
            :      23 1D 00 D1 FE ED 0B 39 10 11 98 18 CC 7D CD 70
            :      CD 8B D3 92
            :              }
            :             }
    785   31:           SEQUENCE {
    787    3:            OBJECT IDENTIFIER
            :             authorityKeyIdentifier (2 5 29 35)
    792   24:            OCTET STRING, encapsulates {
    794   22:             SEQUENCE {
    796   20:              [0]
            :      3E 98 BC B2 EF DC 34 1B BE 71 92 D2 A3 FA 6D BC
            :      F2 66 40 AA
            :               }
            :              }
            :             }
    818   23:           SEQUENCE {
    820    3:            OBJECT IDENTIFIER
            :             certificatePolicies (2 5 29 32)
    825   16:            OCTET STRING, encapsulates {
    827   14:             SEQUENCE {
    829   12:              SEQUENCE {
    831   10:               OBJECT IDENTIFIER
            :                testCertPolicy (2 16 840 1 101 3 2 1 48 48)
            :                }
            :               }
            :              }
            :             }
            :            }



Housley                 Expires 28 December 2025               [Page 17]

Internet-Draft     Statement of Private Key Possession         June 2025


            :           }
            :          }
    843   10:        SEQUENCE {
    845    8:         OBJECT IDENTIFIER
            :          ecdsaWithSHA384 (1 2 840 10045 4 3 3)
            :          }
    855  103:        BIT STRING, encapsulates {
    858  100:         SEQUENCE {
    860   48:          INTEGER
            :      6B BF 53 2A 5D EC 16 95 9D 48 C1 DF A5 2D 5F D9
            :      B9 66 63 E2 EF CC B9 D5 10 3C 5A 16 CE BF 42 90
            :      56 B7 18 B6 3E 2A 39 D8 8C 54 A0 5C A1 57 1E C8
    910   48:          INTEGER
            :      44 9E 94 F7 5D 38 F0 D0 1B DE 78 9C 1D CA C6 15
            :      FD 54 62 B8 5B 0E 5C AD 2B 8B 42 6B 91 C1 C4 3F
            :      EA 02 0C B8 FD E5 33 03 93 59 C1 56 8B 2B BF 2E
            :           }
            :          }
            :         }
            :        }
            :       }
            :      }
            :     }
            :    }
    960   10:  SEQUENCE {
    962    8:   OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
            :    }
    972  103:  BIT STRING, encapsulates {
    975  100:   SEQUENCE {
    977   47:    INTEGER
            :     64 CD 1C F5 0B 59 C0 92 D8 3A 99 08 28 90 79 2C
            :     31 D8 93 CB 30 8D 78 56 2F 7B ED BC F2 AC 89 AA
            :     E6 9D 07 DC 17 A5 E9 F0 12 F0 19 D0 D3 45 8D
   1026   49:    INTEGER
            :     00 84 70 C0 95 C6 D1 B8 78 6A 75 6E A6 3A 00 DD
            :     E6 45 84 18 6A A0 8B 12 2E BC 41 1C 7D 56 E7 34
            :     21 32 10 4E 27 D2 64 3D F4 F1 D4 46 75 E8 1F 0A
            :     85
            :     }
            :    }
            :   }

   The CA issues a key establishment certificate to Alice:








Housley                 Expires 28 December 2025               [Page 18]

Internet-Draft     Statement of Private Key Possession         June 2025


   -----BEGIN CERTIFICATE-----
   MIICJTCCAaygAwIBAgIUf3Sj/ANs4hR4XFlhTm+N8kxHqHowCgYIKoZIzj0EAwMw
   NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh
   LmV4YW1wbGUwHhcNMjUwMTA5MTcwNTAwWhcNMjYwMTA5MTcwNTAwWjA8MQswCQYD
   VQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNVBAcTB0hlcm5kb24xDjAMBgNVBAMT
   BUFsaWNlMHQwDgYFK4EEAQwGBSuBBAAiA2IABAFHJBMf5yrWzkX3i4WoV7uXUuoZ
   0QLxOb57lVgEJ8oALwwnJJAyPUaLEQRcv7VaO2Dbde+cmi4IOjFKkMJIyp/eS+nn
   6dozfu7FrdliAPoM9jeZ7kRm/Jk+9JElMWX8FqN2MHQwDAYDVR0TAQH/BAIwADAL
   BgNVHQ8EBAMCAwgwHQYDVR0OBBYEFAnLfJvnEUcvLXaPUDZMZlQ/zZ3WMB8GA1Ud
   IwQYMBaAFD6YvLLv3DQbvnGS0qP6bbzyZkCqMBcGA1UdIAQQMA4wDAYKYIZIAWUD
   AgEwMDAKBggqhkjOPQQDAwNnADBkAjARQ5LuV6yz8A5DZCll1S/gfxZ+QSJl/pKc
   cTL6Sdr1IS18U/zY8VUJeB2H0nBamLwCMBRQ6sEWpNoeeR8Bonpoot/zYD2luQ1V
   2jevmYsnBihKF0debgfhGvh8WIgBR69DZg==
   -----END CERTIFICATE-----

Acknowledgements

   Thanks to Sean Turner, Joe Mandel, Mike StJohns, Mike Ounsworth, John
   Gray, Carl Wallace, Corey Bonnell, Hani Ezzadeen, Deb Cooley, Mohamed
   Boucadair, and Bron Gondwana for their constructive comments.

Author's Address

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























Housley                 Expires 28 December 2025               [Page 19]


name: draft-bastian-jose-pkdh
rev: 01
title: Public Key Derived HMAC for JOSE
time: 2025-11-04T20:17:23Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T20:06:52Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014877+00:00
abstract:
This specification defines the use of a Diffie-Hellman key agreement
   (DH-KA) protocol combined with a key derivation function (KDF) to
   derive a symmetric Message Authentication Code (MAC) key from public
   information conveyed within a JSON Web Signature (JWS).

full_text:
Javascript Object Signing and Encryption                      P. Bastian
Internet-Draft                                                  M. Kraus
Intended status: Informational                      Bundesdruckerei GmbH
Expires: 23 April 2026                                      S. Santesson
                                                         IDsec Solutions
                                                           P. L. Altmann
                                       The Agency for Digital Government
                                                         20 October 2025


                    Public Key Derived HMAC for JOSE
                       draft-bastian-jose-pkdh-01

Abstract

   This specification defines the use of a Diffie-Hellman key agreement
   (DH-KA) protocol combined with a key derivation function (KDF) to
   derive a symmetric Message Authentication Code (MAC) key from public
   information conveyed within a JSON Web Signature (JWS).

About This Document

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

   The latest revision of this draft can be found at
   https://paulbastian.github.io/draft-bastian-jose-pkdh/draft-bastian-
   jose-pkdh.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-bastian-jose-pkdh/.

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

   Source for this draft and an issue tracker can be found at
   https://github.com/paulbastian/draft-bastian-jose-pkdh.

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




Bastian, et al.           Expires 23 April 2026                 [Page 1]

Internet-Draft              PKD-HMAC for JOSE               October 2025


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

   This Internet-Draft will expire on 23 April 2026.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Cryptographic Dependencies  . . . . . . . . . . . . . . . . .   4
   5.  Public Key Derived HMAC . . . . . . . . . . . . . . . . . . .   4
     5.1.  Signature Generation  . . . . . . . . . . . . . . . . . .   5
     5.2.  Signature Verification  . . . . . . . . . . . . . . . . .   5
     5.3.  Signature Suites  . . . . . . . . . . . . . . . . . . . .   6
   6.  Public Key Derived HMAC for JOSE  . . . . . . . . . . . . . .   6
     6.1.  The "pkdh" Header Parameter . . . . . . . . . . . . . . .   7
       6.1.1.  Syntax and semantics  . . . . . . . . . . . . . . . .   7
     6.2.  Example JWT (*TODO*)  . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     7.1.  Replay Attack Detection . . . . . . . . . . . . . . . . .   9
     7.2.  Limited Repudiability . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  10
   Appendix B.  Appendix A.  JSON Schema for the "pkdh" Header
           Parameter . . . . . . . . . . . . . . . . . . . . . . . .  10
   Document History  . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13




Bastian, et al.           Expires 23 April 2026                 [Page 2]

Internet-Draft              PKD-HMAC for JOSE               October 2025


1.  Introduction

   JSON Web Signature (JWS) [RFC7515] and JSON Web Algorithms (JWA)
   [RFC7518] specify how to secure content with Hash-based Message
   Authentication Codes (HMAC) [RFC2104] using a shared symmetric key.
   These specifications do not provide means to dynamically derive a MAC
   key for JWS validation using only public information embedded in the
   JWS.

   This specification defines a new protected header parameter, pkdh
   (public key derived HMAC), which contains information required to
   derive an HMAC key using a Diffie-Hellman key agreement (DH-KA) and a
   key derivation function (KDF).  The JWS Producer's DH-KA public key
   appears either in the pkdh parameter or in a claims element for use
   in the key agreement computation.  The pkdh parameter also includes
   the JWS Recipient's DH-KA public key, used by the JWS Producer during
   key agreement, as well as the KDF parameters necessary for deriving
   the MAC key.

   This specification also defines new alg parameter values, that are
   fully-specified according to Fully Specified Algorithms
   (https://www.ietf.org/archive/id/draft-jones-jose-fully-specified-
   algorithms-00.html).

   The method is useful in settings where pre-shared keys are
   undesirable or infeasible, and where direct key distribution or key
   wrapping introduces operational concerns.  It enables the use of
   HMAC-based signatures that can be validated solely with information
   embedded in a JWS.

   A primary motivation for this work is to enable HMAC signature
   validation from information contained within an SD-JWT, mirroring
   capabilities available in credential formats like [ISO-18013-5].

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Terminology

   The draft uses "JSON Web Signature", "JOSE Header", "JWS Signature",
   "JWS Signing Input" as defined by [RFC7515].

   *Producer*:  The party that performs the DH-KA first, derives the MAC



Bastian, et al.           Expires 23 April 2026                 [Page 3]

Internet-Draft              PKD-HMAC for JOSE               October 2025


      key via a KDF, constructs the JOSE Header and JWS Payload, and
      computes the JWS Signature value.

   *Recipient*:  The party that performs the DH-KA second, derives the
      MAC key via information in the JWS, and validates the JWS using
      the MAC key according to [RFC7515].

4.  Cryptographic Dependencies

   This specification relies on the following primitives:

   *  A Diffie-Hellman Key Agreement (KA-DH), for example ECKA-DH
      defined in [BSI-TR-03111]:

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

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

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

   *  A key derivation function (KDF), for example HKDF defined in
      [RFC5869]:

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

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

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

   *  A Message Authentication Code algorithm (MAC), for example HMAC
      defined in [RFC2104]:

      -  MacSign(k, i): Returns an authenticated tag for the given input
         i and key k.

      -  Nk: The length in bytes of key k.

5.  Public Key Derived HMAC

   A public key derived HMAC requires three components for an algorithm:




Bastian, et al.           Expires 23 April 2026                 [Page 4]

Internet-Draft              PKD-HMAC for JOSE               October 2025


   1.  a Diffie-Hellman Key Agreement (DHKA)

   2.  a Key Derivation Function (KDF)

   3.  a Message Authentication Code algorithm (MAC)

   In general, these parameters are chosen by the Producer.  These
   parameters need to be communicated to the Recipient to be able to
   verify the HMAC.

5.1.  Signature Generation

   The generation of the public key derived HMAC uses the Producer’s
   private key, the Recipient’s public key, and the message as inputs,
   along with optional parameters.  The retrieval and communication of
   the Recipient's public key is out of scope of this specification and
   subject to the implementing protocols.

   Input:

   *  skP: private key of the Producer

   *  pkR: public key of the Recipient

   *  msg: JWS Signing Input

   *  salt : salt for key derivation

   *  info : info for key derivation

   Function:

   def pkdHmacSign(skP, pkR, msg, salt, info)

       dh =  DH(skP, pkR)
       prk = Extract(salt, dh)
       k = Expand(prk, info, Nk)
       signature = MacSign(k, msg)
       return signature

5.2.  Signature Verification

   The generation of the public key derived HMAC uses the Recipient's
   private key, the Producer's public key, and the message as inputs,
   along with optional parameters.

   Input:




Bastian, et al.           Expires 23 April 2026                 [Page 5]

Internet-Draft              PKD-HMAC for JOSE               October 2025


   *  skR: private key of the Recipient

   *  pkP: public key of the Producer

   *  msg: JWS Signing Input

   *  salt : salt for key derivation

   *  info : info for key derivation

   *  signature : the Message Authentication Code

   Function:

   def pkdHmacVerify(skR, pkP, msg, signature, salt, info)

       dh =  DH(skR, pkP)
       prk = Extract(salt, dh)
       k = Expand(prk, info, Nk)
       signature' = MacSign(k, msg)
       if signature != signature':
         raise Exception("Public key derived HMAC invalid")
       return

5.3.  Signature Suites

   Algorithms MUST follow the naming **TODO**.

6.  Public Key Derived HMAC for JOSE

   Public Key Derived HMAC behave like a digital signature as described
   in Section 3 of [RFC7518] and are intended for use in JSON Web
   Signatures (JWS) as described in [RFC7515].  The Producer performs
   the Message Signature or MAC Computation as defined by Section 5.1 of
   [RFC7515].  The Recipient performs the Message Signature or MAC
   Validation as defined by Section 5.2 of [RFC7515].

   The following JWS headers are used to convey Public Key Derived HMAC
   for JOSE:

   *  alg : REQUIRED.  The algorithm parameter describes the chosen
      signature suite, for example the ones described in Suites
      (Section 5.3).

   *  pkdh : REQUIRED.  The pkdh (public key derived HMAC) parameter
      specifies the inputs needed to derive a symmetric key for MAC PKDH
      Headermake (Section 6.1).




Bastian, et al.           Expires 23 April 2026                 [Page 6]

Internet-Draft              PKD-HMAC for JOSE               October 2025


   *  nonce : OPTIONAL.  The nonce may be provided by the Recipient
      additional to it's public key and ensure additional freshness of
      the signature.  If provided, the Producer SHOULD add the nonce to
      the header.

6.1.  The "pkdh" Header Parameter

   The pkdh protected header parameter specifies the inputs needed to
   derive a symmetric key for MAC computation using a key agreement and
   derivation scheme.  Its value is a JSON object that includes
   identifiers, public keys, and algorithm-specific parameters relevant
   to the derivation.

6.1.1.  Syntax and semantics

   The pkdh Header Parameter value MUST be a JSON object with the
   following fields:

   *  pkr (object, REQUIRED): The Recipient's public key used in DH-KA.
      The pkr object MUST contain at least one key claim as defined in
      Section 4.1 of [RFC7515].

      Implementations MUST reject a JWS if the pkr key cannot be
      resolved unambiguously at validation time.

   *  pkp (object, OPTIONAL): The JWS Producer’s public key used in DH-
      KA.  The pkp object MUST contain at least one key claim as defined
      in Section 4.1 of [RFC7515].

      Implementations MUST reject a JWS if the pkp key cannot be
      resolved unambiguously at validation time or is incompatible with
      the key information in pkr.

   *  info (string, OPTIONAL): Context- and application-specific
      information used as the info parameter to the KDF.  If absent, the
      default string value "PKDH-v1" SHALL be used.

   *  salt (string, OPTIONAL): The salt parameter to the KDF encoded as
      BASE64(salt).  If absent, TBD.

   For a machine-readable definition of these fields, see the JSON
   Schema in Appendix A (Appendix B).

6.2.  Example JWT (*TODO*)

   The JWT/JWS header:





Bastian, et al.           Expires 23 April 2026                 [Page 7]

Internet-Draft              PKD-HMAC for JOSE               October 2025


   {
     "typ":"JWT",
     "alg":"ECDH-P256+HKDF-SHA256+HS256",
     "pkdh":{
       "pkp":{
         "jwk":{
           "kty":"EC",
           "crv":"P-256",
           "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
           "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
         }
       },
       "pkr":{
         "jwk":{
           "kty":"EC",
           "crv":"P-256",
           "x":"vWV4vmRT8HV9QAkbZJAWrvjOV0NfNOzkzq92apq8yjk",
           "y":"XGJRplhubKDv6cFA7e9-yn7F89UUwt57JVLAOS1tpXE"
         }
       },
       "info":"PKDH-v1",
       "salt": "V2hhdCBhIHNhbHQ="
     }
   }

   The JWT/JWS payload (TODO!:

   {
     "sub": "1234567890",
     "iat": 1516239022
   }

   The JWT/JWS signature:

   base64-encoded MAC

   This specification described instantiations of Public Key Derived
   HMAC using specific algorithm combinations:

+-------------------------------+--------------------------+----------------+
| Algorithm Name                | Algorithm Description    | Requirements   |
+-------------------------------+--------------------------+----------------+
| "ECDH-P256+HKDF-SHA256+HS256" | ECDH using NIST P-256,   |   Optional     |
|                               | HKDF using SHA-256, and  |                |
|                               | HMAC using SHA-256       |                |
+-------------------------------+--------------------------+----------------+





Bastian, et al.           Expires 23 April 2026                 [Page 8]

Internet-Draft              PKD-HMAC for JOSE               October 2025


7.  Security Considerations

7.1.  Replay Attack Detection

   Recipient MUST ensure the freshness of signatures by utilizing
   ephemeral keys in pkr or by providing a nonce for nonce.

7.2.  Limited Repudiability

   A malicious Recipient can weaken the repudiability property by
   involving certain third parties in the protocol steps.

   *  One method is to have a third party observe all protocol steps so
      that third party can be sure that the signature originates by the
      Producer.

   *  Another method requires that the Recipient's public key is a
      shared key that has previously been calculated with the keys of
      certain specific third parties so that the proof of authenticity
      can be done with Multi Party Computation involving all parties
      (see [TLS-NOTARY]).

8.  IANA Considerations

   Define:

   *  define new pkdh header parameter

   *  alg values for *TODO* and some more

9.  References

9.1.  Normative References

   [BSI-TR-03111]
              "Technical Guideline BSI TR-03111: Elliptic Curve
              Cryptography, Version 2.10", June 2018,
              <https://www.bsi.bund.de/dok/TR-03111-en>.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/rfc/rfc2104>.

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



Bastian, et al.           Expires 23 April 2026                 [Page 9]

Internet-Draft              PKD-HMAC for JOSE               October 2025


   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/rfc/rfc5869>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/rfc/rfc7515>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7517>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7518>.

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

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

9.2.  Informative References

   [ISO-18013-5]
              "ISO/IEC 18013-5:2021, Personal identification — ISO-
              compliant driving licence, Part 5: Mobile driving licence
              (mDL) application", September 2021,
              <https://www.iso.org/standard/69084.html>.

   [TLS-NOTARY]
              "TLSNotary project", October 2024,
              <https://tlsnotary.org/>.

Appendix A.  Acknowledgments

   Thanks to:

   *  Brian Campbell

   *  John Bradley

Appendix B.  Appendix A.  JSON Schema for the "pkdh" Header Parameter





Bastian, et al.           Expires 23 April 2026                [Page 10]

Internet-Draft              PKD-HMAC for JOSE               October 2025


   {
     "$schema": "https://json-schema.org/draft/2020-12/schema",
     "$id": "https://example.com/schemas/pkdh.schema.json",
     "title": "JOSE Header Parameter: pkdh",
     "type": "object",
     "properties": {
       "pkp": {
         "$ref": "#/$defs/keyRef"
       },
       "pkr": {
         "$ref": "#/$defs/keyRef"
       },
       "info": {
         "type": "string"
       },
       "salt": {
         "type": "string"
       },
       "params": {
         "type": "object"
       }
     },
     "required": [
       "pkr"
     ],
     "additionalProperties": false,
     "$defs": {
       "keyRef": {
         "type": "object",
         "properties": {
           "jwk": {
             "type": "object"
           },
           "kid": {
             "type": "string"
           },
           "jkt": {
             "type": "string"
           },
           "jku": {
             "type": "string"
           },
           "x5c": {
             "type": "array",
             "items": {
               "type": "string"
             }
           },



Bastian, et al.           Expires 23 April 2026                [Page 11]

Internet-Draft              PKD-HMAC for JOSE               October 2025


           "x5u": {
             "type": "string"
           },
           "x5t": {
             "type": "string"
           }
         },
         "anyOf": [
           {
             "required": [
               "jwk"
             ]
           },
           {
             "required": [
               "kid"
             ]
           },
           {
             "required": [
               "jkt"
             ]
           },
           {
             "required": [
               "jku"
             ]
           },
           {
             "required": [
               "x5c"
             ]
           },
           {
             "required": [
               "x5u"
             ]
           },
           {
             "required": [
               "x5t"
             ]
           }
         ],
         "additionalProperties": false
       }
     }
   }



Bastian, et al.           Expires 23 April 2026                [Page 12]

Internet-Draft              PKD-HMAC for JOSE               October 2025


Document History

   -01

   *  use consistent key naming

   *  rename pkds header to pkdh header

   *  add salt to pkdh header

   -00

   *  initial draft after renaming to draft-bastian-jose-pkdh

   [ draft-bastian-jose-dvs ]

   -02

   *  remove term "Designated Verifier Signatures", replace with "Public
      Key Derived HMAC"

   *  add pkds header structure

   *  rename Signing Party to Producer

   *  rename Verifying Party to Recipient

   -01

   *  remove all HPKE-related parts

   *  add co-editors Stefan Santesson and Peter Lee Altmann

   -00

   *  initial draft

Authors' Addresses

   Paul Bastian
   Bundesdruckerei GmbH
   Email: bastianpaul@googlemail.com


   Micha Kraus
   Bundesdruckerei GmbH
   Email: kraus.micha@gmail.com




Bastian, et al.           Expires 23 April 2026                [Page 13]

Internet-Draft              PKD-HMAC for JOSE               October 2025


   Stefan Santesson
   IDsec Solutions
   Email: stefan@aaa-sec.com


   Peter Lee Altmann
   The Agency for Digital Government
   Email: altmann@mail.com











































Bastian, et al.           Expires 23 April 2026                [Page 14]


name: draft-lake-pocero-authkem-ikr-edhoc
rev: 01
title: KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios
time: 2026-01-08T08:05:20Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-12T08:05:20Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:09.014882+00:00
abstract:
This document specifies a more efficient variant of a Key
   Encapsulation Mechanism (KEM)-based authentication method for the
   Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol,
   designed for the specific scenario in which the Initiator has prior
   knowledge of the Responder’s credentials, a case commonly found in
   constrained environments.  Improving upon the approach described in
   KEM-based Authentication for EDHOC, this method uses only a mandatory
   three-message handshake to enable signature-free post-quantum
   authentication when PQC KEMs, such as the NIST-standardized ML-KEM,
   are employed, while still providing mutual authentication, forward
   secrecy, and a degree of identity protection.

full_text:
individual                                              L. Pocero Fraile
Internet-Draft                                               C. Koulamas
Intended status: Standards Track                          A.P. Fournaris
Expires: 12 July 2026                                      E. Haleplidis
                                                        ISI, R.C. ATHENA
                                                          8 January 2026


 KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR)
                               Scenarios
                 draft-lake-pocero-authkem-ikr-edhoc-01

Abstract

   This document specifies a more efficient variant of a Key
   Encapsulation Mechanism (KEM)-based authentication method for the
   Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol,
   designed for the specific scenario in which the Initiator has prior
   knowledge of the Responder’s credentials, a case commonly found in
   constrained environments.  Improving upon the approach described in
   KEM-based Authentication for EDHOC, this method uses only a mandatory
   three-message handshake to enable signature-free post-quantum
   authentication when PQC KEMs, such as the NIST-standardized ML-KEM,
   are employed, while still providing mutual authentication, forward
   secrecy, and a degree of identity protection.

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 12 July 2026.

Copyright Notice

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




Pocero Fraile, et al.     Expires 12 July 2026                  [Page 1]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   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
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology and Requirements Language . . . . . . . . . .   3
       1.2.1.  Key Encapsulation Mechanisms (KEMs) . . . . . . . . .   4
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Protocol Elements . . . . . . . . . . . . . . . . . . . .   6
       2.1.1.  Ephemeral KEM . . . . . . . . . . . . . . . . . . . .   7
       2.1.2.  Authentication Parameters . . . . . . . . . . . . . .   7
         2.1.2.1.  Method  . . . . . . . . . . . . . . . . . . . . .   7
         2.1.2.2.  Authentication Keys . . . . . . . . . . . . . . .   8
         2.1.2.3.  Authentication Credentials  . . . . . . . . . . .   8
         2.1.2.4.  Identification of Credentials . . . . . . . . . .   8
       2.1.3.  Cipher Suites . . . . . . . . . . . . . . . . . . . .   9
   3.  Key Derivation  . . . . . . . . . . . . . . . . . . . . . . .   9
     3.1.  Keys for EDHOC Message Processing . . . . . . . . . . . .  11
       3.1.1.  EDHOC_Extract . . . . . . . . . . . . . . . . . . . .  11
         3.1.1.1.  PRK_1e  . . . . . . . . . . . . . . . . . . . . .  11
         3.1.1.2.  PRK_2m  . . . . . . . . . . . . . . . . . . . . .  12
         3.1.1.3.  PRK_2e3e3m  . . . . . . . . . . . . . . . . . . .  12
       3.1.2.  EDHOC_Expand and EDHOC_KDF  . . . . . . . . . . . . .  13
       3.1.3.  PRK_out . . . . . . . . . . . . . . . . . . . . . . .  14
     3.2.  Keys for EDHOC Applications . . . . . . . . . . . . . . .  14
   4.  Message Formatting and Processing . . . . . . . . . . . . . .  14
     4.1.  KEM-based Authentication EDHOC Message 1  . . . . . . . .  15
       4.1.1.  Formating of Message 1  . . . . . . . . . . . . . . .  15
       4.1.2.  Initiator Composition of Message 1  . . . . . . . . .  15
       4.1.3.  Responder Processing of Message 1 . . . . . . . . . .  16
     4.2.  KEM-based authentication EDHOC Message 2  . . . . . . . .  17
       4.2.1.  Formating of Message 2  . . . . . . . . . . . . . . .  17
       4.2.2.  Responder Composition of Message 2  . . . . . . . . .  17
       4.2.3.  Initiator Processing of Message 2 . . . . . . . . . .  19
     4.3.  KEM-based authentication EDHOC Message 3  . . . . . . . .  20
       4.3.1.  Formating of Message 3  . . . . . . . . . . . . . . .  20
       4.3.2.  Initiator Composition of Message 3  . . . . . . . . .  20
       4.3.3.  Responder Processing of Message 3 . . . . . . . . . .  21
     4.4.  KEM-based authentication EDHOC Message 4  . . . . . . . .  22
       4.4.1.  Formating of Message 4  . . . . . . . . . . . . . . .  22



Pocero Fraile, et al.     Expires 12 July 2026                  [Page 2]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


       4.4.2.  Responder Composition of Message 4  . . . . . . . . .  22
       4.4.3.  Initaitor Processing of Message 4 . . . . . . . . . .  22
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
     5.1.  EDHOC Method Types Registry . . . . . . . . . . . . . . .  23
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1.  Introduction

   The purpose of this document is to address a more efficient quantum-
   resistant transition of the Ephemeral Diffie-Hellman over COSE
   (EDHOC) protocol by extending with a new Key Encapsulation Mechanism
   (KEM)-based authentication method that uses a mandatory three-message
   handshake in Initiator-Known Responder (IKR) Scenarios.

   The specific protocol is part of a more extensive analysis of the PQ
   transition for the EDHOC protocol, which is currently in the process
   of being published.

1.1.  Motivation

   The KEM-based authentication method for EDHOC, specified in
   [I-D.pocero-authkem-edhoc], addresses the general mutually unknown
   peer scenario, similar to the original EDHOC protocol.  In this case,
   the Initiator and Responder, if do not have prior knowledge of each
   other's credentials can exchange them in the form of X.509
   certificate.  To maintain this generality an additional round trip is
   required, resulting in a mandatory five-message handshake.

   This document explores the possibility of reducing this overhead in
   the specific scenario where the Initiator already possesses the
   credentials of the Responder it wishes to connect in advance.  This
   applies to cases where the Initiator is a constrained device equipped
   with credentials for the Responder, obtained through pre-provisioning
   or out-of-band methods.  A typical example is during onboarding,
   where a remote or local server (acting as the Responder) is
   configured on the device in advance.  Such settings are particularly
   relevant for EDHOC, which targets constrained environments where
   transmitting credentials can be costly.

1.2.  Terminology and Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].



Pocero Fraile, et al.     Expires 12 July 2026                  [Page 3]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   Readers are expected to be familiar with the terms and concepts
   described in EDHOC [RFC9528], CBOR [RFC8949], CBOR Sequences
   [RFC8742], COSE Structures and Processing [RFC9052] and COSE
   Algorithms [RFC9053], When referring to CBOR, this specification
   always refers to Deterministically Encoded CBOR, as specified in
   Section 4.2.1 and 4.2.2 of [RFC8949].  The single output from
   authenticated encryption (including the authentication tag) is called
   "ciphertext", following [RFC5116].

1.2.1.  Key Encapsulation Mechanisms (KEMs)

   The Key Encapsulation Mechanism consists of 3 algorithms:

   *  *( pk, sk ) <- KEM.KeyGen( )*: The probabilistic key generation
      algorithm generates a KEM key pair consisting of a public
      encapsulation key ( pk ) and secret decapsulation key ( sk ).

   *  *( ss , ct ) <- KEM.Encapsulate( pk )*: The probabilistic
      encapsulation algorithm takes as input a public encapsulation key
      ( pk ) and produces a shared secret ( ss ) and ciphertext ( ct ).

   *  *( ss ) <- KEM.Decapsulate( ct, sk )*: The decapsulation algorithm
      takes as input a secret encacpsulation key ( sk ) and produce a
      shared secret ( ss ).

2.  Protocol Overview

   This document defines a KEM-based authentication method for EDHOC,
   tailored for a specific scenario where the Initiator knows the
   credentials of the Responder it intends to communicate with
   beforehand.  In such cases, the method, specified in this document,
   reduces the standard five-message handshake defined in
   [I-D.pocero-authkem-edhoc] to a three-message exchange.

   This variant, referred to as Initiator Knows Responder (IKR),
   converts the Noise-XX pattern, used in both static-DH and KEM-based
   authentication EDHOC methods, into a Noise-IK pattern.  The Noise-IK
   pattern enables a mutual authentication handshake when the Initiator
   has prior knowledge of the Responder’s static public key, and the
   Initiator’s static keys are sent in the first message.  The mechanism
   provided in [PQNoise-CCS22] for transforming this pattern into the PQ
   Noise-IK version is integrated into this protocol.

   The KEM-based IKR variant provides a more efficient handshake with
   only three mandatory messages while maintaining mutual
   authentication, forward secrecy, and a level of identity protection.
   Notably, the Responder does not require prior knowledge of the
   Initiator’s credentials.  Instead, the Initiator encrypts its



Pocero Fraile, et al.     Expires 12 July 2026                  [Page 4]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   credentials, or an identifier, within message_1 using a key derived
   from a shared secret, computed over the Responder’s static KEM public
   key, which the Initiator already possesses.  Consequently, only the
   legitimate Responder, holding the corresponding static KEM private
   key, can decrypt this information, ensuring that the Initiator’s
   identity remains protected against both passive and active attackers.

   The KEM-based EDHOC protocol consists of three mandatory messages
   (message_1, message_2, message_3), an optional message_4, and an
   error message, between an Initiator (I) and a Responder (R).
   Figure 2 illustrates a KEM-based ikr authentication EDHOC message
   flow as well as the content of each message.  The protocol elements
   in Figure 1 are introduced in this Section and in Section 4.  Message
   formatting and processing are specified in Section 4.

    Initiator                                                Responder
    |  pk_eph, ct_R, AEAD( METHOD, SUITES_I, ID_CRED_I, C_I, EAD_1)  |
    +---------------------------------------------------------------->
    |                       message_1                                |
    |                                                                |
    |       ct_eph, ct_I, AEAD( C_R, ID_CRED_R, MAC_2, EAD_2 )       |
    <----------------------------------------------------------------+
    |                       message_2                                |
    |                                                                |
    |                  AEAD( MAC_3, EAD_3 )                          |
    +---------------------------------------------------------------->
    |                       message_3                                |
    |                                                                |
    |                      AEAD( EAD_4 )                             |
    <----- - - -- - - - - - - - - - - - - - - - - - - - - - - - - - -+
    |                         message_4                              |

            Figure 1: EDHOC Message Flow using the KEM-based IKR
                           Authentication Method

   The Initiator can derive symmetric application keys after receiving
   message_2 and Responder after receiving message_3.

   *  pk_eph is the ephemeral KEM public key generated by the Initiator.

   *  ct_eph is the ephemeral ciphertext computed by the Responder with
      the KEM.encapsulation algorithm over the received ephemeral public
      key (pk_eph).

   *  ct_R is the responder ciphertext computed by the Initiator with
      the KEM.encapsulation algorithm over the static KEM public key of
      the Responder, retrieved from the received ID_CRED_R in message_2.




Pocero Fraile, et al.     Expires 12 July 2026                  [Page 5]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   *  ct_I is the Iniatiator ciphertext computed by the Responder with
      the KEM.encapsulation algorithm over the static KEM public key of
      the Initiator, retrieved from the received ID_CRED_I in message_1.

   *  "CRED_I and CRED_R are the authentication credentials containing
      the public authentication keys of I and R, respectively", as
      defined in Section 2 of [RFC9528] .

   *  "ID_CRED_I and ID_CRED_R are used to identify and optionally
      transport the credentials of I and R, respectively", as defined in
      Section 2 of [RFC9528].

   *  AEAD(), and MAC() denote Authenticated Encryption with Associated
      Data, and Message Authentication Code, crypto algorithms applied
      with keys derived from one or more shared secrets calculated
      during the protocol", as defined in Section 2 of [RFC9528]

   *  "SUITES_I contains cipher suites supported by the Initiator and
      formatted and processed as specified in Section 3.6 and 6.3.2 of
      [RFC9528]"".

   *  "METHOD is an integer specifying the authentication method",as
      defined in Section 3.2 of [RFC9528].  In this case method 5; see
      Section 2.1.2.1.

   *  C_I and C_R are Connection Identifiers chosen by the Initiator and
      Responder, respectively, as specified in Section 3.3 of [RFC9528]

   *  EAD_1, EAD_2, EAD_3, EAD_4 are External Authorization Data
      included in message_1, message_2, message_3 and message_4,
      respectively

   This protocol is designed so that it follows the provisions of
   [RFC9528], that is, to encrypt and integrity protect as much
   information as possible and derive symmetric keys and random material
   using EDHOC_KDF with as much previous information as possible

2.1.  Protocol Elements

   This section describes the principal protocol elements that differ
   from the ones defined in EDHOC.  For the missing elements, the
   definitions in Section 3 of [RFC9528] SHOULD be consulted.









Pocero Fraile, et al.     Expires 12 July 2026                  [Page 6]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


2.1.1.  Ephemeral KEM

   The ephemeral KEM is used to provide forward secrecy.  The Initiator
   generates a new ephemeral KEM key pair in every new session to ensure
   that the compromise of long-term keys does not compromise past
   communications.  The elements of the Ephemeral KEM are:

   *  The ephemeral KEM key pair ( pk_eph, sk_eph ) is generated by the
      Initiator using the following function:

      pk_eph, sk_eph <- KEM.KeyGen()

   *  The ephemeral shared secret ( ss_eph ) and the ephemeral
      ciphertext ( ct_eph ) are generated using the encapsulation and
      decapsulation functions: in the Responder

      ss_eph, ct_eph <-  KEM.Encapsulate( pk_eph )

      in the Initiator

      ss_eph <-  KEM.decapsulation( ct_eph, sk_eph )

2.1.2.  Authentication Parameters

   The protocol performs the same authentication-related operations as
   described in Section 3.5 of [RFC9528]

   The protocol transports information about credentials ID_CRED_I and
   ID_CRED_R encrypted in message_1 and message_2, respectively.

2.1.2.1.  Method

   The protocol extends EDHOC with a new KEM-based authentication method
   for IKR scenarios, where both parties use static KEM key pairs.  The
   authentication is provided by a Message Authentication Code (MAC)
   included in message_2 and message_3 to authenticate the Responder and
   Initiator, respectively.  The Initiator and Responder need to have
   agreed on a method 5.

      +===================+====================+====================+
      | Method Type Value | Initiator          | Responder          |
      |                   | Authentication Key | Authentication Key |
      +===================+====================+====================+
      |                 5 | Static KEM Key     | Static KEM Key     |
      |                   | (IKR scenario)     | (IKR scenario)     |
      +-------------------+--------------------+--------------------+

               Table 2: Authentication Keys for Method Types



Pocero Fraile, et al.     Expires 12 July 2026                  [Page 7]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


2.1.2.2.  Authentication Keys

   The authentication key MUST be a static KEM authentication key pair.

   *  The Initiator static KEM authentication key pair: ( pk_I, sk_I )

   *  The Responder static KEM authentication key pair: ( pk_R, sk_R )

2.1.2.3.  Authentication Credentials

   The authentication credentials, CRED_I and CRED_R, contain the static
   KEM authentication public key of the Initiator and Responder,
   respectively, as described in Section 3.5.2 of [RFC9528].

   *  The authentication credentials can be X.509 certificates seconded
      as bstr, as defined in Section 3.5.2 of [RFC9528], using
      [RFC9360].  [I-D.ietf-lamps-kyber-certificates] describes the
      conventions for using the ML-KEM in X.509 Public Key
      Infrastructure.

   *  Additionally, the authentication credential may include a
      COSE_key, formatted as specified in [RFC8392], to reduce the
      credential size and avoid the PQC signature verification needed
      when X.509 certificates are used.  New IANA value registries
      should be defined to extend COSE Algorithms with the corresponding
      KEMs algorithm values.

2.1.2.4.  Identification of Credentials

   "The ID_CRED fields are used to identify and optionally transport
   credentials", as defined in Section 3.5.3 of [RFC9528].

   *  "ID_CRED_R is intended to facilitate for the Initiator retrieving
      the authentication credential CRED_R and the authentication key of
      R", as defined in Section 3.5.3 of [RFC9528].  For the
      authentication method defined in this document, the authentication
      key is the static KEM public key, and ID_CRED_R SHOULD contain an
      identifier of the credentials, since in the specific IKR scenario,
      the Responder’s credentials have been pre-provisioned or acquired
      out-of-band.











Pocero Fraile, et al.     Expires 12 July 2026                  [Page 8]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   *  "ID_CRED_I is intended to facilitate for the Responder retrieving
      the authentication credential CRED_I and the authentication key of
      I", as defined in Section 3.5.3 of [RFC9528].  For the
      authentication method defined in this document, the authentication
      key is the static KEM public key, and ID_CRED_I may contain the
      authentication credential CRED_R or an identifier of the
      credentials if these have been pre-provisioned or acquired out-of-
      band.

2.1.3.  Cipher Suites

   The authentication method specified in this document uses the EDHOC
   cipher suites element, as defined in Section 3.6 of [RFC9528].  An
   EDHOC cipher suit consists of an ordered set of algorithms from the
   "COSE Algorithms" IANA registry [RFC9053].  The predefined EDHOC
   cipher suites are also listed in the IANA registry, as specified in
   Section 10.2 of [RFC9528].

   A new predefined cipher suite SHOULD be added to the IANA registry,
   specifying each supported KEM in the EDHOC Key Exchange Algorithm
   parameter.  An example of this, when ML-KEM is used, is shown in
   Section 5.  The same KEM algorithm selected for key exchange SHOULD
   also be used for KEM-based authentication when method 4 is selected.
   Furthermore, the KEM algorithms used SHOULD also be added to the COSE
   Algorithms IANA registry to identify them, as is shown in Section 5.

3.  Key Derivation

   This section highlights the differences and similarities in the key
   derivation process of the KEM-based authentication method for IKR
   scenarios compared to the KEM-based authentication method on the
   general case [I-D.pocero-authkem-edhoc] and with the original EDHOC
   authentication methods described in [RFC9528].  An overview of the
   EDHOC key schedule when using the KEM-based authentication in the IKR
   scenarios method is shown in Figure 2, and each key derivation step
   is defined in the following subsections.


                +----+
                |TH_1|
                +--+-+
                   |
      +----+  +--++  +------+  +---+  +---+  +----+  +---+
      |ss_R|->|Ext|->|PRK_1e|--|Exp|->|K_1|->|AEAD|->|C_1|
      +----+  +---+  +--+---+  +--++  +---+  +--^-+  +---+
                        |         |             |
                    +---+         |         PLAINTEXT_1
                    |           +-------+-----------+



Pocero Fraile, et al.     Expires 12 July 2026                  [Page 9]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


                    |           |TH_1=H(pk_eph,ct_R)|
                    |           +---------+---------+
                    |                     |
      +------+  +---+---+  +-------+   +--+---+  +-----+
      |ss_eph|->|Extract|->|PRK_2m |---|Expand|->|MAC_2|
      +------+  +-------+  +--+----+   +------+  +-----+
                              |
                    +---------+
      +----+  +---+  +----------+  +---+   +---+   +----+  +---+
      |ss_I|->|Ext|->|PRK_2e3e3m|+-|Exp|-->|K_2|-->|AEAD|->|C_2|
      +----+  +---+  +----------+ |+--++   +---+   +-^--+  +---+
                                  |   |              |
                                  |   |         PLAINTEXT_2
                                  | +--+---------------------------+
                                  | |TH_2=H(H(Message1),ct_eph,ct_I|
                                  | +--+---------------------------+
                                  | +--+---+   +-----+
                                  +-|Expand|-->|MAC_3|
                                  | +------+   +-----+
                                  | +-------------------------------+
                                  | |TH_3=H(TH_2,PLAINTEXT_2,CRED_R)|
                                  | +--+----------------------------+
                                  |    |
                                  | +--++    +---+   +----+  +---+
                                  +-|Exp|--->|K_3|-->|AEAD|->|C_3|
                                  | +---+    +---+   +-^--+  +---+
                                  |                    |
                                  |             PLAINTEXT_3
                                  |      +---+  +---+   +----+  +---+
                                  +-m_4?-|Exp|->|K_4|-->|AEAD|->|C_4|
                                  |      +--++  +---+   +-^--+  +---+
                                  |         |             |
                                  |         |         PLAINTEXT_4
                                  | +----------+--------------------+
                                  | |TH_4=H(TH_3,PLAINTEXT_3,CRED_I)|
                                  | +----+--------------------------+
                                  |      |
                                  |  +--+--+  +-------+
                                  +--|Expand|->|PRK_out|
                                     +------+  +--+----+
                                                  |
                                               +--v---+
                                               |Expand|
                                               +------+
                                                  |
                                             +----v-------+
                                             |PRK_exporter|
                                             +---+--------+



Pocero Fraile, et al.     Expires 12 July 2026                 [Page 10]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


                                                 |
                                              +--v---+
                                              |Expand|
                                              +--+---+
                                                 |
                                                 v
                                          Aplication Key

         Figure 2: EDHOC Message Key Derivation using the KEM-based
                           Authentication Method

3.1.  Keys for EDHOC Message Processing

3.1.1.  EDHOC_Extract

   The pseudorandom keys (PRKs) used for KEM-based IKR authentication
   are derived using the same EDHOC_Extract function defined in
   [RFC9528], where the input keying material (IKM) and Salt are
   specified for each PRK below.  The usage of PRKs differs from the
   definitions in both [I-D.pocero-authkem-edhoc] and [RFC9528], and
   their names have been updated to reflect their new roles.

3.1.1.1.  PRK_1e

   The pseudorandom key PRK_1e is derived with the following input:

   *  The salt SHALL be TH_1.

   *  The IKM SHALL be the KEM shared secret (ss_R), used to
      authenticate the Responder.

   When SHA-256 is used PRK_1e is produced as follows:

   PRK_1e = HMAC-SHA-256( TH_1, ss_R )

   Where the ss_R shared secret is the output of the following functions
   in the Initiator and the Responder respectively.

   Initiator:

   ss_R, ct_R <-  KEM.Encapsulate( pk_R )

   Responder:

   ss_R <-  KEM.Decapsulate( ct_R, sk_R )






Pocero Fraile, et al.     Expires 12 July 2026                 [Page 11]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


3.1.1.2.  PRK_2m

   The pseudorandom key PRK_2m is derived with the following input:

   *  The salt SHALL be the SALT_2m derived from PRK_1e

   *  The IKM SHALL be the ephemeral KEM shared secret ss_eph

   PRk_2m is derived as follows:

   PRK_2m = EDHOC_Extract( SALT_2m, ss_eph )

   Where the ephemeral KEM shared secret ( ss_eph ) is the output of the
   following functions in the Initiator and Responder, respectively

   Initiator:

   ss_eph <-  KEM.Decapsulate( ct_eph, sk_eph )

   Responder:

   ss_eph, ct_eph <-  KEM.Encapsulate( pk_eph )

3.1.1.3.  PRK_2e3e3m

   The pseudorandom key PRK_2e3e3m is derived with the following input:

   *  The salt SHALL be the SALT_2e3m, derived from PRK_2m

   *  The IKM SHALL be the KEM shared secret ss_I, used to authenticate
      the Initiator

   PRK_2e3e3m is derived as follows:

   PRK_2e3e3m = EDHOC_Extract( SALT_2e3m, ss_I )

   Where the KEM shared secret ss_I used to authenticate the Initiator
   is the output of the following functions in the Initiator and
   Responder, respectively.

   Initiator:

   ss_I <-  KEM.Decapsulate( ct_I, sk_I )

   Responder:

   ss_I, ct_I <-  KEM.Encapsulate( pk_I )




Pocero Fraile, et al.     Expires 12 July 2026                 [Page 12]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


3.1.2.  EDHOC_Expand and EDHOC_KDF

   The output key materials (OKMs) are derived from the PRKs in the same
   way as described in Section 4.1.2 of [RFC9528], with modifications in
   some of the transcription hashes THs input contraction as specified
   in Section 4.

   The OKMs, including keys, initialization vectors (IV), and salts
   derivations using EDHOC_KDF are shown in Figure 3.

   The main difference from the original EDHOC shows in Section 4.1.2 of
   [RFC9528] Figure 6 are:

   *  A new K_1/IV_1 is computed to encrypt the message_1 which includes
      the ID_CRED_I initiator credentials, using a new transcrit hash
      (TH_1) defined as follows:

      TH_1 = H( pk_eph, ct_I )

      The AEAD encrption of message_1 with K_1/IV_1 provide integrity
      protection ensuring that the Initiator’s identity is protected
      against active attacks.  However, this does not provide
      authentication of the Initiator’s identity.

   *  K_2/IV_2 are computed to encrypt and authnticate message_2,
      derived from the PRK computed over the three shared secrets (
      ss_eph, ss_I, and ss_R )

   *  K2/IV_2, K_3/IV_3, and K_4/IV_4 are derived from the same
      PRK_2e3e4m with different THs as Info.

   *  The usage of the pseudorandom keys (PRKs) has changed, and the
      salt names have been selected to reflect their new roles
      accordingly.

   Further details of the key derivation and how the output keying
   material is used are specified in Section 4














Pocero Fraile, et al.     Expires 12 July 2026                 [Page 13]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   K_1         = EDHOC_KDF(PRK_1e,      0,  TH_1,      plaintext_length)
   IV_1        = EDHOC_KDF(PRK_1e,      1,  TH_1,      plaintext_length)
   SALT_2m     = EDHOC_KDF(PRK_1e,      2,  TH_1,      hash_length)
   MAC_2       = EDHOC_KDF(PRK_2m,      3,  context_2, mac_length_2)
   SALT_2e3e3m = EDHOC_KDF(PRK_2m,      4,  TH_2,      hash_length)
   K_2         = EDHOC_KDF(PRK_2e3e3m,  5,  TH_2,      key_length)
   IV_2        = EDHOC_KDF(PRK_2e3e3m,  6,  TH_2,      key_length)
   MAC_3       = EDHOC_KDF(PRK_2e3e3m,  7,  context_3, mac_length_3)
   K_3         = EDHOC_KDF(PRK_2e3e3m,  8,  TH_3,      key_length)
   IV_3        = EDHOC_KDF(PRK_2e3e3m,  9,  TH_3,      key_length)
   PRK_out     = EDHOC_KDF(PRK_2e3e3m,  10,  TH_4,      hash_length)
   K_4         = EDHOC_KDF(PRK_2e3e3m,  11,  TH_4,      key_length)
   IV_4        = EDHOC_KDF(PRK_2e3e3m,  12, TH_4,      iv_length)
   PRK_exporter= EDHOC_KDF(PRK_out,     13, h'',       hash_length)

        Figure 3: Key Derivations Using EDHOC_KDF for the KEM-based
                           Authentication Method

3.1.3.  PRK_out

   The pseudorandom key PRK_out is the output session key of a completed
   EDHOC session and is derived as follows:

   PRK_out = EDHOC_KDF( PRK_2e3e3m, TH_4, hash_length )

   The context include the trascription hash TH_4, defined as:

   TH_4 = H( TH_3, PLAINTEXT_3, CRED_I )

   Instead of reusing the last key-exchange internal key, the final key
   derivation depends on both PRK_2e3e3m and a newly computed TH_4,
   which include PLAINTEXT_3.  This approach aims to ensure robust
   session keys that are distinct from the MAC keys and whose
   confirmation implies the authentication of all the handshake data.

3.2.  Keys for EDHOC Applications

   Keying material for the application can be derived using the same
   EDHOC_Exporter interface defined in Section 4.2.1 of [RFC9528].

4.  Message Formatting and Processing

   This section outlines the message format and the procedures for
   composing and processing each message.







Pocero Fraile, et al.     Expires 12 July 2026                 [Page 14]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


4.1.  KEM-based Authentication EDHOC Message 1

4.1.1.  Formating of Message 1

   The message_1 SHALL be a CBOR Sequence as defined below.

   message_1 = (
     pk_eph : bstr,
     ct_R : bstr,
     CIPHERTEXT_1: bstr,
   )

4.1.2.  Initiator Composition of Message 1

   The Initiator SHALL compose message_1 as following:

   *  Construct the following elements of PLAINTEX_1:

      -  Chose KEM-based ikr authentication method 5.

      -  Construct SUITES_I following the Section 5.2.2 of [RFC9528]
         specifications

      -  Chose a connection identifier C_I and store it during the EDHOC
         session, as in Section 5.2.2 of [RFC9528]

   *  Encode PLAINTEXT_1 as a sequence of CBOR-encoded data items, as
      specified below:

      PLAINTEX_1 = (
        METHOD : int,
        SUITES_I : suites,
        ID_CRED_I : bstr/ -24..23, C_I,
        C_I : bstr / -24..23,
        ? EAD_1,
      )

   *  Generate an ephemeral KEM Key pair (pk_eph) using the KEM
      algorithm from the selected cipher suit.  The ephemeral key pair
      is computed by the Initiator using the following function:


      pk_eph, sk_eph <-  KEM.KeyGen()

   *  Encapsulate the known beforehand static KEM public key of the
      Responder (pk_R) by calculating the corresponding ciphertext
      (ct_R) and shared secret (ss_R) with the following function:




Pocero Fraile, et al.     Expires 12 July 2026                 [Page 15]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


      ss_R, ct_R <-  KEM.Encapsulate(pk_R)

   *  Compute the transcript hash TH_1 = H(pk_eph,ct_R)

   *  Compute the PRK_1e pseudorandom key from the static KEM shared
      secret ( ss_R ) used to authenticate the Responder.

   *  Compute K_1/IV1 as in Section 3.1.2

   *  Compute a COSE_Encrypt0 object as defined in Section 5.2 and 5.3
      of [RFC9052], with the EDHOC AEAD algorithm of the selected cipher
      suite, using the encryption key K_1, the initialization vector
      IV_1 (if used by the AEAD algorithm), the plaintext PLAINTEXT_1,
      and the following parameters as input:

      -  protected = h''

      -  external_aad = TH_1

      -  K_1 and IV_1 are defined in Section 3.1.2

      -  PLAINTEXT_1 = ( METHOD, SUITES_I, ID_CRED_I, C_I, ?EAD_2 )

      CIPHERTEXT_1 is the 'ciphertext' of COSE_Encrypt0.

   *  Encode message_1 as a sequence of CBOR-encoded data items as
      specified in Section 4.1.1

4.1.3.  Responder Processing of Message 1

   The Responder SHALL process message_1 in the following order:

   1.  Decode message_1

   2.  Compute the KEM shared_secret ( ss_R ) for the authentication of
       the Responder by decapsulating the KEM ciphertext (ct_R) received
       in message_1 using the Responder static KEM secret key (sk_R).
       The KEM shared secret is computed by the Responder using the
       following function:

       ss_R <-  KEM.Decapsulate( ct_R, sk_R )

   3.  Compute the transcript hash TH_1 = H(pk_eph,ct_R)

   4.  Compute the PRK_1e pseudorandom key from the static KEM shared
       secret ( ss_R ) used to authenticate the Responder.

   5.  Compute K_1/IV1 as in Section 3.1.2



Pocero Fraile, et al.     Expires 12 July 2026                 [Page 16]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   6.  Decrypt the COSE_Encrypt0 (CIPHERTEXT_1) as defined Section 5.2
       and 5.3 of [RFC9052]], with the EDHOC AEAD algorithm in the
       selected cipher suite and the parameters defined in
       Section 4.1.2.

   7.  Process PLAINTEXT_1 as specify in Section 5.2.3 of [RFC9528]

   8.  If all processing is completed successfully, then make ID_CRED_I
       and (if present) EAD_1 available to the application.

   9.  Obtain the authentication credential (CRED_I) from the
       (ID_CRED_I) and the static KEM authentication key (pk_I) of the
       Initiator

4.2.  KEM-based authentication EDHOC Message 2

4.2.1.  Formating of Message 2

   The Initiator SHALL compose message_2 as following:

   message_2 = (
     ct_eph : bstr,
     ct_I : bstr,
     CIPHERTEXT_2: bstr,
   )

4.2.2.  Responder Composition of Message 2

   The Responder SHALL compose message_2 as follows:

   *  Encapsulate the ephemeral KEM key received within message_1 using
      the KEM algorithm in the selected cipher suit.  The ephemeral KEM
      ciphertext and the KEM ephemeral shared secret are computed by the
      Responder using the following function:

       ss_eph, ct_eph <-  KEM.Encapsulate(pk_eph)

   *  Choose a connection identifier C_R and store it for the length of
      the EDHOC session.

   *  Compute the PRK_2m pseudorandom key from both the static KEM
      shared secret ( ss_R ) and the latest ephemeral KEM shared secret
      ( ss_eph ).

   *  Choose a connection identifier C_R as specified in Section 5.3.2
      of [RFC9528]





Pocero Fraile, et al.     Expires 12 July 2026                 [Page 17]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   *  Compute the transcript hash TH_2 = H( ct_eph, ct_I, H(message_1)
      ).

   *  Compute MAC_2 as defined in Section 3.1.2, with context_2 =<< C_R,
      ID_CRED_R, TH_2, CRED_R, ? EAD_2 >>

      -  The Responder authenticates with a PRK_2m derived from the KEM
         ephemeral shared secret and with the shared secret computed
         over its static KEM public key.

      -  The mac_lenght_2 is equal to the EDHOC MAC length of the
         selected cipher suit.

      -  The C_R, ID_CRED_R and CRED_R elements corresponds with the
         ones in Section 5.3.2 of [RFC9528]

      -  The latest transcript hash TH_2 and the External Application
         Data included in message_2 (EAD_2) are used.

   *  Encapsulate the retrieved static KEM authentication key of the
      Initiator ( pk_I ) calculating the corresponding ciphertext ( ct_I
      ) and shared secret ( ss_I ) with the following function:

       ss_I, ct_I <-  KEM.Encapsulate(pk_I)

   *  Compute the new PRK_2e3e3m from a chain that includes the KEM
      shared secret for the Authentication of the Responder ( ss_R ),
      the ephemeral KEM shared secret ( ss_eph ), and, the latest KEM
      shared secret for the Authentication of the Initiator ( ss_I ) as
      defined in Section 3.1.1.3

   *  Derive the session key K_2/IV2 as in Section 3.1.2.

   *  Compute a COSE_Encrypt0 object as defined in Section 5.2 and 5.3
      of [RFC9052], with the EDHOC AEAD algorithm of the selected cipher
      suite, using the encryption key K_2, the initialization vector
      IV_2 (if used by the AEAD algorithm), the plaintext PLAINTEXT_2,
      and the following parameters as input:

      -  protected = h''

      -  external_aad = TH_2

      -  K_2 and IV_2 are defined in Section 3.1.2

      -  PLAINTEXT_2 = ( C_R, ID_CRED_R, MAC_2, ?EAD_2 )

      CIPHERTEXT_2 is the 'ciphertext' of COSE_Encrypt0.



Pocero Fraile, et al.     Expires 12 July 2026                 [Page 18]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   *  Encode message_2 as a sequence of CBOR-encoded data items as
      specified in Section 4.2.1

4.2.3.  Initiator Processing of Message 2

   The Initiator SHALL process message_2 in the following order:

   1.   Decode message_2

   2.   Retrieve the protocol state as proposed in Section 5.3.3 of
        [RFC9528]

   3.   Compute the ephemeral KEM shared_secret ( ss_eph ) by
        decapsulating the KEM ciphertext (ct_eph) received in message_2
        using the ephemeral secret key (sk_eph).  The ephemeral KEM
        shared secret is computed by the Initiator using the following
        function:

       ss_eph <-  KEM.Decapsulate( ct_eph, sk_eph )

   4.   Compute the PRK_2m pseudorandom key from both the static KEM
        shared secret ( ss_R ) and the latest ephemeral KEM shared
        secret ( ss_eph )

   5.   Compute the transcript hash TH_2 = H(ct_eph,ct_I,H(message_1))

   6.   Compute the KEM shared_secret ( ss_I ) for the authentication of
        the Initiator by decapsulating the KEM ciphertext (ct_I)
        received in message_2 using the Initiator static KEM secret key
        (sk_I).  The KEM shared secret is computed by the Initiator
        using the following function:

       ss_I <-  KEM.Decapsulate( ct_I, sk_I )

   7.   Compute the new PRK_2e3e3m from a chain that includes the KEM
        shared secret for the Authentication of the Responder ( ss_R ),
        the ephemeral KEM shared secret ( ss_eph ), and the latest KEM
        shared secret for the Authentication of the Initiator ( ss_I )
        as defined in Section 3.1.1.3

   8.   Derive the session key K_2/IV2 as in Section 3.1.2.

   9.   Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_2) as defined
        Section 5.2 and 5.3 of [RFC9052]], with the EDHOC AEAD algorithm
        in the selected cipher suite and the parameters defined in
        Section 4.4.2.





Pocero Fraile, et al.     Expires 12 July 2026                 [Page 19]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   10.  Verify MAC_2 as defined in Section 4.4.2, and make the result of
        the verification available to the application.

   11.  If all processing is completed successfully, then make ID_CRED_R
        and (if present) EAD_2 available to the application as in
        Section 5.3.3 of [RFC9528]

4.3.  KEM-based authentication EDHOC Message 3

4.3.1.  Formating of Message 3

   message_3 SHALL be a CBOR Sequence as defined below

   message_3 = (
     CIPHERTEXT_3 : bstr,
   )

4.3.2.  Initiator Composition of Message 3

   The Initiator SHALL process the composition of message_3 as follows:

   *  Compute MAC_3 as defined in Section 3.1.2, with context_3 =<< C_I,
      ID_CRED_I, TH_2, CRED_I, ? EAD_3 >>

      -  The Initaiator authenticate with a PRK_2e3e3m derived from the
         three shared secrets, including the shared secret computed over
         its static KEM key ( ss_I ).

      -  The mac_lenght_3 is equal to the EDHOC MAC lenght of the
         selected cipher suit.

      -  The C_I, ID_CRED_I and CRED_I elements corresponds with the
         ones in Section 5.4.2 of [RFC9528]

      -  The latest trascript hash TH_3 and the External Aplication Data
         include it on Message 3 (EAD_3) are used it.

   *  Compute the transcript hash TH_3=H(TH_2,PLAINTEXT_2,CRED_R) as
      specified in Section 5.4.2 of [RFC9528]

   *  Derive the new session key K_3/IV_3 as defined in Section 3.1.2.

   *  Compute a COSE_Encrypt0 object as defined inSection 5.2 and 5.3 of
      [RFC9052], with the EDHOC AEAD algorithm of the selected cipher
      suite, using the encryption key K_3, the initialization vector
      IV_3 (if used by the AEAD algorithm), the plaintext PLAINTEXT_3,
      and the following parameters as input:




Pocero Fraile, et al.     Expires 12 July 2026                 [Page 20]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


      -  protected = h''

      -  external_aad = TH_3

      -  K_3 and IV_3 are defined in Section 3.1.2

      -  PLAINTEXT_3 = ( MAC_3, ?EAD_5 )

      CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.

   *  Calculate PRK_out as defined in Section 3.1.3.  The Initiator can
      now derive application keys using the EDHOC_Exporter interface;
      see Section 3.2

   *  Encode message_3 as a CBOR data item as specified in Section 4.3.1

   *  Make the connection identifiers (C_I and C_R) and the application
      algorithms in the selected cipher suite available to the
      application.

4.3.3.  Responder Processing of Message 3

   The Responder SHALL process message_3 in the following order:

   1.  Decode message_3

   2.  Retrieve the protocol state using available message correlation;
       see Section 3.4.2 of [RFC9528].

   3.  Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_3) as defined in
       Section 5.2 and 5.3 of [RFC9052], with the EDHOC AEAD algorithm
       in the selected cipher suite and the parameters defined in
       Section 4.3.2.

   4.  Verify MAC_3 as defined in Section 4.3.2, and make the result of
       the verification available to the application.

   5.  Compute the transcript hash TH_4 = H(TH_3,PLAINTEXT_3,CRED_I)

   6.  Calculate PRK_out as defined in Section 3.1.3.  The Initiator can
       now derive application keys using the EDHOC_Exporter interface;
       see Section 3.2









Pocero Fraile, et al.     Expires 12 July 2026                 [Page 21]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


4.4.  KEM-based authentication EDHOC Message 4

   This section specifies message_4, which is OPTIONAL to support.
   Confirmation of the latest pseudorandom key (PRK2e3e3m) is already
   provided by message_2 and message_3, which are encrypted with K_2/
   IV_2 and K_3/IV_3, respectively.  Either message_4 or the first
   application message from the Responder to the Initiator, protected
   using a key derived from the EDHOC_Exporter, should also ensure the
   authenticity of all prior data.  This is achieved through the use of
   a session key derived from PRK2e3e3m and the latest transcript hash
   TH_4.

4.4.1.  Formating of Message 4

   message_4 SHALL be a CBOR Sequence as defined below

   message_4 = (
     CIPHERTEXT_4 : bstr,
   )

4.4.2.  Responder Composition of Message 4

   The Responder SHALL process the composition of message_4 as follows:

   *  Derive the new session key K_4/IV_4 as defined in Section 3.1.2.

   *  Compute a COSE_Encrypt0 object as defined in Section 5.2 and 5.3
      of [RFC9052], with the EDHOC AEAD algorithm of the selected cipher
      suite, using the encryption key K_4, the initialization vector
      IV_4 (if used by the AEAD algorithm), the plaintext PLAINTEXT_4,
      and the following parameters as input:

      -  protected = h''

      -  external_aad = TH_4

      -  K_4 and IV_4 are defined in Section 3.1.2

      -  PLAINTEXT_4 = ( EAD_4 )

      CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0.

   *  Encode message_4 as a CBOR data item as specified in Section 4.4.1

4.4.3.  Initaitor Processing of Message 4

   The Initiator SHALL process message_4 in the following order:




Pocero Fraile, et al.     Expires 12 July 2026                 [Page 22]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   1.  Decode message_4

   2.  Retrieve the protocol state using available message correlation;
       see Section 3.4.2 of [RFC9528].

   3.  Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_4) as defined
       Section 5.2 and 5.3 of [RFC9052]], with the EDHOC AEAD algorithm
       in the selected cipher suite and the parameters defined in
       Section 4.4.2.

   4.  Make (if present) EAD_4 available to the application for EAD
       processing

5.  IANA Considerations

5.1.  EDHOC Method Types Registry

   The "EDHOC Method Types" Registry from group "Ephemeral Diffie-
   Hellman Over COSE (EDHOC)" SHOULD be extended with a new value that
   identifies the KEM-based authentication method.  The extension value
   from the "Standards Action with Expert Review" range, is proposed in
   Table 2

   Registry Name:  EDHOC Method Types

   Reference:  draft-lake-pocero-authkem-ikr-edhoc-01

   The columns of the registry are Value, Initiator Authentication Key,
   Responder Authentication Key and Reference, where Value is an integer
   and the other columns are text strings.  The new value proposed is:

    +=============+================+================+=================+
    | Value       | Initiator      | Responder      | Reference       |
    |             | Authentication | Authentication |                 |
    |             | Key            | Key            |                 |
    +=============+================+================+=================+
    | 7           | Static KEM Key | Static KEM Key | [draft-lake-    |
    | (suggested) | (IKR)          | (IKR)          | pocero-authkem- |
    |             |                |                | ikr-edhoc-01]   |
    +-------------+----------------+----------------+-----------------+

                        Table 2: EDHOC Method Types









Pocero Fraile, et al.     Expires 12 July 2026                 [Page 23]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


6.  Security Considerations

   The protocol design aligns with the fundamental PQNoise process
   described in [PQNoise-CCS22].  Specifically, the Initiator transmits
   its ephemeral public key in the first message, along with a key
   encapsulation targeting the Responder’s known static public key.  The
   Initiator also includes its own credentials, unknown to the
   Responder, in the first message using ID_CRED_I.  As defined in the I
   pattern of the Noise framework [Noise], this approach exposes the
   Initiator’s identity to a passive attacker.  To mitigate this, the
   Initiator’s credentials are encrypted using a key derived from the
   Responder’s static public key, ensuring that only the intended
   Responder can decrypt the credentials.

   Full forward secrecy and explicit mutual authentication are achieved
   once the KEM-based ikr EDHOC handshake is completed, as in the
   static-DH EDHOC handshake.  While this mechanism preserves the
   Initiator’s anonymity against active attackers, the identity is
   protected only by the Responder public key, which makes it vulnerable
   if the Responder’s static key is later compromised, and vulnerable to
   be replayed.

   This KEM-based authnetication method does not provide non-
   repudiation, but only implicit proof of participation as EDHOC with
   static DH keys.  It also maintains an equivalent level of downgrade
   protection, as the negotiation base of the protocol is unchanged.

7.  References

7.1.  Normative References

   [I-D.ietf-lamps-kyber-certificates]
              Turner, S., Kampanakis, P., Massimo, J., and B.
              Westerbaan, "Internet X.509 Public Key Infrastructure -
              Algorithm Identifiers for the Module-Lattice-Based Key-
              Encapsulation Mechanism (ML-KEM)", Work in Progress,
              Internet-Draft, draft-ietf-lamps-kyber-certificates-11, 22
              July 2025, <https://datatracker.ietf.org/doc/html/draft-
              ietf-lamps-kyber-certificates-11>.

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

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




Pocero Fraile, et al.     Expires 12 July 2026                 [Page 24]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


   [RFC8742]  Bormann, C., "Concise Binary Object Representation (CBOR)
              Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
              <https://www.rfc-editor.org/info/rfc8742>.

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

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

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

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

7.2.  Informative References

   [I-D.pocero-authkem-edhoc]
              Fraile, L. P., Koulamas, C., Fournaris, A. P., and E.
              Haleplidis, "KEM-based Authentication for EDHOC", Work in
              Progress, Internet-Draft, draft-pocero-authkem-edhoc-01,
              24 October 2025, <https://datatracker.ietf.org/doc/html/
              draft-pocero-authkem-edhoc-01>.

   [Noise]    Perrin, T., "The Noise Protocol Framework", Revision 34,
              July 2018, <https://noiseprotocol.org/noise.html>.

   [PQNoise-CCS22]
              Angel, Y., Dowling, B., Hulsing, A., Schwabe, P., and F.
              Weber, "Post Quantum Noise", Proceedings of the 2022 ACM
              SIGSAC Conference on Computer and Communications Security
              (CCS '22), pages 97–109. Association for Computing
              Machinery, New York, NY, USA.  DOI:
              https://doi.org/10.1145/3548606.3560577, 2022,
              <https://doi.org/10.1145/3548606.3560577>.







Pocero Fraile, et al.     Expires 12 July 2026                 [Page 25]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


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

   [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
              August 2022, <https://www.rfc-editor.org/info/rfc9053>.

Authors' Addresses

   Lidia Pocero Fraile
   ISI, R.C. ATHENA
   Cyber-physical and Networked Embedded Systems
   26504 Patras
   Greece
   Email: pocero@isi.gr


   Christos Koulamas
   ISI, R.C. ATHENA
   Cyber-physical and Networked Embedded Systems
   26504 Patras
   Greece
   Email: koulamas@isi.gr


   Apostolos P. Fournaris
   ISI, R.C. ATHENA
   Security and Protection of Systems, Networks and Infrastructures
   26504 Patras
   Greece
   Email: fournaris@isi.gr


   Evangelos Haleplidis
   ISI, R.C. ATHENA
   Department of Digital Systems
   26504 Patras
   Greece
   Email: haleplidis@isi.gr










Pocero Fraile, et al.     Expires 12 July 2026                 [Page 26]


name: draft-ietf-lamps-attestation-freshness
rev: 05
time: 2025-10-19T10:32:22Z
group_uri: /api/v1/group/group/2164/
expires: 2026-04-22T10:32:22Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:09.014887+00:00
title:
Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP), for Enrollment over Secure Transport (EST), and for Certificate Management over CMS (CMC)

abstract:
When an end entity includes attestation Evidence in a Certificate
   Signing Request (CSR), it may be necessary to demonstrate the
   freshness of the provided Evidence.  Current attestation technology
   commonly achieves this using nonces.

   This document outlines the process through which nonces are supplied
   to the end entity by an RA/CA for inclusion in Evidence, leveraging
   the Certificate Management Protocol (CMP), Enrollment over Secure
   Transport (EST), and Certificate Management over CMS (CMC).

full_text:
LAMPS Working Group                                        H. Tschofenig
Internet-Draft                                              H. Brockhaus
Intended status: Standards Track                                 Siemens
Expires: 22 April 2026                                         J. Mandel
                                                                  AKAYLA
                                                               S. Turner
                                                                   sn3rd
                                                         19 October 2025


  Nonce-based Freshness for Remote Attestation in Certificate Signing
  Requests (CSRs) for the Certification Management Protocol (CMP), for
 Enrollment over Secure Transport (EST), and for Certificate Management
                             over CMS (CMC)
               draft-ietf-lamps-attestation-freshness-05

Abstract

   When an end entity includes attestation Evidence in a Certificate
   Signing Request (CSR), it may be necessary to demonstrate the
   freshness of the provided Evidence.  Current attestation technology
   commonly achieves this using nonces.

   This document outlines the process through which nonces are supplied
   to the end entity by an RA/CA for inclusion in Evidence, leveraging
   the Certificate Management Protocol (CMP), Enrollment over Secure
   Transport (EST), and Certificate Management over CMS (CMC).

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 22 April 2026.







Tschofenig, et al.        Expires 22 April 2026                 [Page 1]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Requirements Language . . . . . . . . . . . .   5
   3.  Conveying a Nonce in CMP  . . . . . . . . . . . . . . . . . .   5
   4.  Conveying a Nonce in EST  . . . . . . . . . . . . . . . . . .   9
     4.1.  Request Methods . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  Request Payload (POST)  . . . . . . . . . . . . . . . . .  10
       4.2.1.  Example GET . . . . . . . . . . . . . . . . . . . . .  10
       4.2.2.  Example POST  . . . . . . . . . . . . . . . . . . . .  10
     4.3.  Server Response . . . . . . . . . . . . . . . . . . . . .  11
   5.  Conveying a Nonce in CMC  . . . . . . . . . . . . . . . . . .  12
     5.1.  Generic Nonce Request Message Flow  . . . . . . . . . . .  12
   6.  Nonce Processing Guidelines . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  15
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     10.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   The management of certificates, encompassing issuance, CA certificate
   provisioning, renewal, and revocation, has been streamlined through
   standardized protocols.









Tschofenig, et al.        Expires 22 April 2026                 [Page 2]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


   The Certificate Management Protocol (CMP) [I-D.ietf-lamps-rfc4210bis]
   defines messages for X.509v3 certificate creation and management.
   CMP facilitates interactions between end entities and PKI management
   entities, such as Registration Authorities (RAs) and Certification
   Authorities (CAs).  For Certificate Signing Requests (CSRs), CMP
   primarily utilizes the Certificate Request Message Format (CRMF)
   [RFC4211] but also supports PKCS#10 [RFC2986].

   Enrollment over Secure Transport (EST) ([RFC7030], [RFC8295]) is
   another certificate management protocol that provides a subset of
   CMP's features, primarily using PKCS#10 for CSRs.

   Certificate Management over CMS (CMC) [I-D.ietf-lamps-rfc5272bis] is
   a certificate management protocol using the Cryptographic Message
   Syntax (CMS).

   When an end entity requests a certificate from a Certification
   Authority (CA), it may need to assert credible claims about the
   protections of the corresponding private key, such as the use of a
   hardware security module or the protective capabilities provided by
   the hardware, as well as claims about the platform itself.

   To include these claims as Evidence in remote attestation, the remote
   attestation extension [I-D.ietf-lamps-csr-attestation] has been
   defined.  It specifies how Evidence produced by an Attester is
   encoded for inclusion in CRMF or PKCS#10, along with any necessary
   certificates for its validation.

   For a Verifier or Relying Party to ensure the freshness of the
   Evidence, knowing the exact time of its production is crucial.
   Current attestation technologies, like [TPM20] and [RFC9783], often
   employ nonces to ensure the freshness of Evidence.  Further details
   on ensuring Evidence freshness can be found in Section 10 of
   [RFC9334].

   Section 4 of [I-D.ietf-lamps-csr-attestation] provides examples where
   a CSR contains one or more Evidence statements.  For each Evidence
   statement the end entity may wish to request a separate nonce.

   Since an end entity requires one or more nonces from one or more
   Verifiers via the RA/CA, an additional roundtrip is necessary.
   However, a CSR is a one-shot message.  Therefore, CMP, EST, and CMC
   enable the end entity to request information from the RA/CA before
   submitting a certification request conveniently.







Tschofenig, et al.        Expires 22 April 2026                 [Page 3]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


   Once a nonce is obtained, the end entity invokes the API on an
   Attester, providing the nonce as an input parameter.  The Attester
   then returns Evidence, which is embedded into a CSR and potentially
   together with further Evidence statements, submitted back to the RA/
   CA in a certification request message.

   Figure 1 illustrates this interaction:

   *  One or more nonces are requested in step (0) and obtained in step
      (1) using the extension to CMP/EST/CMC defined in this document.

   *  The CSR extension [I-D.ietf-lamps-csr-attestation] conveys one or
      more Evidence statements to the RA/CA in step (2).

   *  One or more Verifiers process the received Evidence and return the
      Attestation Result(s) to the Relying Party.  The CA uses the
      Attestation Result(s) with the Appraisal Policy and other
      information to create the requested certificate.  The certificate
      is returned to the End Entity in step (3).

   Attester                 Relying Party            One or more
   (End Entity)             (RA/CA)                   Verifier
       |                         |                        |
       |  Certificate            |                        |
       |  Management             |                        |
       |  Protocol               |                        |
       |<----------------------->|                        |
       |                         |                        |
       |                         |                        |
       |  Request Nonce(s)(0)    |                        |
       |------------------------>|                        |
       |                         |  Request Nonce(s)      |
       |                         |----------------------->|
       |                         |  Nonce(s)              |
       |                         |<-----------------------|
       |  Nonce(s) (1)           |                        |
       |<------------------------|                        |
       |                         |                        |
       |  Attested CSR (2)       |                        |
       |------------------------>|                        |
       |                         |  Evidence(s)           |
       |                         |----------------------->|
       |                         |  Attestation Result(s) |
       |                         |<-----------------------|
       |  Certificate (3)        |                        |
       |<------------------------|                        |
       |                         |                        |
       |                         |                        |



Tschofenig, et al.        Expires 22 April 2026                 [Page 4]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


            Figure 1: Architecture with Background Check Model.

   The functionality described in this document is divided into three
   sections:

   *  Section 3 describes how to convey the nonce using CMP.

   *  Section 4 describes the equivalent functionality for EST.

   *  Section 5 describes the equivalent functionality for CMC.

2.  Terminology and Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   The terms Attester, Relying Party, Verifier and Evidence are defined
   in [RFC9334].  The terms end entity, certification authority (CA),
   and registration authority (RA) are defined in [RFC5280].

   We use the terms Certificate Signing Request (CSR) and certification
   request interchangeably.

3.  Conveying a Nonce in CMP

   Section 5.3.19 of [I-D.ietf-lamps-rfc4210bis] defines the general
   request message (genm) and general response (genp).  The NonceRequest
   payload of the genm message, sent by the end entity to request a
   nonce, optionally includes details on the required length of the
   nonce from the Attester.  The NonceResponse payload of the genp
   message, sent by the CA/RA in response to the request, contains the
   nonce itself.


















Tschofenig, et al.        Expires 22 April 2026                 [Page 5]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


    GenMsg:    {id-it TBD1}, NonceRequestValue
    GenRep:    {id-it TBD2}, NonceResponseValue | < absent >

    id-it-nonceRequest OBJECT IDENTIFIER ::= { id-it TBD1 }
    NonceRequestValue ::= SEQUENCE SIZE (1..MAX) OF NonceRequest
    NonceRequest ::= SEQUENCE {
       len INTEGER OPTIONAL,
       -- indicates the required length of the requested nonce
       type EVIDENCE-STATEMENT.&id({EvidenceStatementSet}) OPTIONAL,
       -- indicates which Evidence type to request a nonce for
       hint UTF8String OPTIONAL
       -- indicates which Verifier to request a nonce from
    }

    id-it-nonceResponse OBJECT IDENTIFIER ::= { id-it TBD2 }
    NonceResponseValue ::= SEQUENCE SIZE (1..MAX) OF NonceResponse
    NonceResponse ::= SEQUENCE {
       nonce OCTET STRING,
       -- contains the nonce of length len
       -- provided by the Verifier indicated with hint
       expiry INTEGER OPTIONAL,
       -- indicates how long in seconds the Verifier considers
       -- the nonce valid
       type EVIDENCE-STATEMENT.&id({EvidenceStatementSet}) OPTIONAL,
       -- indicates which Evidence type to request a nonce for
       hint UTF8String OPTIONAL
       -- indicates which Verifier to request a nonce from
    }

   The end entity may request one or more nonces for different
   Verifiers.  The EVIDENCE-STATEMENT type is defined in
   [I-D.ietf-lamps-csr-attestation].  It allows the Attester to specify
   to the Relying Party which Verifier should be contacted to obtain a
   nonce.  If a NonceRequest structure does not contain type or hint,
   the RA/CA MAY generate a nonce itself and include it in the response.

   The use of the general request/response message exchange introduces
   an additional round trip for transmitting nonce(s) from the CA/RA to
   the end entity (and subsequently to the Attester within the end
   entity).











Tschofenig, et al.        Expires 22 April 2026                 [Page 6]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


   The end entity MUST construct an id-it-nonceRequest message to prompt
   the RA/CA to send one or more nonces in response.  The message may
   contain one or more NonceRequest structures, at a maximum one per
   Evidence statement the end entity wishes to provide in a CSR.  If a
   NonceRequest structure does neither contain a type nor a hint, the
   RA/CA MAY generate a nonce itself and provide it in the respective
   NonceResponse structure.  If an RA/CA is not able to provide a
   requested nonce, it MUST provide an empty OCTET STRING in the
   respective NonceResponse structure.

   NonceRequest, NonceResponse, and EvidenceStatement structures can
   contain a type field and a hint field.  In terms of type and hint
   content, the order in which the NonceRequest structures were sent in
   the request message MUST match the order of the NonceResponse
   structures in the response message and the EvidenceStatements in the
   CSR later.  This matching ensures that the RA/CA can send each
   Evidence statement to the same Verifier that generated the
   corresponding nonce used by the Attester.

   When receiving nonces from the RA/CA in an id-it-nonceResponse
   message, the end entity MUST use them to request Evidence statements
   from the respective Attester, as optionally indicated by type and
   hint.  If a nonce is provided in a NonceResponse structure without
   indicating any type or hint, it can be used for all Evidence
   statements requiring a nonce.

   An Evidence statement generated using a nonce provided with an expiry
   value will be accepted by the Verifier as valid until the respective
   expiry time has elapsed.  It is expected that the respective messages
   are delivered in a timely manner.

   The interaction is illustrated in Figure 2.



















Tschofenig, et al.        Expires 22 April 2026                 [Page 7]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


   End Entity                                          RA/CA
   ==========                                      =============

               ------- id-it-NonceRequest ----->
                                                   Verify request
                                                   Generate nonce(s)*
                                                   Create response
               <------ id-it-NonceResponse -----
                       (nonce(s), expiry)

   Generate key pair
   Generate Evidence(s)*
   Generate certification
     request message
               ------- certification request --->
                   +Evidence(s) including nonce)
                                                  Verify request
                                                  Verify Evidence(s)*
                                                  Check for replay*
                                                  Issue certificate
                                                  Create response
               <------ certification response ---
   Handle response
   Store certificate

   *: These steps require interactions with the Attester
   (on the EE side) and with the Verifier (on the RA/CA side).

              Figure 2: CMP Exchange with Nonce and Evidence.

   If HTTP is used to transfer the NonceRequest and NonceResponse
   messages, the OPTIONAL <operation> path segment defined in
   Section 3.6 of [I-D.ietf-lamps-rfc4210bis] MAY be used.

    +------------------------+-----------------+-------------------+
    | Operation              |Operation path   | Details           |
    +========================+=================+===================+
    | Get Attestation        | getnonce        | {{CMP}}           |
    | Freshness Nonce        |                 |                   |
    +------------------------+-----------------+-------------------+

   If CoAP is used for transferring NonceRequest and NonceResponse
   messages, the OPTIONAL <operation> path segment defined in
   Section 2.1 of [RFC9482] MAY be used.







Tschofenig, et al.        Expires 22 April 2026                 [Page 8]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


    +------------------------+-----------------+-------------------+
    | Operation              |Operation path   | Details           |
    +========================+=================+===================+
    | Get Attestation        | nonce           | {{CMP}}           |
    | Freshness Nonce        |                 |                   |
    +------------------------+-----------------+-------------------+

4.  Conveying a Nonce in EST

   The EST client requests one or more nonces for its Attester from the
   EST server.  This function typically follows the request for CA
   certificates and precedes other EST operations.

   The EST server MUST support the path-prefix of "/.well-known/" as
   defined in [RFC5785] and the registered name of "est".  Therefore, a
   valid EST server URI path begins with "https://www.example.com/.well-
   known/est".  Each EST operation is indicated by a path-suffix that
   specifies the intended operation.

   The following operation is defined by this specification:

    +------------------------+-----------------+-------------------+
    | Operation              |Operation path   | Details           |
    +========================+=================+===================+
    | Retrieval of a nonce   | /nonce          | {{EST}}           |
    +------------------------+-----------------+-------------------+

   The operation path is appended to the path-prefix to form the URI
   used with HTTP GET or POST to perform the desired EST operation.  An
   example of a valid URI absolute path for the "/nonce" operation is
   "/.well-known/est/nonce".

4.1.  Request Methods

   An EST client uses either a GET or a POST method, depending on
   whether additional parameters need to be conveyed:

   *  A GET request MUST be used when the EST client does not want to
      convey extra parameters.

   *  A POST request MUST be used when parameters, such as nonce length
      or a hint about the verification service, are included in the
      request.








Tschofenig, et al.        Expires 22 April 2026                 [Page 9]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


    +------------------+------------------------------+---------------+
    | Message type     | Media type(s)                | Reference     |
    | (per operation)  |                              |               |
    +==================+==============================+===============+
    | Nonce Request    | N/A (for GET) or             | This section  |
    |                  | application/json (for POST)  |               |
    +==================+==============================+===============+
    | Nonce Response   | application/json             | This section  |
    |                  |                              |               |
    +==================+==============================+===============+

4.2.  Request Payload (POST)

   The payload in a POST request MUST be of content-type "application/
   json" and MUST contain an array of JSON objects [RFC8259] with the
   optional members "len", "type", and "hint".

   *  The optional "len" member indicates the length of the requested
      nonce value in bytes.

   *  The optional "type" member contains an EvidenceStatement OID
      (dotted-decimal string) as defined in
      [I-D.ietf-lamps-csr-attestation].

   *  The optional "hint" member contains an FQDN or URI identifying the
      Verifier, following the EvidenceHint structure as defined in
      [I-D.ietf-lamps-csr-attestation].

   The order of objects in the JSON array is significant and MUST be
   preserved by the server.  The response array MUST contain the same
   number of elements in the same order so clients can correlate
   requests and responses by array index.

4.2.1.  Example GET

   GET /.well-known/est/nonce HTTP/1.1

4.2.2.  Example POST

   To retrieve one or more nonces while optionally specifying the
   length, type, and/or hint:










Tschofenig, et al.        Expires 22 April 2026                [Page 10]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


   POST /.well-known/est/nonce HTTP/1.1
   Content-Type: application/json
   [
     {
       "len": 8,
       "type": "1.2.3.4.5",
       "hint": "https://example.com"
     }
   ]

4.3.  Server Response

   If successful, the EST server MUST respond with an HTTP 200 status
   code and a content-type of "application/json", containing an array of
   JSON objects [RFC8259] with the "nonce" member.  The "expiry" member
   is optional and indicates the absolute expiry time of the nonce
   encoded as an RFC 3339 timestamp string.  The optional "type" and
   "hint" members MAY be copied from the request to aid correlation.

   Note: CMP encodes "expiry" as an INTEGER representing seconds of
   validity.  EST encodes "expiry" as an absolute timestamp.

   Below is an example response:

   HTTP/1.1 200 OK
   Content-Type: application/json
   [
     {
       "nonce": "MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=",
       "expiry": "2031-10-12T07:20:50.52Z",
       "type": "1.2.3.4.5",
       "hint": "https://example.com"
     }
   ]

   The EST server MAY request HTTP-based client authentication, as
   explained in Section 3.2.3 of [RFC7030].

   Open Issue: Should a specific content type be registered for use with
   EST over CoAP, where the nonce and expiry fields are encoded in a
   CBOR structure?










Tschofenig, et al.        Expires 22 April 2026                [Page 11]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


5.  Conveying a Nonce in CMC

   CMC defines Simple and Full PKI Requests for the client to use to
   request a certificate.  Full PKI Requests provide the client with
   more functionality through the use of Controls, defined in Section 6
   of [I-D.ietf-lamps-rfc5272bis].  Currently, the client sends an
   initial request containing a certification request (CRMF, PKCS#10, or
   other).  To allow the client to request a nonce prior to sending a
   certification request, this section defines the nonceReq and
   nonceResp.

   Generally a Full PKI Request is encapsulated in a SignedData or
   AuthenticatedData with an encapsulated content type of 'id-cct-
   PKIData'.  To accommodate a generic request for a nonce, the Client/
   Server SHOULD use the Data content type; id-data, to transmit the
   nonceReq and nonceResp controls.  The syntax for the controls uses
   the same syntax as the CMP information types defined in Section 3.

   The NonceRequest control is identified by:

   id-cmc-nonceReq OBJECT IDENTIFIER ::= { id-it TBD1 }

   The NonceResponse control is identified by: ~~~ id-cmc-nonceResp
   OBJECT IDENTIFIER ::= { id-it TBD2 } ~~~

5.1.  Generic Nonce Request Message Flow

   The client sends id-cmc-nonceReq structure to the server.  Upon
   receiving and processing the request, the server responds with id-
   cmc-nonceResp.

   Once this round-trip transaction is complete, the client will include
   the nonce in either a Simple or Full PKI Request.

   Client to Server: ~~~ ContentInfo.contentType = id-Data
   ContentInfo.content eContentType = id-cct-PKIData eContent
   controlSequence {101, id-cmc-senderNonce, 10001} {102, id-cmc-
   nonceReq, <sequence of nonce request>} ~~~

   Server to Client: ~~~ ContentInfo.contentType = id-Data
   ContentInfo.content eContentType = id-cct-PKIData eContent
   controlSequence {101, id-cmc-senderNonce, 10005} {102, id-cmc-
   recipientNonce, 10001} {103, id-cmc-nonceResp, <sequence of nonce
   response>} ~~~







Tschofenig, et al.        Expires 22 April 2026                [Page 12]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


6.  Nonce Processing Guidelines

   When the RA/CA is requested to provide a nonce to an end entity, it
   interacts with the Verifier.  According to the IETF RATS architecture
   [RFC9334], the Verifier is responsible for validating Evidence about
   an Attester and generating Attestation Results for use by a Relying
   Party.  The Verifier also acts as the source of the nonce to prevent
   replay attacks.

   The nonce value MUST contain a random byte sequence with at least 64
   bits of entropy.  The RA/CA MUST ensure that nonces are unique and
   MUST NOT be reused.  The length of the nonce depends on the remote
   attestation technology in use, as specific nonce lengths may be
   required by the end entity.  This specification assumes that the RA/
   CA possesses knowledge, either out-of-band or through the len field
   in the NonceRequest, regarding the required nonce length for the
   attestation technology.  Nonces of incorrect length will cause the
   remote attestation protocol to fail.

   For instance, the PSA attestation token [RFC9783] supports nonce
   lengths of 32, 48, and 64 bytes.  Other attestation technologies
   employ nonces of similar lengths.

   If a specific length was requested, the RA/CA MUST provide a nonce of
   that size.  The end entity MUST use the received nonce if the remote
   attestation supports the requested length.  If necessary, the end
   entity MAY adjust the length of the nonce by truncating or padding it
   accordingly.

   While this specification does not address the semantics of the
   attestation API or the underlying software/hardware architecture, the
   API returns Evidence from the Attester in a format specific to the
   attestation technology used and specified by the type and hint.  The
   returned Evidence is encapsulated within the CSR, as defined in
   [I-D.ietf-lamps-csr-attestation].  The software generating the CSR
   treats the Evidence as an opaque blob and does not interpret its
   format.  It's crucial to note that the nonce is included in the
   Evidence, either implicitly or explicitly, and MUST NOT be conveyed
   in CSR structures outside of the Evidence payload.

   The processing of CSRs containing Evidence is detailed in
   [I-D.ietf-lamps-csr-attestation].  Importantly, certificates issued
   based on this process do not contain the nonce, as specified in
   [I-D.ietf-lamps-csr-attestation].







Tschofenig, et al.        Expires 22 April 2026                [Page 13]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


7.  IANA Considerations

   This document adds new entries to the "CMP Well-Known URI Path
   Segments" registry defined in [RFC8615].

    +----------------+---------------------------+-----------------+
    | Path Segment   | Description               | Reference       |
    +================+===========================+=================+
    | getnonce       | Get Attestation Freshness | {{CMP}}         |
    |                | Nonce over HTTP           |                 |
    +----------------+---------------------------+-----------------+
    | nonce          | Get Attestation Freshness | {{CMP}}         |
    |                | Nonce over CoAP           |                 |
    +----------------+---------------------------+-----------------+

   [Open Issue: Register path segments for EST]

   IANA is also requested to register the following ASN.1 [X.680] module
   OID in the "SMI Security for PKIX Module Identifier" registry
   (1.3.6.1.5.5.7.0).  This OID is defined in Appendix A.

              +=========+======================+============+
              | Decimal | Description          | References |
              +=========+======================+============+
              | TBDMOD  | id-mod-att-fresh-req | This-RFC   |
              +---------+----------------------+------------+

                                  Table 1

8.  Security Considerations

   This specification details the process of obtaining a nonce via CMP,
   EST, and CMC, assuming that the nonce does not require
   confidentiality protection while maintaining the security properties
   of the remote attestation protocol.  [RFC9334] defines the IETF
   remote attestation architecture and extensively discusses nonce-based
   freshness.

   Section 8.4 of [RFC9711] specifies requirements for the randomness
   and privacy of nonce generation when used with the Entity Attestation
   Token (EAT).  These requirements, which are also adopted by
   attestation technologies like the PSA attestation token [RFC9783],
   provide general utility:

   *  The nonce MUST have at least 64 bits of entropy.






Tschofenig, et al.        Expires 22 April 2026                [Page 14]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


   *  To prevent disclosure of privacy-sensitive information, it should
      be derived using a salt from a genuinely random number generator
      or another reliable source of randomness.

   Each attestation technology specification offers guidance on replay
   protection using nonces and other techniques.  Specific
   recommendations are deferred to these individual specifications in
   this document.

   Regarding the use of Evidence in a CSR, the security considerations
   outlined in [I-D.ietf-lamps-csr-attestation] are pertinent to this
   specification.

9.  Acknowledgments

   We would like to thank Russ Housley, Thomas Fossati, Watson Ladd,
   Ionut Mihalcea, Carl Wallace, and Michael StJohns for their review
   comments.

10.  References

10.1.  Normative References

   [I-D.ietf-lamps-csr-attestation]
              Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M.,
              and N. Smith, "Use of Remote Attestation with
              Certification Signing Requests", Work in Progress,
              Internet-Draft, draft-ietf-lamps-csr-attestation-21, 5
              October 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-lamps-csr-attestation-21>.

   [I-D.ietf-lamps-rfc4210bis]
              Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
              "Internet X.509 Public Key Infrastructure -- Certificate
              Management Protocol (CMP)", Work in Progress, Internet-
              Draft, draft-ietf-lamps-rfc4210bis-18, 30 January 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              rfc4210bis-18>.

   [I-D.ietf-lamps-rfc5272bis]
              Mandel, J. and S. Turner, "Certificate Management over CMS
              (CMC)", Work in Progress, Internet-Draft, draft-ietf-
              lamps-rfc5272bis-08, 29 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              rfc5272bis-08>.






Tschofenig, et al.        Expires 22 April 2026                [Page 15]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


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

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

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              DOI 10.17487/RFC5785, April 2010,
              <https://www.rfc-editor.org/rfc/rfc5785>.

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

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8259>.

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

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8615>.

   [RFC9482]  Sahni, M., Ed. and S. Tripathi, Ed., "Constrained
              Application Protocol (CoAP) Transfer for the Certificate
              Management Protocol", RFC 9482, DOI 10.17487/RFC9482,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9482>.

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








Tschofenig, et al.        Expires 22 April 2026                [Page 16]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


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

10.2.  Informative References

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

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

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

   [RFC9711]  Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
              Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
              DOI 10.17487/RFC9711, April 2025,
              <https://www.rfc-editor.org/rfc/rfc9711>.

   [RFC9783]  Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T.
              Fossati, "Arm's Platform Security Architecture (PSA)
              Attestation Token", RFC 9783, DOI 10.17487/RFC9783, June
              2025, <https://www.rfc-editor.org/rfc/rfc9783>.

   [TPM20]    Trusted Computing Group, "Trusted Platform Module Library
              Specification, Family 2.0, Level 00, Revision 01.59",
              November 2019,
              <https://trustedcomputinggroup.org/resource/tpm-library-
              specification/>.

Appendix A.  ASN.1 Module

   The following module adheres to ASN.1 specifications [X.680] and
   [X.690].








Tschofenig, et al.        Expires 22 April 2026                [Page 17]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


   <CODE BEGINS>

   att-fresh-req
     { iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) id-mod(0)
     id-mod-att-fresh-req (TBDMOD) }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN
   EXPORTS ALL;
   IMPORTS

   id-it, InfoTypeAndValue{}
     FROM PKIXCMP-2023
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-cmp2023-02(TBD-PKIXCMP-23) }
   -- RFC Editor: The value for id-mod-cmp2023-02 must be set as soon
   -- as it is assigned by I-D.ietf-lamps-rfc4210bis

   EVIDENCE-STATEMENT, EvidenceStatementSet
     FROM CSR-ATTESTATION-2023
       { iso(1) identified-organization(3) dod(6) internet(1) security(5)
         mechanisms(5) pkix(7) id-mod(0) id-mod-pkix-attest-01(TBD-CSR-ATTESTATION-2023) }
   -- RFC Editor: The value for id-mod-pkix-attest-01 must be set as soon
   -- as it is assigned by I-D.ietf-lamps-csr-attestation

   CMC-CONTROL
   FROM EnrollmentMessageSyntax-2025
      { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-enrollMsgSyntax-2025(TBD1) }

   ;

   -- NonceRequest and NonceResponse messages

    id-it-nonceRequest OBJECT IDENTIFIER ::= { id-it TBD1 }
    NonceRequestValue ::= SEQUENCE SIZE (1..MAX) OF NonceRequest
    NonceRequest ::= SEQUENCE {
       len    INTEGER OPTIONAL,
       -- indicates the required length of the requested nonce
       type   EVIDENCE-STATEMENT.&id({EvidenceStatementSet}) OPTIONAL,
       -- indicates which Evidence type to request a nonce for
       hint   UTF8String OPTIONAL
       -- indicates which Verifier to request a nonce from
    }




Tschofenig, et al.        Expires 22 April 2026                [Page 18]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


    id-it-nonceResponse OBJECT IDENTIFIER ::= { id-it TBD2 }
    NonceResponseValue ::= SEQUENCE SIZE (1..MAX) OF NonceResponse
    NonceResponse ::= SEQUENCE {
       nonce  OCTET STRING,
       -- contains the nonce of length len
       -- provided by the Verifier indicated with hint
       expiry INTEGER OPTIONAL,
       -- indicates how long in seconds the Verifier considers
       -- the nonce valid
       type   EVIDENCE-STATEMENT.&id({EvidenceStatementSet}) OPTIONAL,
       -- indicates which Evidence type to request a nonce for
       hint UTF8String OPTIONAL
       -- indicates which Verifier to request a nonce from
    }

   id-cmc-nonceReq ::= { id-it TBD1 }

   cmc-nonceReq CMC-CONTROL ::=
         { NonceRequest IDENTIFIED BY id-cmc-nonceReq }

   id-cmc-nonceResp ::= { id-it TBD2 }

   cmc-nonceResp CMC-CONTROL ::=
         { NonceResponse IDENTIFIED BY id-cmc-nonceResp }

   END
   <CODE ENDS>

Authors' Addresses

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


   Hendrik Brockhaus
   Siemens
   Werner-von-Siemens-Strasse 1
   80333 Munich
   Germany
   Email: hendrik.brockhaus@siemens.com
   URI:   https://www.siemens.com


   Joe Mandel
   AKAYLA, Inc.
   Email: joe@akayla.com



Tschofenig, et al.        Expires 22 April 2026                [Page 19]

Internet-Draft   Freshness Nonces for Remote Attestation    October 2025


   Sean Turner
   sn3rd
   Email: sean@sn3rd.com
















































Tschofenig, et al.        Expires 22 April 2026                [Page 20]


name: draft-chen-lake-edhoc-aka
rev: 01
title: EDHOC Authenticated with AKA
time: 2025-10-20T02:51:53Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T02:51:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:09.014892+00:00
abstract:
This document defines the EDHOC-AKA authentication method based on
   the Authentication and Key Agreement(AKA) protocol and the Ephemeral
   Diffie-Hellman Over COSE(EDHOC) key exchange protocol.  This method
   is designed to provide efficient mobile communication network access
   authentication for scenarios with limited computing and network
   resources (such as Non-Terrestrial Network, NTN).  EDHOC-AKA utilizes
   the pre-shared long-term key and employs symmetric cryptography
   techniques to achieve mutual authentication and key derivation.  It
   ensures security while significantly enhancing the authentication
   efficiency.

full_text:
Internet Engineering Task Force                                  M. Chen
Internet-Draft                                                     L. Su
Intended status: Standards Track                            China Mobile
Expires: 23 April 2026                                   20 October 2025


                      EDHOC Authenticated with AKA
                      draft-chen-lake-edhoc-aka-01

Abstract

   This document defines the EDHOC-AKA authentication method based on
   the Authentication and Key Agreement(AKA) protocol and the Ephemeral
   Diffie-Hellman Over COSE(EDHOC) key exchange protocol.  This method
   is designed to provide efficient mobile communication network access
   authentication for scenarios with limited computing and network
   resources (such as Non-Terrestrial Network, NTN).  EDHOC-AKA utilizes
   the pre-shared long-term key and employs symmetric cryptography
   techniques to achieve mutual authentication and key derivation.  It
   ensures security while significantly enhancing the authentication
   efficiency.

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 23 April 2026.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights



Chen & Su                 Expires 23 April 2026                 [Page 1]

Internet-Draft                EDHOC PSK AKA                 October 2025


   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  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Credentials . . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.1.  CRED_AKA_X  . . . . . . . . . . . . . . . . . . . . .   4
       3.1.2.  Encoding and processing . . . . . . . . . . . . . . .   4
     3.2.  Message Flow of EDHOC-AKA . . . . . . . . . . . . . . . .   4
   4.  Key Derivation  . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Message Formating and Processing  . . . . . . . . . . . . . .   6
     5.1.  Message1  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Message2  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.3.  Message3  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.4.  Message4  . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   This document defines a AKA authentication method for the Ephemeral
   Diffie-Hellman Over COSE (EDHOC) key exchange protocol [RFC9528].
   AKA is a symmetric ciper, it achieves key agreement through mutual
   authentication between the mobile users and networks, and
   subsequently generates data encryption keys and integrity protection
   keys.  In this document, Initiator stands for the mobile user and
   Responder stands for the network.  AKA relies on long-term keys which
   is provided out-of-band and realize dynamic symmetric key derivation.
   Symmetric key authentication offers greater computational efficiency
   compared to the methods outlined in [RFC9528].

   The Authentication and Key Agreement (AKA) is an authentication
   mechanism for devices wishing to access mobile networks.  [RFC4187]
   (EAP-AKA) made the use of this mechanism possible within the
   Extensible Authentication Protocol (EAP) framework.  [RFC5448] (EAP-
   AKA') was an improved version of EAP-AKA.  [RFC9048]is the most
   recent specification of EAP-AKA'related to 5G networks.







Chen & Su                 Expires 23 April 2026                 [Page 2]

Internet-Draft                EDHOC PSK AKA                 October 2025


   The parameters in the authentication vectors of EDHOC-AKA and EAP-
   AKA' are remain consistent and defined in the new field CRED_AKA_X.
   This document only considers two parties and the interaction between
   networks is out of scope.

2.  Terminology

   The following terms are used:

   *  AKA: Authentication and Key Agreement.

3.  Protocol

   This document specifies a new EDHOC authentication method (see
   Section 3.2 of [RFC9528]) referred to as the Authentication and Key
   Agreement method for the Ephemeral Diffie-Hellman Over COSE key
   exchange protocol (EDHOC-AKA).  Authentication is based on a long-
   term key shared between the Initiator and the Responder.  As in the
   methods defined in [RFC9528], CRED_I and CRED_R are authentication
   credentials containing identifying information for the Initiator and
   Responder, respectively.  We defined CRED_AKA_I and CRED_AKA_R to
   hold the authentication vector of AKA for the Initiator and
   Responder, respectively.  We have added a new method to indicate that
   the Initiator and Responder support AKA authentication.

3.1.  Credentials

   According to RFC 9528 and the existing specifications of AKA,
   designing a new authentication method ( Method = 5)and defining new
   credential parameter CRED_AKA_X, it is necessary to ensure that the
   Initiator (I) and the Responder (R) meet the following core
   requirements:

   *  The Initiator and Responder are assumed to share a long-term key,
      or it is possible to obtain the derived parameters indirectly.

   *  The explicit indication of the authentication method is AKA, and
      it also carries the necessary identity credential information.

   The requirements for Initiator

   *  The long-term key K and user identifier must be pre-set and stored
      in a secure environment.

   *  Support the capability of generating the 5-tuple of AKA
      (RAND/AUTN/XRES/CK/IK).

   The requirements for Responder



Chen & Su                 Expires 23 April 2026                 [Page 3]

Internet-Draft                EDHOC PSK AKA                 October 2025


   *  Based on the SUPI/SUCI in EAD_1, route to the network, the
      division between the visiting network and the home network is out
      of scope.

   *  Obtain the AKA five-tuple (or generate dynamic vector) from
      network

3.1.1.  CRED_AKA_X

   CRED_AKA is a COSE header map containing header parameters that
   indicate the AKA authentication parameters.  CRED_AKA_X is uesed to
   refer to CRED_AKA_I or CRED_AKA_R, CRED_AKA_I and CRED_AKA_R are
   authentication credentials associated with the AKA.

   CRED_AKA_R: Contains the AKA parameters sent by the responder,
   typically including: * AT_RAND: Random Number Challenge * AT_AUTN:
   Authentication Token

   CRED_AKA_I: Contains parameters for the responder's response to the
   challenge, typically including: * AT_RES: Authentication Response

   An example of CRED_AKA_I and CRED_AKA_R is shown below: TBD

3.1.2.  Encoding and processing

   The AKA parameters should be encoded in the CWT format and the
   encryption and signature methods for them should be standardized in
   COSE.

   NOTE: Encode AKA in CWT format.  Need to standardize the encryption
   and signature of CWT-AKA in COSE.  RFC Editor: Remove this note.

3.2.  Message Flow of EDHOC-AKA

   The message flow of EDHOC-AKA follows the structure defined in
   [RFC9528], with authentication based on symmetric keys rather than
   public keys.

   The Responder authenticates the Initiator first.  Figure 1
   illustrates the message flow of the EDHOC-AKA authentication method.











Chen & Su                 Expires 23 April 2026                 [Page 4]

Internet-Draft                EDHOC PSK AKA                 October 2025


   Initiator                                 Responder
       |                                         |
       |                                         |
       | Method,SUITES_I,G_X,C_I,EAD_1           |
       +----------------------------------------->
       | Message_1                               |
       |                                         |
       |           G_Y,Enc(C_R,CRED_AKA_R,EAD_2) |
       <-----------------------------------------+
       |                  Message_2              |
       |                                         |
       |                                         |
       |                                         |
       | AEAD(CRED_AKA_I, EAD_3)                 |
       +----------------------------------------->
       | Message_3                               |
       |                                         |
       |                                         |
       |                   AEAD(EAD_4)           |
       <-----------------------------------------+
       |                   Message_4             |
       |                                         |

    Figure 1: Overview of Message Flow of EDHOC-AKA

   EDHOC message_4 is required to indicate EDHOC-AKA authentication
   success.

   EAD_1 = Initiator identity, it usually represents a pseudo identity
   rather than the user's genuine and long-term identity.  Based on this
   pseudo identity, the real identity can be retrieved on the Responder
   side.

   Both endpoints are authenticated with AKA (TBD1：METHOD = 5)

   NOTE: Assuming TBD1 = 5, to be confirmed by IANA.  RFC Editor: Remove
   this note.

4.  Key Derivation

   The key derivation of EDHOC-AKA is similar to that of EDHOC-PSK, but
   the source of the key PRK_4e3m is different.  The derivation methods
   of PRK_2e and PRK_3e2m are exactly the same as those of the standard
   EDHOC (based on G_XY).  The key difference lies in PRK_4e3m: In
   EDHOC-PSK: PRK_4e3m = EDHOC_Extract(SALT_4e3m, PSK) In EDHOC-AKA:
   PRK_4e3m = EDHOC_Extract(SALT_4e3m, K_AKA) Here, K_AKA is the key
   material generated from the AKA process.  In 3GPP AKA, this is
   usually derived by the key derivation function using CK (encryption



Chen & Su                 Expires 23 April 2026                 [Page 5]

Internet-Draft                EDHOC PSK AKA                 October 2025


   key) and IK (integrity key) as inputs to generate a new key for the
   specific service (EDHOC).  The subsequent derived keys PRK_out and so
   on are securely derived from PRK_4e3m, ensuring the independence and
   forward security of the final session key.

5.  Message Formating and Processing

5.1.  Message1

   Message 1 (Initiator -> Responder) METHOD = 5: Clearly declare that
   this conversation uses AKA authentication.  EAD_1: include the
   permanent identity (such as SUPI) or temporary identity (such as
   GUTI) of the initiating party, to assist the responder (service
   network) in requesting an authentication vector from its network.

5.2.  Message2

   Message 2 (Responder -> Initiator) The responder obtains the AKA
   authentication vectors (RAND, AUTN, XRES, CK, IK) from the network.
   The responder sends the challenge RAND and AUTN to the initiator
   through CRED_AKA_R.  The remaining part of Message 2 (G_Y, C_R) is
   consistent with the standard EDHOC.  The encryption structure
   Enc(C_R, CRED_AKA_R, EAD_2) is encrypted using the key stream derived
   from PRK_2e, similar to EDHOC-PSK.

5.3.  Message3

   Message 3 (Initiator -> Responder) The initiating party (UE) uses its
   built-in USIM card and long-term key K to verify the AUTN.  If the
   verification is successful, the response RES and session keys CK, IK
   are calculated.  The initiating party sends RES through CRED_AKA_I to
   the responding party.  The responding party verifies whether the
   received RES matches the expected XRES, thereby completing the
   authentication of the initiating party.

5.4.  Message4

   Message 4 (Responder -> Initiator) This message should be sent as it
   provides clear key confirmation to the initiator and authenticates
   the responder.  It is also an AEAD encryption structure, proving that
   the responder has successfully derived the session key.

6.  IANA Considerations

   IANA is requested to register the following entry in the "EDHOC
   Method Type" registry under the group name "Ephemeral Diffie-Hellman
   Over COSE (EDHOC)".




Chen & Su                 Expires 23 April 2026                 [Page 6]

Internet-Draft                EDHOC PSK AKA                 October 2025


   +-------+----------------------------+----------------------------+
   | Value |Initiator Authentication Key|Responder Authentication Key|
   +-------+----------------------------+----------------------------+
   | TBD2  | EDHOC-AKA                  |  EDHOC-AKA                 |
   +-------+---------------------- -----+----------------------------+
       Table 1: Addition to the EDHOC Method Type Registry.

   NOTE: Suggested value: TBD1 = 5.  RFC Editor: Remove this note.

7.  Security Considerations

   Mutual authentication: Strong mutual authentication is achieved
   through the AKA challenge-response mechanism.  Identity protection:
   The permanent identity of the initiator (such as SUPI) is only
   transmitted in the possible EAD_1 and can be replaced by a temporary
   identity.  The identity of the responder is protected in the message
   flow.  Forward security: Based on the temporary Diffie-Hellman
   exchange, even if the long-term subscription key K or the CK/IK
   derived from AKA is leaked, the past session will not be decrypted.
   Key binding: The final session key PRK_out is simultaneously bound to
   the temporary DH shared secret G_XY and the key K_AKA derived from
   AKA, providing stronger security.

8.  Informative References

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

   [RFC4187]  Arkko, J. and H. Haverinen, "Extensible Authentication
              Protocol Method for 3rd Generation Authentication and Key
              Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,
              January 2006, <https://www.rfc-editor.org/rfc/rfc4187>.

   [RFC5448]  Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
              Extensible Authentication Protocol Method for 3rd
              Generation Authentication and Key Agreement (EAP-AKA')",
              RFC 5448, DOI 10.17487/RFC5448, May 2009,
              <https://www.rfc-editor.org/rfc/rfc5448>.

   [RFC9048]  Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
              "Improved Extensible Authentication Protocol Method for
              3GPP Mobile Network Authentication and Key Agreement (EAP-
              AKA')", RFC 9048, DOI 10.17487/RFC9048, October 2021,
              <https://www.rfc-editor.org/rfc/rfc9048>.





Chen & Su                 Expires 23 April 2026                 [Page 7]

Internet-Draft                EDHOC PSK AKA                 October 2025


Authors' Addresses

   Meiling Chen
   China Mobile
   BeiJing
   China
   Email: chenmeiling@chinamobile.com


   Li Su
   China Mobile
   BeiJing
   China
   Email: suli@chinamobile.com





































Chen & Su                 Expires 23 April 2026                 [Page 8]


name: draft-ietf-lake-app-profiles
rev: 03
title: Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC)
time: 2025-11-21T17:11:52Z
group_uri: /api/v1/group/group/2249/
expires: 2026-04-23T12:35:40Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Data formats/interop", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:09.014896+00:00
abstract:
The lightweight authenticated key exchange protocol Ephemeral Diffie-
   Hellman Over COSE (EDHOC) requires certain parameters to be agreed
   out-of-band, in order to ensure its successful completion.  To this
   end, application profiles specify the intended use of EDHOC to allow
   for the relevant processing and verifications to be made.  In order
   to ensure the applicability of such parameters and information beyond
   transport- or setup-specific scenarios, this document defines a
   canonical, CBOR-based representation that can be used to describe,
   distribute, and store EDHOC application profiles.  Furthermore, In
   order to facilitate interoperability between EDHOC implementations
   and support EDHOC extensibility for additional integrations, this
   document defines a number of means to coordinate the use of EDHOC
   application profiles.  Finally, this document defines a set of well-
   known EDHOC application profiles.

full_text:
LAKE Working Group                                             M. Tiloca
Internet-Draft                                                R. Höglund
Intended status: Standards Track                                 RISE AB
Expires: 23 April 2026                                   20 October 2025


   Coordinating the Use of Application Profiles for Ephemeral Diffie-
                       Hellman Over COSE (EDHOC)
                    draft-ietf-lake-app-profiles-03

Abstract

   The lightweight authenticated key exchange protocol Ephemeral Diffie-
   Hellman Over COSE (EDHOC) requires certain parameters to be agreed
   out-of-band, in order to ensure its successful completion.  To this
   end, application profiles specify the intended use of EDHOC to allow
   for the relevant processing and verifications to be made.  In order
   to ensure the applicability of such parameters and information beyond
   transport- or setup-specific scenarios, this document defines a
   canonical, CBOR-based representation that can be used to describe,
   distribute, and store EDHOC application profiles.  Furthermore, In
   order to facilitate interoperability between EDHOC implementations
   and support EDHOC extensibility for additional integrations, this
   document defines a number of means to coordinate the use of EDHOC
   application profiles.  Finally, this document defines a set of well-
   known EDHOC application profiles.

Discussion Venues

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

   Discussion of this document takes place on the Lightweight
   Authenticated Key Exchange Working Group mailing list
   (lake@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/lake/.

   Source for this draft and an issue tracker can be found at
   https://github.com/lake-wg/app-profiles.

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



Tiloca & Höglund          Expires 23 April 2026                 [Page 1]

Internet-Draft         EDHOC Application Profiles           October 2025


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

   This Internet-Draft will expire on 23 April 2026.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  EDHOC_Application_Profile . . . . . . . . . . . . . . . . . .   6
   3.  Identifying EDHOC Application Profiles by Profile ID  . . . .   8
     3.1.  In Web Linking  . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  In the EDHOC_Information Object . . . . . . . . . . . . .  10
       3.2.1.  Use in the EDHOC and OSCORE Profile of the ACE
               Framework . . . . . . . . . . . . . . . . . . . . . .  11
   4.  Additional Parameters for Web Linking . . . . . . . . . . . .  13
   5.  Advertising Supported EDHOC Application Profiles during an
           EDHOC Session . . . . . . . . . . . . . . . . . . . . . .  15
     5.1.  In EDHOC Message 1 and Message 2  . . . . . . . . . . . .  15
       5.1.1.  Content Restrictions  . . . . . . . . . . . . . . . .  19
       5.1.2.  Agreeing on EDHOC_Exporter Output Lengths . . . . . .  20
     5.2.  In the EDHOC Error Message  . . . . . . . . . . . . . . .  24
   6.  Advertising Supported EDHOC Application Profiles using SVCB
           Resource Records  . . . . . . . . . . . . . . . . . . . .  25
   7.  Well-known EDHOC Application Profiles . . . . . . . . . . . .  28
     7.1.  Well-Known Application Profile MINIMAL_CS_2 . . . . . . .  29
     7.2.  Well-Known Application Profile MINIMAL_CS_0 . . . . . . .  29
     7.3.  Well-Known Application Profile BASIC_CS_2_X509  . . . . .  29
     7.4.  Well-Known Application Profile BASIC_CS_0_X509  . . . . .  30
     7.5.  Well-Known Application Profile BASIC_CS_2_C509  . . . . .  30
     7.6.  Well-Known Application Profile BASIC_CS_0_C509  . . . . .  30
     7.7.  Well-Known Application Profile INTERMEDIATE_CS_2  . . . .  31



Tiloca & Höglund          Expires 23 April 2026                 [Page 2]

Internet-Draft         EDHOC Application Profiles           October 2025


     7.8.  Well-Known Application Profile INTERMEDIATE_CS_0  . . . .  31
     7.9.  Well-Known Application Profile EXTENSIVE  . . . . . . . .  31
   8.  Identifiers of Well-known EDHOC Application Profiles  . . . .  32
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  33
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  33
     10.1.  Media Type Registrations . . . . . . . . . . . . . . . .  34
     10.2.  CoAP Content-Formats Registry  . . . . . . . . . . . . .  35
     10.3.  Target Attributes Registry . . . . . . . . . . . . . . .  35
     10.4.  EDHOC Information Registry . . . . . . . . . . . . . . .  38
     10.5.  EDHOC External Authorization Data Registry . . . . . . .  38
     10.6.  EDHOC Error Codes Registry . . . . . . . . . . . . . . .  39
     10.7.  DNS SVCB Service Parameter Keys (SvcParamKeys) . . . . .  39
     10.8.  EDHOC Application Profiles Registry  . . . . . . . . . .  40
     10.9.  Expert Review Instructions . . . . . . . . . . . . . . .  41
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  41
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  41
     11.2.  Informative References . . . . . . . . . . . . . . . . .  44
   Appendix A.  CDDL Model . . . . . . . . . . . . . . . . . . . . .  45
   Appendix B.  Document Updates . . . . . . . . . . . . . . . . . .  45
     B.1.  Version -02 to -03  . . . . . . . . . . . . . . . . . . .  45
     B.2.  Version -01 to -02  . . . . . . . . . . . . . . . . . . .  46
     B.3.  Version -00 to -01  . . . . . . . . . . . . . . . . . . .  47
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  48
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  48

1.  Introduction

   Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] is a lightweight
   authenticated key exchange protocol, especially intended for use in
   constrained scenarios.  A main use case for EDHOC is the
   establishment of a Security Context for Object Security for
   Constrained RESTful Environments (OSCORE) [RFC8613].

   In order to successfully run EDHOC, the two peers acting as Initiator
   and Responder have to agree on certain parameters.  Some of those are
   in-band and communicated through the protocol execution, during which
   a few of them may even be negotiated.  However, other parameters have
   to be known out-of-band, before running the EDHOC protocol.

   As discussed in Section 3.9 of [RFC9528], applications can use EDHOC
   application profiles, which specify the intended usage of EDHOC to
   allow for the relevant processing and verifications to be made.  In
   particular, an EDHOC application profile may include both in-band and
   out-of-band parameters.

   In order to ensure the applicability of such parameters and
   information beyond transport- or setup-specific scenarios, this
   document also defines the EDHOC_Application_Profile object, i.e., a



Tiloca & Höglund          Expires 23 April 2026                 [Page 3]

Internet-Draft         EDHOC Application Profiles           October 2025


   canonical, CBOR-based representation that can be used to describe,
   distribute, and store EDHOC application profiles as CBOR data items
   (see Section 2).  The defined representation is transport- and setup-
   independent, and avoids the need to reinvent an encoding for the
   available options to run the EDHOC protocol or the selection logic to
   apply on those.

   The CBOR-based representation of an EDHOC application profile can be,
   for example: retrieved as a result of a discovery process; or
   retrieved/provided during the retrieval/provisioning of an EDHOC
   peer's public authentication credential; or obtained during the
   execution of a device on-boarding/registration workflow.

   Furthermore, in order to facilitate interoperability between EDHOC
   implementations and to support EDHOC extensibility for additional
   integrations (e.g., of external security applications, handling of
   authentication credentials, and message transports), this document
   defines a number of means to coordinate the use of EDHOC application
   profiles, that is:

   *  The new IANA registry "EDHOC Application Profiles" defined in
      Section 10.8, where to register integer identifiers of EDHOC
      application profiles to use as corresponding Profile IDs.

   *  The new parameter "ed-prof" defined in Section 3.1.  This
      parameter is employed to specify an EDHOC application profile
      identified by its Profile ID and can be used as target attribute
      in a web link [RFC8288] to an EDHOC resource, or as filter
      criterion in a discovery request to discover EDHOC resources.

      For instance, the target attribute can be used in a CoRE link-
      format document [RFC6690] describing EDHOC resources at a server,
      when EDHOC is transferred over the Constrained Application
      Protocol (CoAP) [RFC7252] (see Appendix A.2 of [RFC9528] as well
      as [RFC9668]).

   *  The new parameter "app_prof" defined in Section 3.2 for the
      EDHOC_Information object specified in
      [I-D.ietf-ace-edhoc-oscore-profile].  This parameter is employed
      to specify a set of EDHOC application profiles, each identified by
      its Profile ID.

      For instance, the parameter can be used in the EDHOC and OSCORE
      profile [I-D.ietf-ace-edhoc-oscore-profile] of the ACE framework
      for authentication and authorization in constrained environments
      (ACE) [RFC9200], in order to indicate the EDHOC application
      profiles supported by an ACE resource server.




Tiloca & Höglund          Expires 23 April 2026                 [Page 4]

Internet-Draft         EDHOC Application Profiles           October 2025


      This parameter is also used in the EDHOC_Application_Profile
      object defined in this document, in order to encode the Profile ID
      of the EDHOC application profile described by an instance of that
      object.

   *  Additional parameters that provide information about an EDHOC
      application profile.  These parameters correspond to elements of
      the EDHOC_Information object and are to be used as target
      attributes in a web link to an EDHOC resource, or as filter
      criteria in a discovery request to discover EDHOC resources (see
      Section 4).

   *  A new EDHOC External Authorization Data (EAD) item (see
      Section 5.1) and a new error code for the EDHOC error message (see
      Section 5.2).  When running EDHOC, a peer can use those in order
      to advertise the EDHOC application profiles that it supports to
      the other peer.

   *  The use of SVCB Resource Records (RR) [RFC9460][RFC9461] to
      advertise the support for EDHOC and for EDHOC application profiles
      of a given server (see Section 6).

   Finally, this document defines a set of well-known EDHOC application
   profiles (see Section 7).  These application profiles are meant to
   reflect what is most common and expected to be supported by EDHOC
   peers, while they are not to be intended as "default" application
   profiles or as a deviation from what is mandatory to support for
   EDHOC peers (see Section 8 of [RFC9528]).  On the other hand, they
   provide implementers and users with a quick overview of the several
   available options to run the EDHOC protocol and of their most
   expected combinations.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The reader is expected to be familiar with terms and concepts defined
   in EDHOC [RFC9528] and with the use of EDHOC with CoAP [RFC7252] and
   OSCORE [RFC8613] defined in [RFC9668].

   Concise Binary Object Representation (CBOR) [RFC8949] and Concise
   Data Definition Language (CDDL) [RFC8610] are used in this document.
   CDDL predefined type names, especially bstr for CBOR byte strings and
   tstr for CBOR text strings, are used extensively in this document.



Tiloca & Höglund          Expires 23 April 2026                 [Page 5]

Internet-Draft         EDHOC Application Profiles           October 2025


   CBOR data items are represented using the CBOR extended diagnostic
   notation as defined in Section 8 of [RFC8949] and Appendix G of
   [RFC8610] ("diagnostic notation").  Diagnostic notation comments are
   used to provide a textual representation of the parameters' keys and
   values.

   In the CBOR diagnostic notation used in this document, constructs of
   the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME
   in the CDDL model shown in Figure 7 of Appendix A.  For example,
   {e'methods' : [0, 1, 2, 3], e'cipher_suites': 3} stands for {1 : [0,
   1, 2, 3], 2 : 3}.

   Note to RFC Editor: Please delete the paragraph immediately preceding
   this note.  Also, in the CBOR diagnostic notation used in this
   document, please replace the constructs of the form e'SOME_NAME' with
   the value assigned to SOME_NAME in the CDDL model shown in Figure 7
   of Appendix A.  Finally, please delete this note.

2.  EDHOC_Application_Profile

   This section defines the EDHOC_Application_Profile object, which can
   be used as a canonical representation of EDHOC application profiles
   for their description, distribution, and storage.

   An EDHOC_Application_Profile object is encoded as a CBOR map
   [RFC8949].  All elements that can be included in the
   EDHOC_Application_Profile object are elements that can be included in
   the CBOR-encoded EDHOC_Information object specified in Section 3.4 of
   [I-D.ietf-ace-edhoc-oscore-profile].  In particular, they use the
   same CBOR abbreviations from the 'CBOR label' column of the IANA
   registry "EDHOC Information" defined in
   [I-D.ietf-ace-edhoc-oscore-profile].

   The CBOR map encoding an EDHOC_Application_Profile object MUST
   include the element "app_prof" defined in Section 3.2 of this
   document, as well as the elements "methods" and "cred_types" defined
   in Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile].

   The value of the element "app_prof" is the unique identifier of the
   EDHOC application profile described by the instance of the
   EDHOC_Application_Profile object in question.  The identifier is
   taken from the 'Profile ID' column of the "EDHOC Application
   Profiles" registry defined in this document and encoded as a CBOR
   integer.

   The CBOR map MUST NOT include the following elements: "session_id",
   "uri_path", "initiator", "responder", and "trust_anchors".  Also, the
   CBOR map MUST NOT include the element "exporter_out_len" defined in



Tiloca & Höglund          Expires 23 April 2026                 [Page 6]

Internet-Draft         EDHOC Application Profiles           October 2025


   Section 5.1.2 of this document.  A consumer MUST ignore those
   elements if they are included in the EDHOC_Application_Profile
   object.

   The CBOR map MAY include other elements.

   Furthermore, consistent with Sections 8 and A.1 of [RFC9528] and with
   Section 5.4 of [RFC8613], the following applies:

   *  If the element "cipher_suites" is not present in the CBOR map,
      this indicates that the EDHOC application profile uses the EDHOC
      cipher suites 2 and 3, and possibly other cipher suites.

   *  If the element "id_cred_types" is not present in the CBOR map,
      this indicates that the EDHOC application profile uses "kid" as
      type of authentication credential identifiers for EDHOC, and
      possibly other types of authentication credential identifiers.

   *  The absence of any other elements in the CBOR map MUST NOT result
      in assuming any value.

   If an element is present in the CBOR map and the corresponding entry
   in the IANA registry "EDHOC Information" specifies "NP" (non-
   prescriptive) in the 'Type' column and "True or False" in the 'CBOR
   type' column, then the following applies.  An EDHOC peer that adheres
   to the EDHOC application profile in question is required or not to
   support the property or feature of EDHOC associated with the element
   in the CBOR map, if that element encodes the CBOR simple value true
   (0xf5) or false (0xf4), respectively.  For example, the presence of
   the parameter "comb_req" denotes whether EDHOC peers adhering to the
   EDHOC application profile have to support the EDHOC + OSCORE combined
   request defined in [RFC9668], or instead do not have to but might if
   they are willing to.

   If an element present in the CBOR map specifies an information that
   is intrinsically a set of one or more co-existing alternatives, then
   all the specified alternatives apply for the EDHOC application
   profile in question.  For example, the element "cipher_suites" with
   value the CBOR array [0, 2] means that, in order to adhere to the
   EDHOC application profile in question, an EDHOC peer has to implement
   both the EDHOC cipher suites 0 and 2, because either of them can be
   used by another EDHOC peer also adhering to the same EDHOC
   application profile.

   The CDDL grammar describing the EDHOC_Application_Profile object is:






Tiloca & Höglund          Expires 23 April 2026                 [Page 7]

Internet-Draft         EDHOC Application Profiles           October 2025


   EDHOC_Application_Profile = {
         1 => int / array,    ; methods
         6 => int / array,    ; cred_types
        23 => int,            ; app_prof
      * int / tstr => any
   }

     Figure 1: CDDL Definition of the EDHOC_Application_Profile object

3.  Identifying EDHOC Application Profiles by Profile ID

   This document introduces the concept of Profile IDs, i.e., integer
   values that uniquely identify EDHOC application profiles, for which
   an IANA registry is defined in Section 10.8.

   This section defines two parameters to convey such Profile IDs, i.e.:

   *  The parameter "ed-prof" for web linking [RFC8288] (see
      Section 3.1).

   *  The parameter "app_prof" of the EDHOC_Information object specified
      in [I-D.ietf-ace-edhoc-oscore-profile] (see Section 3.2).

      As defined in Section 2, Profile IDs are also conveyed by the
      parameter "app_prof" in the EDHOC_Application_Profile object, in
      order to identify the EDHOC application profile described by a
      given instance of that object.

   As defined later in this document, Profile IDs can be used to
   identify EDHOC application profiles also:

   *  Within certain EDHOC messages sent during an EDHOC session by a
      peer that supports such EDHOC application profiles (see
      Section 5).

   *  When using SVCB Resource Records (RR) [RFC9460][RFC9461] to
      advertise the support for EDHOC and for EDHOC application profiles
      of a given server (see Section 6).

3.1.  In Web Linking

   Section 6 of [RFC9668] defines a number of target attributes that can
   be used in a web link [RFC8288] with resource type "core.edhoc" (see
   Section 10.10 of [RFC9528]).  This is the case, e.g., when using a
   CoRE link-format document [RFC6690] describing EDHOC resources at a
   server, when EDHOC is transferred over CoAP [RFC7252] as defined in
   Appendix A.2 of [RFC9528].  This allows a client to obtain relevant
   information about the EDHOC application profile(s) to be used with a



Tiloca & Höglund          Expires 23 April 2026                 [Page 8]

Internet-Draft         EDHOC Application Profiles           October 2025


   certain EDHOC resource.

   In the same spirit, this section defines the following additional
   parameter, which can be optionally specified as a target attribute
   with the same name in the link to the respective EDHOC resource, or
   among the filter criteria in a discovery request from a client.

   *  'ed-prof', specifying an EDHOC application profile supported by
      the server.  This parameter MUST specify a single value, which is
      taken from the 'Profile ID' column of the "EDHOC Application
      Profiles" registry defined in Section 10.8 of this document.  This
      parameter MAY occur multiple times, with each occurrence
      specifying an EDHOC application profile.

   When specifying the parameter 'ed-prof' in a link to an EDHOC
   resource, the target attribute rt="core.edhoc" MUST be included.

   If a link to an EDHOC resource includes occurrences of the target
   attribute 'ed-prof', then the following applies.

   *  The link MUST NOT include other target attributes that provide
      information about an EDHOC application profile (see, e.g.,
      Section 6 of [RFC9668] and Section 4 of this document), with the
      exception of the target attribute 'ed-ead' that MAY be included.

      The recipient MUST ignore other target attributes that provide
      information about an EDHOC application profile, with the exception
      of the target attribute 'ed-ead'.

   *  If the link includes occurrences of the target attribute 'ed-ead',
      the link provides the following information: when using the target
      EDHOC resource as per the EDHOC application profile indicated by
      any occurrence of the target attribute 'ed-prof', the server
      supports the External Authorization Data (EAD) items that are
      specified in the definition of that EDHOC application profile, as
      well as the EAD items indicated by the occurrences of the target
      attribute 'ed-ead'.

   The example in Figure 2 shows how a CoAP client discovers two EDHOC
   resources at a CoAP server, and obtains information about the
   application profile corresponding to each of those resources.  The
   CoRE Link Format notation from Section 5 of [RFC6690] is used.

   The example assumes the existence of an EDHOC application profile
   identified by the integer Profile ID 500, which is supported by the
   EDHOC resource at /edhoc-alt and whose definition includes the
   support for the EAD items with EAD label 111 and 222.




Tiloca & Höglund          Expires 23 April 2026                 [Page 9]

Internet-Draft         EDHOC Application Profiles           October 2025


   Therefore, the link to the EDHOC resource at /edhoc-alt indicates
   that, when using that EDHOC resource as per the EDHOC application
   profile with Profile ID 500, the server supports the EAD items with
   EAD label 111, 222, and 333.

      REQ: GET /.well-known/core

      RES: 2.05 Content
          </sensors/temp>;osc,
          </sensors/light>;if=sensor,
          </.well-known/edhoc>;rt=core.edhoc;ed-csuite=0;ed-csuite=2;
              ed-method=0;ed-cred-t=1;ed-cred-t=3;ed-idcred-t=4;
              ed-i;ed-r;ed-comb-req,
          </edhoc-alt>;rt=core.edhoc;ed-prof=500;ed-ead=333

                          Figure 2: The Web Link.

3.2.  In the EDHOC_Information Object

   Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile] defines the
   EDHOC_Information object and an initial set of its parameters.  The
   object can be used to convey information that guides two peers about
   executing the EDHOC protocol.

   This document defines the new parameter "app_prof" of the
   EDHOC_Information object.  The parameter is of type non-prescriptive
   (NP) and is summarized in Table 1.  The parameter is specified
   further below.

    +==========+=======+=======+=============+=================+======+
    | Name     | CBOR  | CBOR  | Registry    | Description     | Type |
    |          | label | type  |             |                 |      |
    +==========+=======+=======+=============+=================+======+
    | app_prof | 23    | int   | EDHOC       | Set of          | NP   |
    |          |       | or    | Application | supported EDHOC |      |
    |          |       | array | Profiles    | Application     |      |
    |          |       |       | Registry    | Profiles        |      |
    +----------+-------+-------+-------------+-----------------+------+

              Table 1: EDHOC_Information Parameter "app_prof"

   *  app_prof: This parameter specifies a set of supported EDHOC
      application profiles, identified by their Profile ID.  If the set
      is composed of a single EDHOC application profile, its Profile ID
      is encoded as an integer.  Otherwise, the set is encoded as an
      array of integers, where each array element encodes one Profile
      ID.  In JSON, the "app_prof" value is an integer or an array of
      integers.  In CBOR, "app_prof" is an integer or an array of



Tiloca & Höglund          Expires 23 April 2026                [Page 10]

Internet-Draft         EDHOC Application Profiles           October 2025


      integers, and has label 23.  The integer values are taken from the
      'Profile ID' column of the "EDHOC Application Profiles" registry
      defined in Section 10.8 of this document.

3.2.1.  Use in the EDHOC and OSCORE Profile of the ACE Framework

   Section 3 of [I-D.ietf-ace-edhoc-oscore-profile] defines how the
   EDHOC_Information object can be used within the workflow of the EDHOC
   and OSCORE transport profile of the ACE framework for authentication
   and authorization in constrained environments (ACE) [RFC9200].

   In particular, the AS-to-C Access Token Response includes the
   parameter "edhoc_info", with value an EDHOC_Information object.  This
   allows the ACE authorization server (AS) to provide the ACE client
   (C) with information about how to run the EDHOC protocol with the ACE
   resource server (RS) for which the access token is issued.

   Similarly, the access token includes the corresponding claim
   "edhoc_info", with value an EDHOC_Information object.  This allows
   the AS to provide the ACE RS with information about how to run the
   EDHOC protocol with the ACE client, according to the issued access
   token.

   In turn, the EDHOC_Information object can include the parameter
   "app_prof" defined in this document.  This parameter indicates a set
   of EDHOC application profiles associated with the EDHOC resource to
   use at the RS, which is either implied or specified by the parameter
   "uri_path" within the same EDHOC_Information object.

   If the EDHOC_Information object specified as the value of the
   parameter/claim "edhoc_info" includes the "app_prof" parameter, then
   the following applies.

   *  In addition to the "app_prof" parameter, the object MUST NOT
      include other parameters, with the exception of the following
      parameters that MAY be included:

      -  The parameter "eads".

      -  Any parameter that is not allowed in the
         EDHOC_Application_Profile object defined in Section 2, unless
         its inclusion in the EDHOC_Information object is explicitly
         forbidden by the parameter's definition.








Tiloca & Höglund          Expires 23 April 2026                [Page 11]

Internet-Draft         EDHOC Application Profiles           October 2025


         For example, the parameter "session_id" is not allowed in the
         EDHOC_Application_Profile object (see Section 2) and thus can
         be included in the EDHOC_Information object, where in fact it
         has to be present (see Sections 3.3 and 3.3.1 of
         [I-D.ietf-ace-edhoc-oscore-profile]).

      C and RS MUST ignore other parameters that are not admitted if
      they are present in the EDHOC_Information object.

   *  The object might provide an information that corresponds to an
      EDHOC_Information prescriptive parameter (see Section 3.4 of
      [I-D.ietf-ace-edhoc-oscore-profile]), e.g., "message_4" or
      "max_msgsize".  The type of a parameter is indicated in the 'Type'
      column of the corresponding entry in the IANA registry "EDHOC
      Information" (see [I-D.ietf-ace-edhoc-oscore-profile]).

      If the object specifies such an information multiple times, then
      each occurrence of that information MUST convey exactly the same
      content.  This MUST take into account prescriptive parameters that
      are included: i) as elements of the EDHOC_Information object; or
      ii) as elements of an EDHOC_Application_Profile object (see
      Section 2) encoding an EDHOC application profile, which is
      identified by its Profile ID specified in the "app_prof" parameter
      of the EDHOC_Information object.

      A consumer MUST treat as malformed an EDHOC_Information object
      that does not comply with the restriction above.

   *  If the EDHOC_Information object specified in the parameter
      "edhoc_info" of the AS-to-C Access Token Response includes the
      parameter "eads", then the following applies.

      When using the target EDHOC resource as per any EDHOC application
      profile indicated by the parameter "app_prof", the ACE RS for
      which the access token is issued supports the EAD items that are
      specified in the definition of that EDHOC application profile, as
      well as the EAD items indicated by the parameter "eads".

   *  If the EDHOC_Information object specified in the claim
      "edhoc_info" of the access token includes the parameter "eads",
      then the following applies.

      When using the target EDHOC resource as per any EDHOC application
      profile indicated by the parameter "app_prof", the ACE client to
      which the access token is issued supports the EAD items that are
      specified in the definition of that EDHOC application profile, as
      well as the EAD items indicated by the parameter "eads".




Tiloca & Höglund          Expires 23 April 2026                [Page 12]

Internet-Draft         EDHOC Application Profiles           October 2025


4.  Additional Parameters for Web Linking

   Building on what is defined and prescribed in Section 6 of [RFC9668],
   this section defines additional parameters for web linking [RFC8288],
   which can be used to obtain relevant pieces of information from the
   EDHOC application profile associated with an EDHOC resource.

   These parameters can be optionally specified as target attributes
   with the same name in a link with resource type "core.edhoc" (see
   Section 10.10 of [RFC9528]) targeting an EDHOC resource, or as filter
   criteria in a discovery request from a client.

   When specifying any of the parameters defined below in a link to an
   EDHOC resource, the target attribute rt="core.edhoc" MUST be
   included.

   *  'ed-max-msgsize', specifying the admitted maximum size of EDHOC
      messages in bytes.  This parameter MUST specify a single unsigned
      integer value.

   *  'ed-coap-ct', specifying that CoAP messages have to include the
      CoAP Content-Format Option with value 64 (application/edhoc+cbor-
      seq) or 65 (application/cid-edhoc+cbor-seq) as appropriate, when
      the message payload includes exclusively an EDHOC message possibly
      prepended by an EDHOC connection identifier (see Sections 3.4.1
      and A.2 of [RFC9528]).  A value MUST NOT be given to this
      parameter and any present value MUST be ignored by the recipient.

   *  'ed-epid-t', specifying a type of endpoint identity for EDHOC
      supported by the server.  This parameter MUST specify a single
      value, which is taken from the 'CBOR Label' column of the "EDHOC
      Endpoint Identity Types" registry defined in
      [I-D.ietf-ace-edhoc-oscore-profile].  This parameter MAY occur
      multiple times, with each occurrence specifying a type of endpoint
      identity for EDHOC.

   *  'ed-tp', specifying a means for transporting EDHOC messages
      supported by the server.  This parameter MUST specify a single
      value, which is taken from the 'Transport ID' column of the "EDHOC
      Transports" registry defined in
      [I-D.ietf-ace-edhoc-oscore-profile].  This parameter MAY occur
      multiple times, with each occurrence specifying a means for
      transporting EDHOC messages.

   *  'ed-ta-edcred-uuid', specifying the identifier of a trust anchor
      supported by the server for verifying authentication credentials
      of other EDHOC peers, as a UUID [RFC9562].  This parameter MUST
      specify a single value, which is the UUID in its string format



Tiloca & Höglund          Expires 23 April 2026                [Page 13]

Internet-Draft         EDHOC Application Profiles           October 2025


      (see Section 4 of [RFC9562]).  This parameter MAY occur multiple
      times, with each occurrence specifying one trust anchor
      identifier.

   *  'ed-ta-edcred-kid', specifying the identifier of a trust anchor
      supported by the server for verifying authentication credentials
      of other EDHOC peers, as a binary key identifier.  This parameter
      MUST specify a single value, which is the base64url-encoded text
      string of the binary representation of the key identifier.  This
      parameter MAY occur multiple times, with each occurrence
      specifying one trust anchor identifier.

   *  'ed-ta-edcred-c5t', specifying the identifier of a trust anchor
      supported by the server for verifying authentication credentials
      of other EDHOC peers, as a hash of a C509 certificate
      [I-D.ietf-cose-cbor-encoded-cert].  This parameter MUST specify a
      single value, which is the base64url-encoded text string of the
      binary representation of the certificate hash encoded as a
      COSE_CertHash [RFC9360].  This parameter MAY occur multiple times,
      with each occurrence specifying one trust anchor identifier.

   *  'ed-ta-edcred-c5u', specifying the identifier of a trust anchor
      supported by the server for verifying authentication credentials
      of other EDHOC peers, as a URI [RFC3986] pointing to a C509
      certificate [I-D.ietf-cose-cbor-encoded-cert].  This parameter
      MUST specify a single value, which is the URI pointing to the
      certificate.  This parameter MAY occur multiple times, with each
      occurrence specifying one trust anchor identifier.

   *  'ed-ta-edcred-x5t', specifying the identifier of a trust anchor
      supported by the server for verifying authentication credentials
      of other EDHOC peers, as a hash of an X.509 certificate [RFC5280].
      This parameter MUST specify a single value, which is the
      base64url-encoded text string of the binary representation of the
      certificate hash encoded as a COSE_CertHash [RFC9360].  This
      parameter MAY occur multiple times, with each occurrence
      specifying one trust anchor identifier.

   *  'ed-ta-edcred-x5u', specifying the identifier of a trust anchor
      supported by the server for verifying authentication credentials
      of other EDHOC peers, as a URI [RFC3986] pointing to an X.509
      certificate [RFC5280].  This parameter MUST specify a single
      value, which is the URI pointing to the certificate.  This
      parameter MAY occur multiple times, with each occurrence
      specifying one trust anchor identifier.






Tiloca & Höglund          Expires 23 April 2026                [Page 14]

Internet-Draft         EDHOC Application Profiles           October 2025


5.  Advertising Supported EDHOC Application Profiles during an EDHOC
    Session

   The rest of this section defines means that an EDHOC peer can use in
   order to advertise the EDHOC application profiles that it supports to
   another EDHOC peer, when running EDHOC with that other peer.

   Such means are an EDHOC EAD item (see Section 5.1) and an error code
   for the EDHOC error message (see Section 5.2).

5.1.  In EDHOC Message 1 and Message 2

   This section defines the EDHOC EAD item "Supported EDHOC application
   profiles", which is registered in Section 10.5 of this document.

   The EAD item MAY be included:

   *  In the EAD_1 field of EDHOC message_1, in order to specify EDHOC
      application profiles supported by the Initiator.

   *  In the EAD_2 field of EDHOC message_2, in order to specify EDHOC
      application profiles supported by the Responder.

   When the EAD item is present, its ead_label TBD_EAD_LABEL MUST be
   used only with negative sign, i.e., the use of the EAD item is always
   critical (see Section 3.8 of [RFC9528]).

   The EAD item MUST NOT occur more than once in the EAD fields of EDHOC
   message_1 or message_2.  The recipient peer MUST abort the EDHOC
   session and MUST reply with an EDHOC error message with error code
   (ERR_CODE) 1, if the EAD item occurs multiple times in the EAD fields
   of EDHOC message_1 or message_2.

   The EAD item MUST NOT be included in the EAD fields of EDHOC
   message_3 or message_4.  In case the recipient peer supports the EAD
   item, the recipient peer MUST silently ignore the EAD item if this is
   included in the EAD fields of EDHOC message_3 or message_4.

   The EAD item MUST specify an ead_value, as a CBOR byte string with
   value the binary representation of a CBOR sequence [RFC8742].  In
   particular:

   *  When the EAD item is included in the EAD_1 field, the value of the
      CBOR byte string is the binary representation of the CBOR sequence
      OUTER_SEQ.  In turn, OUTER_SEQ is composed of the following
      elements:





Tiloca & Höglund          Expires 23 April 2026                [Page 15]

Internet-Draft         EDHOC Application Profiles           October 2025


      -  The CBOR data item reply_flag, which MAY be present.  If
         present, it MUST encode the CBOR simple value true (0xf5) or
         false (0xf4).  The semantics of this element is as follows.

         o  If reply_flag is present and encodes the CBOR simple value
            true (0xf5), the Initiator is asking the Responder to
            advertise the EDHOC application profiles that it supports,
            within the EDHOC message sent in reply to EDHOC message_1.

            If such a message is EDHOC message_2, the Responder relies
            on the EAD item "Supported EDHOC application profiles"
            included in the EAD_2 field.  If such a message is an EDHOC
            error message with error code TBD_ERROR_CODE (see
            Section 5.2), the Responder relies on ERR_INFO.

            If the Responder sends either of those messages in reply to
            such an EDHOC message_1, the Responder MUST honor the
            request from the Initiator and accordingly advertise the
            EDHOC application profiles that it supports.

         o  If reply_flag is present and encodes the CBOR simple value
            false (0xf4), the Initiator is suggesting the Responder to
            not advertise the EDHOC application profiles that it
            supports, within the EDHOC message sent in reply to EDHOC
            message_1.  This is relevant when the Initiator already
            knows what EDHOC application profiles are supported by the
            Responder, e.g., based on previous interactions with that
            Responder or on the outcome of a discovery process.

            In spite of the suggestion from the Initiator, the Responder
            MAY still advertise the EDHOC application profiles that it
            supports, when replying to EDHOC message_1 with EDHOC
            message_2 or with an EDHOC error message with error code
            TBD_ERROR_CODE (see Section 5.2).  For example, when sending
            EDHOC message_2, the Responder might wish to steer the rest
            of the EDHOC session in a specific way, by including the EAD
            item "Supported EDHOC application profiles" that specifies
            information corresponding to EDHOC_Information prescriptive
            parameters (see Section 3.4 of
            [I-D.ietf-ace-edhoc-oscore-profile]).

      -  The CBOR sequence APP_PROF_SEQ, which is specified further
         below.

   *  When the EAD item is included in the EAD_2 field, the value of the
      CBOR byte string is the binary representation of the CBOR sequence
      APP_PROF_SEQ.




Tiloca & Höglund          Expires 23 April 2026                [Page 16]

Internet-Draft         EDHOC Application Profiles           October 2025


   The CBOR sequence APP_PROF_SEQ is composed of one or more elements,
   whose order has no meaning.  Each element of the CBOR sequence MUST
   be either of the following:

   *  A CBOR integer, specifying the Profile ID of an EDHOC application
      profile.  The integer value is taken from the 'Profile ID' column
      of the "EDHOC Application Profiles" registry defined in
      Section 10.8 of this document.

      This element of the CBOR sequence indicates that the message
      sender supports the EDHOC application profile identified by the
      Profile ID.

   *  A CBOR array including at least two elements.  In particular:

      -  The first element MUST be a CBOR integer, specifying the
         Profile ID of an EDHOC application profile.  The integer value
         is taken from the 'Profile ID' column of the "EDHOC Application
         Profiles" registry.

      -  Each of the elements following the first one MUST be a CBOR
         unsigned integer, specifying the ead_label of an EAD item.

      This element of the CBOR sequence indicates that the message
      sender supports:

      -  The EDHOC application profile PROFILE identified by the Profile
         ID in the first element of the array; and

      -  The EAD items identified by the ead_label in the elements
         following the first one, in addition to the EAD items that are
         specified in the definition of the EDHOC application profile
         PROFILE.

   *  An EDHOC_Information object encoded in CBOR, i.e., as a CBOR map
      (see Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile]).

      The EDHOC_Information object MUST NOT include the element
      "app_prof".  Also, it MUST NOT include elements that are not
      allowed within the EDHOC_Application_Profile object defined in
      Section 2, with the exception of the following elements that MAY
      be included:

      -  "trust_anchors".

      -  "exporter_out_len" (see Section 5.1.2).





Tiloca & Höglund          Expires 23 April 2026                [Page 17]

Internet-Draft         EDHOC Application Profiles           October 2025


      This element of the CBOR sequence indicates that the message
      sender supports an EDHOC application profile consistent with the
      pieces of information specified by the EDHOC_Information object.

   The recipient peer MUST abort the EDHOC session and MUST reply with
   an EDHOC error message with error code (ERR_CODE) 1, if ead_value is
   malformed or does not conform with the format defined above.

   It is possible that ead_value provides information corresponding to
   EDHOC_Information prescriptive parameters (see Section 3.4 of
   [I-D.ietf-ace-edhoc-oscore-profile]), e.g., "message_4" or
   "max_msgsize".  The type of such parameters is indicated in the
   'Type' column of the corresponding entry in the IANA registry "EDHOC
   Information" (see [I-D.ietf-ace-edhoc-oscore-profile]).

   If the EAD item "Supported EDHOC application profiles" is included in
   EDHOC message_1 and/or message_2 during an EDHOC session, the peers
   participating in that session MUST NOT act in violation of what is
   indicated by prescriptive parameters that are specified in those EAD
   items.  Upon receiving an EDHOC message, a peer MUST check whether
   the other peer has violated such indications.  If any violation is
   found, the peer MUST abort the EDHOC session and MUST reply with an
   EDHOC error message with error code (ERR_CODE) 1.

   When composing ead_value, the sender peer MUST comply with the
   content restrictions specified in Section 5.1.1.

   The CDDL grammar describing ead_value for the EAD item "Supported
   EDHOC application profiles" is shown in Figure 3.






















Tiloca & Höglund          Expires 23 April 2026                [Page 18]

Internet-Draft         EDHOC Application Profiles           October 2025


   ead_value = ead_1_value / ead_2_value

   ead_1_value = bytes .cborseq OUTER_SEQ

   ead_2_value = bytes .cborseq APP_PROF_SEQ

   ; This defines an array, the elements of which
   ; are to be used in the CBOR Sequence OUTER_SEQ:
   OUTER_SEQ = [?reply_flag, APP_PROF_SEQ]

   reply_flag = bool

   ; This defines an array, the elements of which
   ; are to be used in the CBOR Sequence APP_PROF_SEQ:
   APP_PROF_SEQ = [1* element]

   element = profile_id / profile_id_with_eads / EDHOC_Information

   profile_id = int

   profile_id_with_eads = [profile_id, 1* uint]

   ; The full definition is provided in
   ; draft-ietf-ace-edhoc-oscore-profile
   EDHOC_Information : map

          Figure 3: CDDL Definition of ead_value for the EAD Item
                   "Supported EDHOC application profiles"

5.1.1.  Content Restrictions

   When the sender peer composes ead_value of the EDHOC EAD item
   "Supported EDHOC application profiles", the following applies.

   It is possible that ead_value provides an information corresponding
   to an EDHOC_Information prescriptive parameter (see Section 3.4 of
   [I-D.ietf-ace-edhoc-oscore-profile]).

   If ead_value specifies such an information multiple times, then each
   occurrence of that information MUST convey exactly the same content.
   With reference to the CBOR sequence APP_PROF_SEQ defined in
   Section 5.1, the enforcement of these content restrictions MUST take
   into account prescriptive parameters that are included:

   *  As elements of an EDHOC_Information object specified within
      APP_PROF_SEQ; or





Tiloca & Höglund          Expires 23 April 2026                [Page 19]

Internet-Draft         EDHOC Application Profiles           October 2025


   *  As elements of an EDHOC_Application_Profile object encoding an
      EDHOC application profile, which is identified by its Profile ID
      specified within APP_PROF_SEQ.

   If the Responder receives the EAD item in the EAD_1 field of EDHOC
   message_1 and intends to include the EAD item in the EAD_2 field of
   EDHOC message_2, then the Responder MUST further take into account
   the presence of such information in the received EAD item when
   composing ead_value.

   A consumer MUST treat as malformed an EDHOC_Information object that
   does not comply with the restrictions above.

5.1.2.  Agreeing on EDHOC_Exporter Output Lengths

   The main output of a successfully completed EDHOC session is the
   shared secret session key PRK_out (see Section 4.1.3 of [RFC9528]).

   After having established PRK_out, the two peers can use the
   EDHOC_Exporter interface defined in Section 4.2.1 of [RFC9528], e.g.,
   to derive keying material for an application protocol.  Among its
   inputs, the EDHOC_Exporter interface includes "exporter_label" as a
   registered numeric identifier of the intended output and "length" as
   the length in bytes of the intended output.

   When using the EDHOC_Exporter interface, it is crucial that the two
   peers agree about the length in bytes of each intended output, in
   order to ensure the correctness of their operations.  To this end,
   the two peers can rely on pre-defined default lengths, or agree out-
   of-band on alternative lengths.

   However, the two peers might need or prefer to explicitly agree about
   specific output lengths to use on a per-session basis.  As described
   below, this can be achieved in-band, by using the EDHOC EAD item
   "Supported EDHOC application profiles" defined in Section 5.1.

   This document defines the new parameter "exporter_out_len" of the
   EDHOC_Information object (see Section 3.4 of
   [I-D.ietf-ace-edhoc-oscore-profile]).  The parameter is of type
   prescriptive (P) and is summarized in Table 2.  The parameter is
   specified further below.










Tiloca & Höglund          Expires 23 April 2026                [Page 20]

Internet-Draft         EDHOC Application Profiles           October 2025


    +==================+=====+=======+==========+================+====+
    | Name             |CBOR | CBOR  | Registry | Description    |Type|
    |                  |label| type  |          |                |    |
    +==================+=====+=======+==========+================+====+
    | exporter_out_len |22   | array | EDHOC    | Set of output  |P   |
    |                  |     |       | Exporter | lengths to use |    |
    |                  |     |       | Labels   | with the       |    |
    |                  |     |       |          | EDHOC_Exporter |    |
    |                  |     |       |          | interface      |    |
    +------------------+-----+-------+----------+----------------+----+

          Table 2: EDHOC_Information Parameter "exporter_out_len"

   *  exporter_out_len: This parameter specifies a set of pairs (X, Y),
      where:

      -  The first element X specifies a value to use as first argument
         "exporter_label" when invoking the EDHOC_Exporter interface
         (see Section 4.2.1 of [RFC9528]).

         The value of X is taken from the 'Label' column of the "EDHOC
         Exporter Labels" registry within the "Ephemeral Diffie-Hellman
         Over COSE (EDHOC)" registry group [EDHOC.Exporter.Labels].

      -  The second element Y specifies the value to use as third
         argument "length" when invoking the EDHOC_Exporter interface
         using the value specified by X as first argument
         "exporter_label" (see Section 4.2.1 of [RFC9528]).

         The value specified by Y MUST be a valid value to use as
         "length" when using the value specified by X as
         "exporter_label".  For example, when X specifies 0 as the
         "exporter_label" to derive an OSCORE Master Secret [RFC8613], Y
         is required to be not less than the "length" default value
         defined in Appendix A.1 of [RFC9528], i.e., the key length (in
         bytes) of the application AEAD Algorithm of the selected cipher
         suite for the EDHOC session.

      The set is encoded as an array, each element of which MUST be an
      array of exactly two elements, hence encoding one pair (X, Y).
      That is, each inner array includes X encoded as an unsigned
      integer and Y encoded as an unsigned integer, in this order.

      Within the set of pairs (X, Y), the order of the inner arrays
      encoding the pairs is not relevant.  The set MUST NOT specify
      multiple pairs that have the same unsigned integer value as their
      first element X.




Tiloca & Höglund          Expires 23 April 2026                [Page 21]

Internet-Draft         EDHOC Application Profiles           October 2025


      In JSON, the "exporter_out_len" value is an array, each element of
      which is an array including two unsigned integers.  In CBOR,
      "exporter_out_len" is an array, each element of which is an array
      including two unsigned integers, and has label 22.

   Within ead_value of the EAD item "Supported EDHOC application
   profiles", the parameter "exporter_out_len" can be included within
   instances of the EDHOC_Information object that are specified within
   the CBOR sequence APP_PROF_SEQ (see Section 5.1).

   The recipient peer MUST abort the EDHOC session and MUST reply with
   an EDHOC error message with error code (ERR_CODE) 1, if any of the
   following occurs:

   *  The recipient peer does not recognize the value encoded by the
      first element X of a pair (X, Y) as a valid "exporter_label" to be
      used when invoking the EDHOC_Exporter interface.

   *  In a pair (X, Y), the value encoded by the second element Y is not
      valid to be used as "length" when invoking the EDHOC_Exporter
      interface using the value encoded by the first element X as
      "exporter_label".

   *  For a pair (X, Y), the recipient peer is not going to be able to
      invoke the EDHOC_Exporter interface using the values encoded by X
      and Y as the first argument "exporter_label" and the third
      argument "length", respectively.

   If the Responder has received an EDHOC message_1 including the EAD
   item "Supported EDHOC application profiles" and specifying the
   parameter "exporter_out_len", then the following applies if the
   Responder includes the EAD item "Supported EDHOC application
   profiles" in EDHOC message_2, with ead_value specifying the parameter
   "exporter_out_len".  Within ead_value of the EAD item included in
   EDHOC message_2, the Responder MUST NOT specify any pair (X, Y) such
   that the unsigned integer value encoded by X was encoded by the first
   element of a pair within the EAD item included in the received EDHOC
   message_1.













Tiloca & Höglund          Expires 23 April 2026                [Page 22]

Internet-Draft         EDHOC Application Profiles           October 2025


   If the Initiator receives an EDHOC message_2 including the EAD item
   "Supported EDHOC application profiles" and specifying the parameter
   "exporter_out_len", then the following applies if the Initiator
   included the EAD item "Supported EDHOC application profiles" in EDHOC
   message_1, with ead_value specifying the parameter
   "exporter_out_len".  The Initiator MUST abort the EDHOC session and
   MUST reply with an EDHOC error message with error code (ERR_CODE) 1,
   if ead_value of the EAD item included in EDHOC message_2 specifies
   any pair (X, Y) such that the unsigned integer value encoded by X was
   encoded by the first element of a pair of the EAD item included in
   the sent EDHOC message_1.

   Since the parameter "exporter_out_len" is of type prescriptive, the
   restrictions compiled in Section 5.1.1 apply.  In particular, the
   "information" corresponding to the prescriptive parameter
   "exporter_out_len" is the "length" Y to use when invoking the
   EDHOC_Exporter interface using the paired "exporter_label" X.

   That is, if ead_value provides the length of the EDHOC_Exporter
   output for a given "exporter_label" multiple times, then each of such
   occurrences MUST specify the same "length" value.  Within this
   constraint, it remains possible for ead_value to specify multiple
   instances of the EDHOC_Information object within APP_PROF_SEQ and for
   each of such instances to include the parameter "exporter_out_len",
   which can overall encode a value different from that of the same
   parameter in another instance of the EDHOC_Information object.

   The recipient peer MUST abort the EDHOC session and MUST reply with
   an EDHOC error message with error code (ERR_CODE) 1, if the parameter
   "exporter_out_len" is malformed or does not conform with the format
   and constraints defined above.

   In an EDHOC session during which the EAD item "Supported EDHOC
   application profiles" has been included in EDHOC message_1 and/or
   message_2 as specifying the parameter "exporter_out_len", the
   following applies.

   *  The Initiator (Responder) considers the successful verification of
      EDHOC message_2 (message_3) as a confirmed agreement with the
      other peer about how to invoke the EDHOC_Exporter interface, once
      the session key PRK_out for the present EDHOC session is
      available.

      That is, for each pair (X, Y) specified by the exchanged EAD
      items, the two peers MUST use the unsigned integer values encoded
      by X and Y as the first argument "exporter_label" and the third
      argument "length", respectively.




Tiloca & Höglund          Expires 23 April 2026                [Page 23]

Internet-Draft         EDHOC Application Profiles           October 2025


   *  If a particular "exporter_label" value is not specified by the
      exchanged EAD items, then a possible invocation of the
      EDHOC_Exporter interface using that value as its first argument
      takes as value for its third argument "length" a pre-defined
      default value, or an alternative value agreed out-of-band.

   When using the EDHOC and OSCORE transport profile of the ACE
   framework [I-D.ietf-ace-edhoc-oscore-profile], the parameter
   "exporter_out_len" MUST NOT be included within the EDHOC_Information
   object specified as the value of the parameter/claim "edhoc_info".

5.2.  In the EDHOC Error Message

   This section defines the error code TBD_ERROR_CODE, which is
   registered in Section 10.6 of this document.

   Error code TBD_ERROR_CODE MUST only be used when replying to EDHOC
   message_1.  If an EDHOC error message with error code TBD_ERROR_CODE
   is received as reply to an EDHOC message different from EDHOC
   message_1, then the recipient of the error message MUST ignore what
   is specified in ERR_INFO.

   The Responder MUST NOT abort an EDHOC session exclusively due to the
   wish of sending an error message with error code TBD_ERROR_CODE.
   Instead, the Responder can advertise the EDHOC application profiles
   that it supports to the Initiator by means of the EAD item "Supported
   EDHOC application profiles" defined in Section 5.1, specifying it in
   the EAD_2 field of the EDHOC message_2 to send in the EDHOC session.

   When replying to an EDHOC message_1 with an error message, the
   Responder has to consider the reason for which it is aborting the
   EDHOC session and MUST NOT specify error code TBD_ERROR_CODE if a
   different, more appropriate error code can be specified instead.  For
   example, if the negotiation of the selected cipher suite fails (see
   Section 6.3 of [RFC9528]), the error message MUST NOT specify error
   code TBD_ERROR_CODE, since the error message intended to be used in
   that case specifies error code 2 (Wrong selected cipher suite) and
   conveys SUITES_R as ERR_INFO.

   When using error code TBD_ERROR_CODE, the error information specified
   in ERR_INFO MUST be a CBOR byte string with value the binary
   representation of a CBOR sequence APP_PROF_SEQ.

   In particular, APP_PROF_SEQ has the same format and semantics
   specified in Section 5.1, except for the following difference: for
   each element of the CBOR sequence that is an EDHOC_Information
   object, such an object MUST NOT include the element
   "exporter_out_len" defined in Section 5.1.2.



Tiloca & Höglund          Expires 23 April 2026                [Page 24]

Internet-Draft         EDHOC Application Profiles           October 2025


   The recipient peer MUST silently ignore elements of the CBOR sequence
   APP_PROF_SEQ that are malformed or do not conform with the intended
   format of APP_PROF_SEQ.

6.  Advertising Supported EDHOC Application Profiles using SVCB Resource
    Records

   Given a server, its support for EDHOC and for EDHOC application
   profiles can be advertised using SVCB Resource Records (RR)
   [RFC9460][RFC9461].

   To this end, this document specifies the SvcParamKeys "edhocpath" and
   "edhoc-app-prof", which are defined below and are registered in
   Section 10.7.

   *  "edhocpath" - The SvcParamKey "edhocpath" is single-valued and
      specifies a list of one or more absolute paths to EDHOC resources
      at the server.

      -  The wire-format value of "edhocpath" is the binary
         representation of the CBOR data item edhocpath-value, which
         MUST exactly fill the SvcParamValue.

         In particular, edhocpath-value MUST be a CBOR byte string
         PATH_BSTR or a CBOR array.  In the latter case, the array MUST
         include at least two elements, each of which MUST be a CBOR
         byte string PATH_BSTR.  The SVCB RR MUST be considered
         malformed if the SvcParamValue ends within edhocpath-value or
         if edhocpath-value is malformed.

         The value of each CBOR byte string PATH_BSTR is the binary
         representation of a CBOR sequence PATH_SEQ composed of zero or
         more CBOR text strings.  In particular, each PATH_SEQ specifies
         the URI path of an EDHOC resource at the server, with each CBOR
         text string within that PATH_SEQ specifying a URI path segment.

         If edhocpath-value is a CBOR array, it MUST NOT include any two
         elements that specify the same URI path.

         The CDDL grammar describing the CBOR data item edhocpath-value
         is shown in Figure 4.

      -  The presentation format value of "edhocpath" SHALL be a comma-
         separated list (see Appendix A.1 of [RFC9460]) of one or more
         absolute paths to EDHOC resources at the server.  The same
         considerations for the "," and "\" characters in paths for
         zone-file implementations as for the alpn-ids in an "alpn"
         SvcParam apply (see Section 7.1.1 of [RFC9460]).



Tiloca & Höglund          Expires 23 April 2026                [Page 25]

Internet-Draft         EDHOC Application Profiles           October 2025


         The i-th path in the presentation format value is the textual
         representation of the path specified by the i-th CBOR sequence
         PATH_SEQ in the wire-format value (see above).

         The textual representation of each path follows the semantics
         of path-absolute shown in the ABNF definition in Figure 5,
         which is provided by the ABNF for path-absolute in Section 3.3
         of [RFC3986].  In particular, given the path specified by a
         CBOR sequence PATH_SEQ, segment-nz is the value of the first
         CBOR text string in PATH_SEQ (if any), while each segment is
         the value of a CBOR text string following the first one in
         PATH_SEQ (if any).

   *  "edhoc-app-prof" - The SvcParamKey "edhoc-app-prof" is single-
      valued and specifies a set of EDHOC application profiles that the
      server supports.

      -  The wire-format value of "edhoc-app-prof" is the binary
         representation of the CBOR data item edhoc-app-prof-value,
         which MUST exactly fill the SvcParamValue.

         In particular, edhoc-app-prof-value MUST be a CBOR byte string
         APP_BSTR or a CBOR array.  In the latter case, the array MUST
         include at least two elements, each of which MUST be a CBOR
         byte string APP_BSTR.  The SVCB RR MUST be considered malformed
         if the SvcParamValue ends within edhoc-app-prof-value or if
         edhoc-app-prof-value is malformed.

         The value of each CBOR byte string APP_BSTR is the binary
         representation of a CBOR sequence APP_PROF_SEQ.  In particular,
         APP_PROF_SEQ has the same format and semantics specified in
         Section 5.1, except for the following difference: for each
         element of the CBOR sequence that is an EDHOC_Information
         object, such an object MUST NOT include the element
         "exporter_out_len" defined in Section 5.1.2.

         The SVCB RR MUST be considered malformed if APP_PROF_SEQ is
         malformed or does not conform with the intended format.

         The CDDL grammar describing the CBOR data item edhoc-app-prof-
         value is shown in Figure 6.










Tiloca & Höglund          Expires 23 April 2026                [Page 26]

Internet-Draft         EDHOC Application Profiles           October 2025


      -  The presentation format value of "edhoc-app-prof" SHALL be the
         CBOR extended diagnostic notation (see Section 8 of [RFC8949]
         and Appendix G of [RFC8610]) of edhoc-app-prof-value in the
         wire-format value (see above).  When producing the presentation
         format value, care ought to be taken in representing Unicode
         with the limited ASCII character subset (e.g., by means of
         Punycode [RFC3492]) and in removing unnecessary common blank
         spaces within the CBOR extended diagnostic notation.

   If the SvcParamKey "edhoc-app-prof" is not present in the SVCB RR,
   then the SvcParamKey "edhocpath", if present, specifies the URI paths
   of EDHOC resources at the server.

   If the SvcParamKey "edhoc-app-prof" is present in the SVCB RR, then
   the following applies.

   *  If the SvcParamKey "edhocpath" is not present in the SVCB RR, then
      the value of the SvcParamKey "edhoc-app-prof" MUST be a CBOR byte
      string.

      The information specified by the SvcParamKey "edhoc-app-prof"
      pertains to the EDHOC resource at the server with URI path
      "/.well-known/edhoc".

   *  If the SvcParamKey "edhocpath" is present in the SVCB RR, then the
      following applies.

      -  If the value of the SvcParamKey "edhocpath" is a CBOR byte
         string, then the value of the SvcParamKey "edhoc-app-prof" MUST
         also be a CBOR byte string.

         The information specified by the SvcParamKey "edhoc-app-prof"
         pertains to the EDHOC resource at the server with URI path
         specified by the SvcParamKey "edhocpath".

      -  If the value of the SvcParamKey "edhocpath" is a CBOR array
         including N elements, then the value of the SvcParamKey "edhoc-
         app-prof" MUST also be a CBOR array including N elements.

         The information specified by the i-th element of the CBOR array
         within the SvcParamKey "edhoc-app-prof" pertains to the EDHOC
         resource at the server with URI path specified by the i-th
         element of the CBOR array within the SvcParamKey "edhocpath".

   A consumer MUST treat as malformed an SVCB RR, in case the
   SvcParamKeys "edhocpath" and "edhoc-app-prof", if present, do not
   comply with the format and restrictions defined above.




Tiloca & Höglund          Expires 23 April 2026                [Page 27]

Internet-Draft         EDHOC Application Profiles           October 2025


   edhocpath-value = PATH_BSTR / [2* PATH_BSTR]

   PATH_BSTR = bytes .cborseq PATH_SEQ

   ; This defines an array, the elements of which
   ; are to be used in the CBOR Sequence PATH_SEQ:
   PATH_SEQ = [* path_segment]

   path_segment = tstr

   Figure 4: CDDL Definition of the value of the SvcParamKey "edhocpath"

   path-absolute = "/" [ segment-nz *( "/" segment ) ]

   segment       = *pchar
   segment-nz    = 1*pchar

   pchar = unreserved / pct-encoded / sub-delims / ":" / "@"

   unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
   pct-encoded   = "%" HEXDIG HEXDIG
   sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                / "*" / "+" / "," / ";" / "="

                 Figure 5: ABNF Definition of path-absolute

   edhoc-app-prof-value = APP_BSTR / [2* APP_BSTR]

   ; The full definition of APP_PROF_SEQ
   ; is provided in Section 5.1
   APP_BSTR = bytes .cborseq APP_PROF_SEQ

     Figure 6: CDDL Definition of the value of the SvcParamKey "edhoc-
                                 app-prof"

7.  Well-known EDHOC Application Profiles

   This section defines a set of well-known EDHOC application profiles
   that are meant to reflect what is most common and expected to be
   supported by EDHOC peers.

   The well-known application profiles are _not_ to be intended as
   "default" profiles to use, in case no other indication is provided to
   EDHOC peers.







Tiloca & Höglund          Expires 23 April 2026                [Page 28]

Internet-Draft         EDHOC Application Profiles           October 2025


   In particular, an EDHOC peer MUST NOT assume that, unless otherwise
   indicated, any of such profiles is used when running EDHOC through a
   well-known EDHOC resource, such as the resource at /.well-known/edhoc
   when EDHOC messages are transported as payload of CoAP messages (see
   Appendix A.2 of [RFC9528]).

   Building on the above, the well-known application profiles are _not_
   intended to deviate from what is mandatory to support for EDHOC
   peers, which is defined by the compliance requirements in Section 8
   of [RFC9528].

   The rest of this section defines the well-known application profiles,
   each of which is represented by means of an EDHOC_Application_Profile
   object (see Section 2) using the CBOR extended diagnostic notation.

   An entry for each well-known application profile is also registered
   at the "EDHOC Application Profiles" registry defined in Section 10.8
   of this document.

7.1.  Well-Known Application Profile MINIMAL_CS_2

   {
           e'methods' : 3, / EDHOC Method Type 3 /
     e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
        e'cred_types' : 1, / CWT Claims Set (CCS) /
     e'id_cred_types' : 4, / kid /
          e'app_prof' : e'APP-PROF-MINIMAL-CS-2'
   }

   This application profile is aligned with the example trace of EDHOC
   compiled in Section 3 of [RFC9529].

7.2.  Well-Known Application Profile MINIMAL_CS_0

   {
           e'methods' : 3, / EDHOC Method Type 3 /
     e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
        e'cred_types' : 1, / CWT Claims Set (CCS) /
     e'id_cred_types' : 4, / kid /
          e'app_prof' : e'APP-PROF-MINIMAL-CS-0'
   }

7.3.  Well-Known Application Profile BASIC_CS_2_X509








Tiloca & Höglund          Expires 23 April 2026                [Page 29]

Internet-Draft         EDHOC Application Profiles           October 2025


   {
           e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
     e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
        e'cred_types' : [1, 2], / CWT Claims Set (CCS)
                                and X.509 certificate /
     e'id_cred_types' : [4, 34], / kid and x5t /
          e'app_prof' : e'APP-PROF-BASIC-CS-2-X509'
   }

   This application profile is aligned with the example trace of EDHOC
   compiled in Section 3 of [RFC9529].

7.4.  Well-Known Application Profile BASIC_CS_0_X509

   {
           e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
     e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
        e'cred_types' : [1, 2], / CWT Claims Set (CCS)
                                and X.509 certificate /
     e'id_cred_types' : [4, 34], / kid and x5t /
          e'app_prof' : e'APP-PROF-BASIC-CS-0-X509'
   }

   This application profile is aligned with the example trace of EDHOC
   compiled in Section 2 of [RFC9529].

7.5.  Well-Known Application Profile BASIC_CS_2_C509

   {
           e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
     e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
        e'cred_types' : [1, e'c509_cert'], / CWT Claims Set (CCS)
                                           and C509 certificate /
     e'id_cred_types' : [4, e'c5t'], / kid and c5t /
          e'app_prof' : e'APP-PROF-BASIC-CS-2-C509'
   }

7.6.  Well-Known Application Profile BASIC_CS_0_C509

   {
           e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
     e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
        e'cred_types' : [1, e'c509_cert'], / CWT Claims Set (CCS)
                                           and C509 certificate /
     e'id_cred_types' : [4, e'c5t'], / kid and c5t /
          e'app_prof' : e'APP-PROF-BASIC-CS-0-C509'
   }




Tiloca & Höglund          Expires 23 April 2026                [Page 30]

Internet-Draft         EDHOC Application Profiles           October 2025


7.7.  Well-Known Application Profile INTERMEDIATE_CS_2

   {
           e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
     e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
        e'cred_types' : [1, 2, e'c509_cert'], / CWT Claims Set (CCS),
                                              X.509 certificate,
                                              and C509 certificate /
     e'id_cred_types' : [4, 14, 34, 33, e'c5t', e'c5c'], / kid, kccs,
                                                         x5t, x5chain,
                                                         c5t, and c5c /
          e'app_prof' : e'APP-PROF-INTERMEDIATE-CS-2'
   }

   This application profile is aligned with the example trace of EDHOC
   compiled in Section 3 of [RFC9529].

7.8.  Well-Known Application Profile INTERMEDIATE_CS_0

   {
           e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
     e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
        e'cred_types' : [1, 2, e'c509_cert'], / CWT Claims Set (CCS),
                                                X.509 certificate,
                                                and C509 certificate /
     e'id_cred_types' : [4, 14, 34, 33, e'c5t', e'c5c'], / kid, kccs,
                                                         x5t, x5chain,
                                                         c5t, and c5c /
          e'app_prof' : e'APP-PROF-INTERMEDIATE-CS-0'
   }

   This application profile is aligned with the example trace of EDHOC
   compiled in Section 2 of [RFC9529].

7.9.  Well-Known Application Profile EXTENSIVE
















Tiloca & Höglund          Expires 23 April 2026                [Page 31]

Internet-Draft         EDHOC Application Profiles           October 2025


   {
           e'methods' : [0, 1, 2, 3], / EDHOC Method Types
                                        0, 1, 2, and 3 /
     e'cipher_suites' : [0, 1, 2, 3], / EDHOC Cipher Suites
                                        0, 1, 2, and 3 /
        e'cred_types' : [1, 0, 2, e'c509_cert'], / CWT Claims Set (CCS),
                                                 CWT, X.509 certificate,
                                                 and C509 certificate /
     e'id_cred_types' : [4, 14, 13, 34, 33, e'c5t', e'c5c'], / kid,
                                                             kccs, kcwt,
                                                             x5t,
                                                             x5chain,
                                                             c5t, and
                                                             c5c /
          e'app_prof' : e'APP-PROF-EXTENSIVE'
   }

   This application profile is aligned with the example traces of EDHOC
   compiled in Sections 2 and 3 of [RFC9529].

8.  Identifiers of Well-known EDHOC Application Profiles

   This document defines the following identifiers of well-known EDHOC
   application profiles.

   Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
   with the RFC number of this specification and delete this paragraph.

    +=========+===================+======================+============+
    | Profile | Name              | Description          | Reference  |
    | ID      |                   |                      |            |
    +=========+===================+======================+============+
    | 0       | MINIMAL-CS-2      | Method 3; Cipher     | [RFC-XXXX] |
    |         |                   | Suite 2; CCS; kid    |            |
    +---------+-------------------+----------------------+------------+
    | 1       | MINIMAL-CS-0      | Method 3; Cipher     | [RFC-XXXX] |
    |         |                   | Suite 0; CCS; kid    |            |
    +---------+-------------------+----------------------+------------+
    | 2       | BASIC-CS-2-X509   | Methods (0, 3);      | [RFC-XXXX] |
    |         |                   | Cipher Suite 2;      |            |
    |         |                   | (CCS, X.509          |            |
    |         |                   | certificates); (kid, |            |
    |         |                   | x5t)                 |            |
    +---------+-------------------+----------------------+------------+
    | 3       | BASIC-CS-0-X509   | Methods (0, 3);      | [RFC-XXXX] |
    |         |                   | Cipher Suite 0;      |            |
    |         |                   | (CCS, X.509          |            |
    |         |                   | certificates); (kid, |            |



Tiloca & Höglund          Expires 23 April 2026                [Page 32]

Internet-Draft         EDHOC Application Profiles           October 2025


    |         |                   | x5t)                 |            |
    +---------+-------------------+----------------------+------------+
    | 4       | BASIC-CS-2-C509   | Methods (0, 3);      | [RFC-XXXX] |
    |         |                   | Cipher Suite 2;      |            |
    |         |                   | (CCS, C509           |            |
    |         |                   | certificates); (kid, |            |
    |         |                   | c5t)                 |            |
    +---------+-------------------+----------------------+------------+
    | 5       | BASIC-CS_0-C509   | Methods (0, 3);      | [RFC-XXXX] |
    |         |                   | Cipher Suite 0;      |            |
    |         |                   | (CCS, C509           |            |
    |         |                   | certificates); (kid, |            |
    |         |                   | c5t)                 |            |
    +---------+-------------------+----------------------+------------+
    | 6       | INTERMEDIATE-CS-2 | Methods (0, 3);      | [RFC-XXXX] |
    |         |                   | Cipher Suite 2;      |            |
    |         |                   | (CCS, X.509/C509     |            |
    |         |                   | certificates); (kid, |            |
    |         |                   | kccs, x5t, x5chain,  |            |
    |         |                   | c5t, c5c)            |            |
    +---------+-------------------+----------------------+------------+
    | 7       | INTERMEDIATE-CS-0 | Methods (0, 3);      | [RFC-XXXX] |
    |         |                   | Cipher Suite 0;      |            |
    |         |                   | (CCS, X.509/C509     |            |
    |         |                   | certificates); (kid, |            |
    |         |                   | kccs, x5t, x5chain,  |            |
    |         |                   | c5t, c5c)            |            |
    +---------+-------------------+----------------------+------------+
    | 8       | EXTENSIVE         | Methods (0, 1, 2,    | [RFC-XXXX] |
    |         |                   | 3); Cipher Suites    |            |
    |         |                   | (0, 1, 2, 3); (CCS,  |            |
    |         |                   | CWT, X.509/C509      |            |
    |         |                   | certificates); (kid, |            |
    |         |                   | kccs, kcwt, x5t,     |            |
    |         |                   | x5chain, c5t, c5c)   |            |
    +---------+-------------------+----------------------+------------+

               Table 3: EDHOC Well-known Application Profiles

9.  Security Considerations

   TBD

10.  IANA Considerations

   This document has the following actions for IANA.





Tiloca & Höglund          Expires 23 April 2026                [Page 33]

Internet-Draft         EDHOC Application Profiles           October 2025


   Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
   with the RFC number of this specification and delete this paragraph.

10.1.  Media Type Registrations

   IANA is asked to register the media type "application/edhoc-app-
   profile+cbor-seq".  This registration follows the procedures
   specified in [RFC6838].

   Type name: application

   Subtype name: edhoc-app-profile+cbor-seq

   Required parameters: N/A

   Optional parameters: N/A

   Encoding considerations: Must be encoded as a CBOR sequence [RFC8742]
   of CBOR maps [RFC8949].  Each element of each CBOR map is also
   defined as an element of the CBOR-encoded EDHOC_Information object
   from Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile].

   Security considerations: See Section 9 of [RFC-XXXX].

   Interoperability considerations: N/A

   Published specification: [RFC-XXXX]

   Applications that use this media type: Applications that need to
   describe, distribute, and store a representation of an EDHOC
   application profile (see [RFC-XXXX] and Section 3.9 of [RFC9528]).

   Fragment identifier considerations: N/A

   Additional information: N/A

   Person & email address to contact for further information: LAKE WG
   mailing list (lake@ietf.org) or IETF Applications and Real-Time Area
   (art@ietf.org)

   Intended usage: COMMON

   Restrictions on usage: None

   Author/Change controller: IETF

   Provisional registration: No




Tiloca & Höglund          Expires 23 April 2026                [Page 34]

Internet-Draft         EDHOC Application Profiles           October 2025


10.2.  CoAP Content-Formats Registry

   IANA is asked to add the following entry to the "CoAP Content-
   Formats" registry within the "Constrained RESTful Environments (CoRE)
   Parameters" registry group.

   Content Type: application/edhoc-app-profile+cbor-seq

   Content Coding: -

   ID: TBD (range 0-255)

   Reference: [RFC-XXXX]

10.3.  Target Attributes Registry

   IANA is asked to register the following entries in the "Target
   Attributes" registry within the "Constrained RESTful Environments
   (CoRE) Parameters", as per [RFC9423].

   *  Attribute Name: ed-max-msgsize

   *  Brief Description: The admitted maximum size of EDHOC messages in
      bytes

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-coap-ct

   *  Brief Description: Requested use of the CoAP Content-Format Option
      in CoAP messages whose payload includes exclusively an EDHOC
      message, possibly prepended by an EDHOC connection identifier

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-epid-t

   *  Brief Description: A supported type of endpoint identity for EDHOC

   *  Change Controller: IETF



Tiloca & Höglund          Expires 23 April 2026                [Page 35]

Internet-Draft         EDHOC Application Profiles           October 2025


   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-tp

   *  Brief Description: A supported means for transporting EDHOC
      messages

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-prof

   *  Brief Description: A supported EDHOC application profile

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-ta-edcred-uuid

   *  Brief Description: Identifier of a supported trust anchor for
      verifying authentication credentials of other EDHOC peers, as a
      UUID

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-ta-edcred-kid

   *  Brief Description: Identifier of a supported trust anchor for
      verifying authentication credentials of other EDHOC peers, as a
      binary key identifier

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]





Tiloca & Höglund          Expires 23 April 2026                [Page 36]

Internet-Draft         EDHOC Application Profiles           October 2025


   *  Attribute Name: ed-ta-edcred-c5t

   *  Brief Description: Identifier of a supported trust anchor for
      verifying authentication credentials of other EDHOC peers, as a
      hash of a C509 certificate

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-ta-edcred-c5u

   *  Brief Description: Identifier of a supported trust anchor for
      verifying authentication credentials of other EDHOC peers, as a
      URI pointing to a C509 certificate

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-ta-edcred-x5t

   *  Brief Description: Identifier of a supported trust anchor for
      verifying authentication credentials of other EDHOC peers, as a
      hash of an X.509 certificate

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-ta-edcred-x5u

   *  Brief Description: Identifier of a supported trust anchor for
      verifying authentication credentials of other EDHOC peers, as a
      URI pointing to an X.509 certificate

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]






Tiloca & Höglund          Expires 23 April 2026                [Page 37]

Internet-Draft         EDHOC Application Profiles           October 2025


10.4.  EDHOC Information Registry

   IANA is asked to register the following entries in the "EDHOC
   Information" registry defined in [I-D.ietf-ace-edhoc-oscore-profile].

   *  Name: exporter_out_len

   *  CBOR label: 22 (suggested)

   *  CBOR type: array

   *  Registry: EDHOC Exporter Labels

   *  Description: Set of output lengths to use with the EDHOC_Exporter
      interface

   *  Type: P

   *  Specification: [RFC-XXXX][RFC9528]



   *  Name: app_prof

   *  CBOR label: 23 (suggested)

   *  CBOR type: int or array

   *  Registry: EDHOC Application Profiles registry

   *  Description: Set of supported EDHOC application profiles

   *  Type: NP

   *  Specification: [RFC-XXXX][RFC9528]

10.5.  EDHOC External Authorization Data Registry

   IANA is asked to register the following entry in the "EDHOC External
   Authorization Data" registry within the "Ephemeral Diffie-Hellman
   Over COSE (EDHOC)" registry group defined in [RFC9528].

   *  Name: Supported EDHOC application profiles

   *  Label: TBD_EAD_LABEL (range 0-23)

   *  Description: Set of supported EDHOC application profiles




Tiloca & Höglund          Expires 23 April 2026                [Page 38]

Internet-Draft         EDHOC Application Profiles           October 2025


   *  Reference: [RFC-XXXX]

10.6.  EDHOC Error Codes Registry

   IANA is asked to register the following entry in the "EDHOC Error
   Codes" registry within the "Ephemeral Diffie-Hellman Over COSE
   (EDHOC)" registry group defined in [RFC9528].

   *  ERR_CODE: TBD_ERROR_CODE (range -24 to 23)

   *  ERR_INFO Type: app_profiles

   *  Description: Supported EDHOC application profiles

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]

10.7.  DNS SVCB Service Parameter Keys (SvcParamKeys)

   IANA is asked to add the following entries to the "Service Parameter
   Keys (SvcParamKeys)" registry within the "DNS Service Bindings
   (SVCB)" registry group.  The definition of these parameters can be
   found in Section 6.

   *  Number: 11 (suggested)

   *  Name: edhocpath

   *  Meaning: EDHOC resource path

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Number: 12 (suggested)

   *  Name: edhoc-app-prof

   *  Meaning: Supported EDHOC application profiles

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]





Tiloca & Höglund          Expires 23 April 2026                [Page 39]

Internet-Draft         EDHOC Application Profiles           October 2025


10.8.  EDHOC Application Profiles Registry

   IANA is requested to create a new "EDHOC Application Profiles"
   registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)"
   registry group defined in [RFC9528].

   The registration policy is either "Private Use", "Standards Action
   with Expert Review", or "Specification Required" per Section 4.6 of
   [RFC8126].  "Expert Review" guidelines are provided in Section 10.9.

   All assignments according to "Standards Action with Expert Review"
   are made on a "Standards Action" basis per Section 4.9 of [RFC8126],
   with Expert Review additionally required per Section 4.5 of
   [RFC8126].  The procedure for early IANA allocation of Standards
   Track code points defined in [RFC7120] also applies.  When such a
   procedure is used, IANA will ask the designated expert(s) to approve
   the early allocation before registration.  In addition, WG chairs are
   encouraged to consult the expert(s) early during the process outlined
   in Section 3.1 of [RFC7120].

   The columns of this registry are:

   *  Profile ID: This field contains the value used to identify the
      EDHOC application profile.  These values MUST be unique.  The
      value can be a positive integer or a negative integer.  Different
      ranges of values use different registration policies [RFC8126].
      Integer values from -24 to 23 are designated as "Standards Action
      With Expert Review".  Integer values from -65536 to -25 and from
      24 to 65535 are designated as "Specification Required".  Integer
      values smaller than -65536 and greater than 65535 are marked as
      "Private Use".

   *  Name: This field contains the name of the EDHOC application
      profile.

   *  Description: This field contains a short description of the EDHOC
      application profile.

   *  Reference: This field contains a pointer to the public
      specification for the EDHOC application profile.

   This registry has been initially populated with the values in
   Table 3.








Tiloca & Höglund          Expires 23 April 2026                [Page 40]

Internet-Draft         EDHOC Application Profiles           October 2025


10.9.  Expert Review Instructions

   "Standards Action with Expert Review" and "Specification Required"
   are two of the registration policies defined for the IANA registry
   established in this document.  This section gives some general
   guidelines for what the experts should be looking for, but they are
   being designated as experts for a reason so they should be given
   substantial latitude.

   Expert reviewers should take into consideration the following points:

   *  Clarity and correctness of registrations.  Experts are expected to
      check the clarity of purpose and use of the requested entries.
      Experts need to make sure that the object of registration is
      clearly defined in the corresponding specification.  Entries that
      do not meet these objective of clarity and completeness must not
      be registered.

   *  Point squatting should be discouraged.  Reviewers are encouraged
      to get sufficient information for registration requests to ensure
      that the usage is not going to duplicate one that is already
      registered and that the point is likely to be used in deployments.
      The zones tagged as "Private Use" are intended for testing
      purposes and closed environments.  Code points in other ranges
      should not be assigned for testing.

   *  Specifications are required for the "Standards Action With Expert
      Review" range of point assignment.  Specifications should exist
      for "Specification Required" ranges, but early assignment before a
      specification is available is considered to be permissible.  When
      specifications are not provided, the description provided needs to
      have sufficient information to identify what the point is being
      used for.

   *  Experts should take into account the expected usage of fields when
      approving point assignment.  Documents published via Standards
      Action can also register points outside the Standards Action
      range.  The length of the encoded value should be weighed against
      how many code points of that length are left, the size of device
      it will be used on, and the number of code points left that encode
      to that size.

11.  References

11.1.  Normative References






Tiloca & Höglund          Expires 23 April 2026                [Page 41]

Internet-Draft         EDHOC Application Profiles           October 2025


   [EDHOC.Exporter.Labels]
              IANA, "EDHOC Exporter Labels",
              <https://www.iana.org/assignments/edhoc/edhoc.xhtml#edhoc-
              exporter-labels>.

   [I-D.ietf-ace-edhoc-oscore-profile]
              Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund,
              "Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object
              Security for Constrained Environments (OSCORE) Profile for
              Authentication and Authorization for Constrained
              Environments (ACE)", Work in Progress, Internet-Draft,
              draft-ietf-ace-edhoc-oscore-profile-08, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ace-
              edhoc-oscore-profile-08>.

   [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-15, 18 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
              cbor-encoded-cert-15>.

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

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/rfc/rfc3986>.

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

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <https://www.rfc-editor.org/rfc/rfc6690>.

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




Tiloca & Höglund          Expires 23 April 2026                [Page 42]

Internet-Draft         EDHOC Application Profiles           October 2025


   [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
              Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
              2014, <https://www.rfc-editor.org/rfc/rfc7120>.

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

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

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

   [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
              DOI 10.17487/RFC8288, October 2017,
              <https://www.rfc-editor.org/rfc/rfc8288>.

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

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/rfc/rfc8613>.

   [RFC8742]  Bormann, C., "Concise Binary Object Representation (CBOR)
              Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8742>.

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

   [RFC9200]  Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments Using the OAuth 2.0 Framework
              (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9200>.




Tiloca & Höglund          Expires 23 April 2026                [Page 43]

Internet-Draft         EDHOC Application Profiles           October 2025


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

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

   [RFC9461]  Schwartz, B., "Service Binding Mapping for DNS Servers",
              RFC 9461, DOI 10.17487/RFC9461, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9461>.

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

   [RFC9562]  Davis, K., Peabody, B., and P. Leach, "Universally Unique
              IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
              2024, <https://www.rfc-editor.org/rfc/rfc9562>.

   [RFC9668]  Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
              G. Selander, "Using Ephemeral Diffie-Hellman Over COSE
              (EDHOC) with the Constrained Application Protocol (CoAP)
              and Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 9668, DOI 10.17487/RFC9668, November 2024,
              <https://www.rfc-editor.org/rfc/rfc9668>.

11.2.  Informative References

   [I-D.serafin-lake-ta-hint]
              Serafin, M. and G. Selander, "Trust Anchor Hints in
              Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in
              Progress, Internet-Draft, draft-serafin-lake-ta-hint-00,
              21 October 2024, <https://datatracker.ietf.org/doc/html/
              draft-serafin-lake-ta-hint-00>.

   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications
              (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
              <https://www.rfc-editor.org/rfc/rfc3492>.

   [RFC9423]  Bormann, C., "Constrained RESTful Environments (CoRE)
              Target Attributes Registry", RFC 9423,
              DOI 10.17487/RFC9423, April 2024,
              <https://www.rfc-editor.org/rfc/rfc9423>.



Tiloca & Höglund          Expires 23 April 2026                [Page 44]

Internet-Draft         EDHOC Application Profiles           October 2025


   [RFC9529]  Selander, G., Preuß Mattsson, J., Serafin, M., Tiloca, M.,
              and M. Vučinić, "Traces of Ephemeral Diffie-Hellman Over
              COSE (EDHOC)", RFC 9529, DOI 10.17487/RFC9529, March 2024,
              <https://www.rfc-editor.org/rfc/rfc9529>.

Appendix A.  CDDL Model

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

   ; EDHOC Information
   methods = 1
   cipher_suites = 2
   cred_types = 6
   id_cred_types = 7
   app_prof = 23

   ; EDHOC Application Profiles
   APP-PROF-MINIMAL-CS-2 = 0
   APP-PROF-MINIMAL-CS-0 = 1
   APP-PROF-BASIC-CS-2-X509 = 2
   APP-PROF-BASIC-CS-0-X509 = 3
   APP-PROF-BASIC-CS-2-C509 = 4
   APP-PROF-BASIC-CS-0-C509 = 5
   APP-PROF-INTERMEDIATE-CS-2 = 6
   APP-PROF-INTERMEDIATE-CS-0 = 7
   APP-PROF-EXTENSIVE = 8

   ; COSE Header Parameters
   c5t = 22
   c5c = 25

   ; EDHOC Authentication Credential Types
   c509_cert = 3

                            Figure 7: CDDL model

Appendix B.  Document Updates

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

B.1.  Version -02 to -03

   *  Removed restrictions on the scope of the EDHOC_Application_Profile
      object.

   *  Forbidden violations of prescriptive indications in the EAD item.
      The EDHOC session fails if such a violation is detected.




Tiloca & Höglund          Expires 23 April 2026                [Page 45]

Internet-Draft         EDHOC Application Profiles           October 2025


   *  Extended semantics of ead_value: optional boolean flag when the
      EAD item is used in EDHOC message_1.

   *  Defined parameter "exporter_out_len", for in-band negotiation of
      EDHOC_Exporter output lengths through the EAD item "Supported
      EDHOC application profiles".

   *  Specified wire-format and presentation format for the
      SvcParamKeys.

   *  Fixed errors in CDDL notations.

   *  Specified type of "app_prof" in the IANA registration request.

   *  Clarifications and editorial improvements.

B.2.  Version -01 to -02

   *  Revised order of sections.

   *  Use of parameters aligned with corresponding updates in draft-
      ietf-ace-edhoc-oscore-profile.

   *  EAD item "Supported EDHOC application profiles":

      -  It can be used only in a critical way.

      -  Improved semantics of ead_value.

      -  Content restrictions to avoid inconsistent information.

   *  Use of the parameter "app_prof" in draft-ietf-ace-edhoc-oscore-
      profile:

      -  Improved co-existence with other parameters.

      -  Content restrictions to avoid inconsistent information.

   *  Error handling:

      -  EAD item "Supported EDHOC application profiles" occurring
         multiple times in EDHOC message_1 or message_2.

      -  EAD item "Supported EDHOC application profiles" in EDHOC
         message_3 or message_4.

      -  Invalid ead_value in EAD item "Supported EDHOC application
         profiles".



Tiloca & Höglund          Expires 23 April 2026                [Page 46]

Internet-Draft         EDHOC Application Profiles           October 2025


      -  Invalid information in EDHOC error message with new error code.

   *  Fixed encoding of ERR_INFO for the EDHOC error message with the
      new error code.

   *  EDHOC_Application_Profile object

      -  Clarified scope.

      -  Clarified meaning of boolean parameters that are non-
         prescriptive.

      -  Forbid the presence of the element "trust_anchors".

   *  Advertisement of Supported EDHOC Application Profiles using SVCB
      Resource Records.

   *  Updated integer abbreviations for the EDHOC_Information
      parameters.

   *  Editorial improvements.

B.3.  Version -00 to -01

   *  Clarified motivation in the abstract and introduction.

   *  Moved definition of EDHOC_Information parameters to draft-ietf-
      ace-edhoc-oscore-profile.

   *  Renamed ed-idep-t x as ed-epid-t.

   *  Content-Format abbreviated as "ct" (not "cf").

   *  CBOR abbreviation of "app_prof" changed to 23.

   *  Added preamble on identifying application profiles by Profile ID.

   *  Defined target attributes "ed-ta-*" for specifying supported trust
      anchors.

   *  Defined new EAD item and error code to advertise supported EDHOC
      application profiles.

   *  Defined how to handle non admitted parameters.

   *  Renamed well-known EDHOC application profiles.

   *  Updated IANA considerations:



Tiloca & Höglund          Expires 23 April 2026                [Page 47]

Internet-Draft         EDHOC Application Profiles           October 2025


      -  Suggested range 0-255 for CoAP Content-Format ID.

      -  Requested registration for target attributes "ed-ta-*".

      -  Removed requests for registration of removed parameters.

   *  Updated references.

   *  Editorial improvements.

Acknowledgments

   The authors sincerely thank Christian Amsüss, Carsten Bormann,
   Geovane Fedrecheski, Martine Lenders, Elsa Lopez-Perez, Michael
   Richardson, Göran Selander, Brian Sipos, and Mališa Vučinić for their
   feedback and comments.

   The target attributes "ed-ta-*" for specifying supported trust
   anchors build on a proposal originally described in
   [I-D.serafin-lake-ta-hint].

   This work was supported by the Sweden's Innovation Agency VINNOVA
   within the EUREKA CELTIC-NEXT project CYPRESS.

Authors' Addresses

   Marco Tiloca
   RISE AB
   Isafjordsgatan 22
   SE-16440 Stockholm Kista
   Sweden
   Email: marco.tiloca@ri.se


   Rikard Höglund
   RISE AB
   Isafjordsgatan 22
   SE-16440 Stockholm Kista
   Sweden
   Email: rikard.hoglund@ri.se











Tiloca & Höglund          Expires 23 April 2026                [Page 48]


