# 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: []
tags: []
fetched_at: 2026-03-04T00:00:05.801587+00:00
source: ietf
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-03-03T16:23:32Z
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.811607+00:00
source: ietf
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/108/", "/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: 07
title: EDHOC Authenticated with Pre-Shared Keys (PSK)
time: 2026-03-02T08:39:12Z
group_uri: /api/v1/group/group/2249/
expires: 2026-09-03T08:39:12Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/145/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.825896+00:00
source: ietf
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.833086+00:00
source: ietf
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.836304+00:00
source: ietf
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.840108+00:00
source: ietf
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.843416+00:00
source: ietf
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.847365+00:00
source: ietf
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.851268+00:00
source: ietf
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: 04
title: Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC)
time: 2026-03-02T14:48:42Z
group_uri: /api/v1/group/group/2249/
expires: 2026-09-03T14:48:42Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.854737+00:00
source: ietf
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]


