doc: Add RFC documents

1 files changed, 4671 insertions, 0 deletions

diff --git a/doc/rfc/rfc9528.txt b/doc/rfc/rfc9528.txt
new file mode 100644
index 0000000..8af13e8
--- /dev/null
+++ b/doc/rfc/rfc9528.txt
@@ -0,0 +1,4671 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       G. Selander
+Request for Comments: 9528                             J. Preuß Mattsson
+Category: Standards Track                                   F. Palombini
+ISSN: 2070-1721                                                 Ericsson
+                                                              March 2024
+
+
+               Ephemeral Diffie-Hellman Over COSE (EDHOC)
+
+Abstract
+
+   This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
+   very compact and lightweight authenticated Diffie-Hellman key
+   exchange with ephemeral keys.  EDHOC provides mutual authentication,
+   forward secrecy, and identity protection.  EDHOC is intended for
+   usage in constrained scenarios, and a main use case is to establish
+   an Object Security for Constrained RESTful Environments (OSCORE)
+   security context.  By reusing CBOR Object Signing and Encryption
+   (COSE) for cryptography, Concise Binary Object Representation (CBOR)
+   for encoding, and Constrained Application Protocol (CoAP) for
+   transport, the additional code size can be kept very low.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9528.
+
+Copyright Notice
+
+   Copyright (c) 2024 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
+     1.1.  Motivation
+     1.2.  Message Size Examples
+     1.3.  Document Structure
+     1.4.  Terminology and Requirements Language
+   2.  EDHOC Outline
+   3.  Protocol Elements
+     3.1.  General
+     3.2.  Method
+     3.3.  Connection Identifiers
+     3.4.  Transport
+     3.5.  Authentication Parameters
+     3.6.  Cipher Suites
+     3.7.  Ephemeral Public Keys
+     3.8.  External Authorization Data (EAD)
+     3.9.  Application Profile
+   4.  Key Derivation
+     4.1.  Keys for EDHOC Message Processing
+     4.2.  Keys for EDHOC Applications
+   5.  Message Formatting and Processing
+     5.1.  EDHOC Message Processing Outline
+     5.2.  EDHOC Message 1
+     5.3.  EDHOC Message 2
+     5.4.  EDHOC Message 3
+     5.5.  EDHOC Message 4
+   6.  Error Handling
+     6.1.  Success
+     6.2.  Unspecified Error
+     6.3.  Wrong Selected Cipher Suite
+     6.4.  Unknown Credential Referenced
+   7.  EDHOC Message Deduplication
+   8.  Compliance Requirements
+   9.  Security Considerations
+     9.1.  Security Properties
+     9.2.  Cryptographic Considerations
+     9.3.  Cipher Suites and Cryptographic Algorithms
+     9.4.  Post-Quantum Considerations
+     9.5.  Unprotected Data and Privacy
+     9.6.  Updated Internet Threat Model Considerations
+     9.7.  Denial of Service
+     9.8.  Implementation Considerations
+   10. IANA Considerations
+     10.1.  EDHOC Exporter Label Registry
+     10.2.  EDHOC Cipher Suites Registry
+     10.3.  EDHOC Method Type Registry
+     10.4.  EDHOC Error Codes Registry
+     10.5.  EDHOC External Authorization Data Registry
+     10.6.  COSE Header Parameters Registry
+     10.7.  Well-Known URI Registry
+     10.8.  Media Types Registry
+     10.9.  CoAP Content-Formats Registry
+     10.10. Resource Type (rt=) Link Target Attribute Values Registry
+     10.11. Expert Review Instructions
+   11. References
+     11.1.  Normative References
+     11.2.  Informative References
+   Appendix A.  Use with OSCORE and Transfer over CoAP
+     A.1.  Deriving the OSCORE Security Context
+     A.2.  Transferring EDHOC over CoAP
+   Appendix B.  Compact Representation
+   Appendix C.  Use of CBOR, CDDL, and COSE in EDHOC
+     C.1.  CBOR and CDDL
+     C.2.  CDDL Definitions
+     C.3.  COSE
+   Appendix D.  Authentication-Related Verifications
+     D.1.  Validating the Authentication Credential
+     D.2.  Identities
+     D.3.  Certification Path and Trust Anchors
+     D.4.  Revocation Status
+     D.5.  Unauthenticated Operation
+   Appendix E.  Use of External Authorization Data
+   Appendix F.  Application Profile Example
+   Appendix G.  Long PLAINTEXT_2
+   Appendix H.  EDHOC_KeyUpdate
+   Appendix I.  Example Protocol State Machine
+     I.1.  Initiator State Machine
+     I.2.  Responder State Machine
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+1.1.  Motivation
+
+   Many Internet of Things (IoT) deployments require technologies that
+   are highly performant in constrained environments [RFC7228].  IoT
+   devices may be constrained in various ways, including memory,
+   storage, processing capacity, and power.  The connectivity for these
+   settings may also exhibit constraints, such as unreliable and lossy
+   channels, highly restricted bandwidth, and dynamic topology.  The
+   IETF has acknowledged this problem by standardizing a range of
+   lightweight protocols and enablers designed for the IoT, including
+   CoAP [RFC7252], CBOR [RFC8949], and Static Context Header Compression
+   (SCHC) [RFC8724].
+
+   The need for special protocols targeting constrained IoT deployments
+   extends also to the security domain [LAKE-REQS].  Important
+   characteristics in constrained environments are the number of round
+   trips and protocol message sizes, which (if kept low) can contribute
+   to good performance by enabling transport over a small number of
+   radio frames, reducing latency due to fragmentation, duty cycles,
+   etc.  Another important criterion is code size, which may be
+   prohibitively large for certain deployments due to device
+   capabilities or network load during firmware updates.  Some IoT
+   deployments also need to support a variety of underlying transport
+   technologies, potentially even with a single connection.
+
+   Some security solutions for such settings exist already.  COSE
+   [RFC9052] specifies basic application-layer security services
+   efficiently encoded in CBOR.  Another example is OSCORE [RFC8613],
+   which is a lightweight communication security extension to CoAP using
+   CBOR and COSE.  In order to establish good quality cryptographic keys
+   for security protocols such as COSE and OSCORE, the two endpoints may
+   run an authenticated Diffie-Hellman key exchange protocol, from which
+   shared secret keying material can be derived.  Such a key exchange
+   protocol should also be lightweight to prevent bad performance in
+   case of repeated use, e.g., due to device rebooting or frequent
+   rekeying for security reasons or to avoid latencies in a network
+   formation setting with many devices authenticating at the same time.
+
+   This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
+   lightweight authenticated key exchange protocol providing good
+   security properties including forward secrecy, identity protection,
+   and cipher suite negotiation.  Authentication can be based on raw
+   public keys (RPKs) or public key certificates and requires the
+   application to provide input on how to verify that endpoints are
+   trusted.  This specification supports the referencing of credentials
+   in order to reduce message overhead, but credentials may
+   alternatively be embedded in the messages.  EDHOC does not currently
+   support Pre-Shared Key (PSK) authentication as authentication with
+   static Diffie-Hellman (DH) public keys by reference produces equally
+   small message sizes but with much simpler key distribution and
+   identity protection.
+
+   EDHOC makes use of known protocol constructions, such as SIGn-and-MAc
+   [SIGMA], the Noise XX pattern [Noise], and Extract-and-Expand
+   [RFC5869].  EDHOC uses COSE for cryptography and identification of
+   credentials (including COSE_Key, CBOR Web Token (CWT), CWT Claims Set
+   (CCS), X.509, and CBOR-encoded X.509 (C509) certificates; see
+   Section 3.5.2).  COSE provides crypto agility and enables the use of
+   future algorithms and credential types targeting IoT.
+
+   EDHOC is designed for highly constrained settings, making it
+   especially suitable for low-power networks [RFC8376] such as Cellular
+   IoT, IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH), and LoRaWAN.
+   A main objective for EDHOC is to be a lightweight authenticated key
+   exchange for OSCORE, i.e., to provide authentication and session key
+   establishment for IoT use cases such as those built on CoAP [RFC7252]
+   involving 'things' with embedded microcontrollers, sensors, and
+   actuators.  By reusing the same lightweight primitives as OSCORE
+   (CBOR, COSE, and CoAP), the additional code size can be kept very
+   low.  Note that while CBOR and COSE primitives are built into the
+   protocol messages, EDHOC is not bound to a particular transport.
+
+   A typical setting is when one of the endpoints is constrained or in a
+   constrained network and the other endpoint is a node on the Internet
+   (such as a mobile phone).  Thing-to-thing interactions over
+   constrained networks are also relevant since both endpoints would
+   then benefit from the lightweight properties of the protocol.  EDHOC
+   could, e.g., be run when a device connects for the first time or to
+   establish fresh keys that are not revealed by a later compromise of
+   the long-term keys.
+
+1.2.  Message Size Examples
+
+   Examples of EDHOC message sizes are shown in Table 1, which use
+   different kinds of authentication keys and COSE header parameters for
+   identification, including static Diffie-Hellman keys or signature
+   keys, either in CWT/CCS [RFC8392] identified by a key identifier
+   using 'kid' [RFC9052] or in X.509 certificates identified by a hash
+   value using 'x5t' [RFC9360].  EDHOC always uses ephemeral-ephemeral
+   key exchange.  As a comparison, in the case of RPK authentication and
+   when transferred in CoAP, the EDHOC message size can be less than 1/7
+   of the DTLS 1.3 handshake [RFC9147] with Ephemeral Elliptic Curve
+   Diffie-Hellman (ECDHE) and connection ID; see [CoAP-SEC-PROT].
+
+              +===========+================+================+
+              |           | Static DH Keys | Signature Keys |
+              +===========+==========+=====+==========+=====+
+              |           |      kid | x5t |      kid | x5t |
+              +===========+==========+=====+==========+=====+
+              | message_1 |       37 |  37 |       37 |  37 |
+              +-----------+----------+-----+----------+-----+
+              | message_2 |       45 |  58 |      102 | 115 |
+              +-----------+----------+-----+----------+-----+
+              | message_3 |       19 |  33 |       77 |  90 |
+              +-----------+----------+-----+----------+-----+
+              | Total     |      101 | 128 |      216 | 242 |
+              +-----------+----------+-----+----------+-----+
+
+                Table 1: Examples of EDHOC Message Sizes in
+                                   Bytes
+
+1.3.  Document Structure
+
+   The remainder of the document is organized as follows: Section 2
+   outlines EDHOC authenticated with signature keys; Section 3 describes
+   the protocol elements of EDHOC, including formatting of the ephemeral
+   public keys; Section 4 specifies the key derivation; Section 5
+   specifies message processing for EDHOC authenticated with signature
+   keys or static Diffie-Hellman keys; Section 6 describes the error
+   messages; Section 7 describes EDHOC support for transport that does
+   not handle message duplication; and Section 8 lists compliance
+   requirements.  Note that normative text is also used in appendices,
+   in particular Appendix A.
+
+1.4.  Terminology and Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   Readers are expected to be familiar with the terms and concepts
+   described in 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.  Examples
+   of CBOR and CDDL are provided in Appendix C.1.  When referring to
+   CBOR, this specification always refers to Deterministically Encoded
+   CBOR, as specified in Sections 4.2.1 and 4.2.2 of [RFC8949].  The
+   single output from authenticated encryption (including the
+   authentication tag) is called "ciphertext", following [RFC5116].
+
+2.  EDHOC Outline
+
+   EDHOC supports different authentication methods of the ephemeral-
+   ephemeral Diffie-Hellman key exchange.  This document specifies
+   authentication methods based on signature keys and static Diffie-
+   Hellman keys.  This section outlines the signature-key-based method.
+   Further details of protocol elements and other authentication methods
+   are provided in the remainder of this document.
+
+   SIGn-and-MAc (SIGMA) is a family of theoretical protocols with a
+   number of variants [SIGMA].  Like in Internet Key Exchange Protocol
+   Version 2 (IKEv2) [RFC7296] and (D)TLS 1.3 [RFC8446] [RFC9147], EDHOC
+   authenticated with signature keys is built on a variant of the SIGMA
+   protocol, SIGMA-I, which provides identity protection against active
+   attacks on the party initiating the protocol.  Also like IKEv2, EDHOC
+   implements the MAC-then-Sign variant of the SIGMA-I protocol.  The
+   message flow (excluding an optional fourth message) is shown in
+   Figure 1.
+
+   Initiator                                                   Responder
+   |                                G_X                                |
+   +------------------------------------------------------------------>|
+   |                                                                   |
+   |      G_Y, Enc( ID_CRED_R, Sig( R; MAC( CRED_R, G_X, G_Y ) ) )     |
+   |<------------------------------------------------------------------+
+   |                                                                   |
+   |        AEAD( ID_CRED_I, Sig( I; MAC( CRED_I, G_Y, G_X ) ) )       |
+   +------------------------------------------------------------------>|
+   |                                                                   |
+
+      Figure 1: MAC-then-Sign Variant of the SIGMA-I Protocol Used by
+                             the EDHOC Method 0
+
+   The parties exchanging messages in an EDHOC session are called the
+   Initiator (I) and the Responder (R), where the Initiator sends
+   message_1 (see Section 3).  They exchange ephemeral public keys,
+   compute a shared secret session key PRK_out, and derive symmetric
+   application keys used to protect application data.
+
+   *  G_X and G_Y are the Elliptic Curve Diffie-Hellman (ECDH) ephemeral
+      public keys of I and R, respectively.
+
+   *  CRED_I and CRED_R are the authentication credentials containing
+      the public authentication keys of I and R, respectively.
+
+   *  ID_CRED_I and ID_CRED_R are used to identify and optionally
+      transport the credentials of I and R, respectively.
+
+   *  Sig(I; . ) and Sig(R; . ) denote signatures made with the private
+      authentication key of I and R, respectively.
+
+   *  Enc(), AEAD(), and MAC() denote encryption, 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.
+
+   In order to create a "full-fledged" protocol, some additional
+   protocol elements are needed.  This specification adds:
+
+   *  transcript hashes (hashes of message data), TH_2, TH_3, and TH_4,
+      used for key derivation and as additional authenticated data,
+
+   *  computationally independent keys derived from the ECDH shared
+      secret and used for authenticated encryption of different
+      messages,
+
+   *  an optional fourth message giving key confirmation to I in
+      deployments where no protected application data is sent from R to
+      I,
+
+   *  a keying material exporter and a key update function with forward
+      secrecy,
+
+   *  secure negotiation of the cipher suite,
+
+   *  method types, error handling, and padding,
+
+   *  the selection of connection identifiers, C_I and C_R, which may be
+      used in EDHOC to identify the protocol state, and
+
+   *  transport of external authorization data.
+
+   EDHOC is designed to encrypt and integrity protect as much
+   information as possible.  Symmetric keys and random material used in
+   EDHOC are derived using EDHOC_KDF with as much previous information
+   as possible; see Figure 6.  EDHOC is furthermore designed to be as
+   compact and lightweight as possible, in terms of message sizes,
+   processing, and the ability to reuse already existing CBOR, COSE, and
+   CoAP libraries.  Like in (D)TLS, authentication is the responsibility
+   of the application.  EDHOC identifies (and optionally transports)
+   authentication credentials and provides proof-of-possession of the
+   private authentication key.
+
+   To simplify for implementors, the use of CBOR, CDDL, and COSE in
+   EDHOC is summarized in Appendix C.  Test vectors, including CBOR
+   diagnostic notation, are provided in [RFC9529].
+
+3.  Protocol Elements
+
+3.1.  General
+
+   The EDHOC protocol consists of three mandatory messages (message_1,
+   message_2, and message_3), an optional fourth message (message_4),
+   and an error message, between an Initiator (I) and a Responder (R).
+   The odd messages are sent by I, the even by R.  Both I and R can send
+   error messages.  The roles have slightly different security
+   properties that should be considered when the roles are assigned; see
+   Section 9.1.  All EDHOC messages are CBOR Sequences [RFC8742] and are
+   defined to be deterministically encoded CBOR as specified in
+   Section 4.2.1 of [RFC8949].  Figure 2 illustrates an EDHOC message
+   flow with the optional fourth message as well as the content of each
+   message.  The protocol elements in the figure are introduced in
+   Sections 3 and 5.  Message formatting and processing are specified in
+   Sections 5 and 6.
+
+   Application data may be protected using the agreed application
+   algorithms (AEAD, hash) in the selected cipher suite (see
+   Section 3.6), and the application can make use of the established
+   connection identifiers C_I and C_R (see Section 3.3).  Media types
+   that may be used for EDHOC are defined in Section 10.8.
+
+   The Initiator can derive symmetric application keys after creating
+   EDHOC message_3; see Section 4.2.1.  Protected application data can
+   therefore be sent in parallel or together with EDHOC message_3.
+   EDHOC message_4 is typically not sent.
+
+   Initiator                                                   Responder
+   |                 METHOD, SUITES_I, G_X, C_I, EAD_1                 |
+   +------------------------------------------------------------------>|
+   |                             message_1                             |
+   |                                                                   |
+   |       G_Y, Enc( C_R, ID_CRED_R, Signature_or_MAC_2, EAD_2 )       |
+   |<------------------------------------------------------------------+
+   |                             message_2                             |
+   |                                                                   |
+   |            AEAD( ID_CRED_I, Signature_or_MAC_3, EAD_3 )           |
+   +------------------------------------------------------------------>|
+   |                             message_3                             |
+   |                                                                   |
+   |                           AEAD( EAD_4 )                           |
+   |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
+   |                             message_4                             |
+
+     Figure 2: EDHOC Message Flow Including the Optional Fourth Message
+
+3.2.  Method
+
+   The data item METHOD in message_1 (see Section 5.2.1) is an integer
+   specifying the authentication method.  EDHOC currently supports
+   authentication with signature or static Diffie-Hellman keys, as
+   defined in the four authentication methods: 0, 1, 2, and 3; see
+   Table 2.  When using a static Diffie-Hellman key, the authentication
+   is provided by a Message Authentication Code (MAC) computed from an
+   ephemeral-static ECDH shared secret that enables significant
+   reductions in message sizes.  Note that, also in the static Diffie-
+   Hellman-based authentication methods, there is an ephemeral-ephemeral
+   Diffie-Hellman key exchange.
+
+   The Initiator and Responder need to have agreed on a single method to
+   be used for EDHOC; see Section 3.9.
+
+      +===================+====================+====================+
+      | Method Type Value | Initiator          | Responder          |
+      |                   | Authentication Key | Authentication Key |
+      +===================+====================+====================+
+      |                 0 | Signature Key      | Signature Key      |
+      +-------------------+--------------------+--------------------+
+      |                 1 | Signature Key      | Static DH Key      |
+      +-------------------+--------------------+--------------------+
+      |                 2 | Static DH Key      | Signature Key      |
+      +-------------------+--------------------+--------------------+
+      |                 3 | Static DH Key      | Static DH Key      |
+      +-------------------+--------------------+--------------------+
+      |                23 | Reserved           | Reserved           |
+      +-------------------+--------------------+--------------------+
+
+               Table 2: Authentication Keys for Method Types
+
+   EDHOC does not have a dedicated message field to indicate the
+   protocol version.  Breaking changes to EDHOC can be introduced by
+   specifying and registering new methods.
+
+3.3.  Connection Identifiers
+
+   EDHOC includes the selection of connection identifiers (C_I and C_R)
+   identifying a connection for which keys are agreed.
+
+   Connection identifiers may be used to correlate EDHOC messages and
+   facilitate the retrieval of protocol state during an EDHOC session
+   (see Section 3.4) or may be used in applications of EDHOC, e.g., in
+   OSCORE (see Section 3.3.3).  The connection identifiers do not have
+   any cryptographic purpose in EDHOC and only facilitate the retrieval
+   of security data associated with the protocol state.
+
+   Connection identifiers in EDHOC are intrinsically byte strings.  Most
+   constrained devices only have a few connections for which short
+   identifiers may be sufficient.  In some cases, minimum length
+   identifiers are necessary to comply with overhead requirements.
+   However, CBOR byte strings -- with the exception of the empty byte
+   string h'', which encodes as one byte (0x40) -- are encoded as two or
+   more bytes.  To enable one-byte encoding of certain byte strings
+   while maintaining CBOR encoding, EDHOC represents certain identifiers
+   as CBOR integers on the wire; see Section 3.3.2.
+
+3.3.1.  Selection of Connection Identifiers
+
+   C_I and C_R are chosen by I and R, respectively.  The Initiator
+   selects C_I and sends it in message_1 for the Responder to use as a
+   reference to the connection in communications with the Initiator.
+   The Responder selects C_R and sends it in message_2 for the Initiator
+   to use as a reference to the connection in communications with the
+   Responder.
+
+   If connection identifiers are used by an application protocol for
+   which EDHOC establishes keys, then the selected connection
+   identifiers SHALL adhere to the requirements for that protocol; see
+   Section 3.3.3 for an example.
+
+3.3.2.  Representation of Byte String Identifiers
+
+   To allow identifiers with minimal overhead on the wire, certain byte
+   strings used in connection identifiers and credential identifiers
+   (see Section 3.5.3) are defined to have integer representations.
+
+   The integers with one-byte CBOR encoding are -24, ..., 23; see
+   Figure 3.
+
+   Integer:  -24  -23  ... -11  ...  -2   -1    0    1  ...  15  ...  23
+   Encoding:  37   36  ...  2A  ...  21   20   00   01  ...  0F  ...  17
+
+                  Figure 3: One-Byte CBOR-Encoded Integers
+
+   The byte strings that coincide with a one-byte CBOR encoding of an
+   integer MUST be represented by the CBOR encoding of that integer.
+   Other byte strings are simply encoded as CBOR byte strings.
+
+   For example:
+
+   *  0x21 is represented by 0x21 (CBOR encoding of the integer -2), not
+      by 0x4121 (CBOR encoding of the byte string 0x21).
+
+   *  0x0D is represented by 0x0D (CBOR encoding of the integer 13), not
+      by 0x410D (CBOR encoding of the byte string 0x0D).
+
+   *  0x18 is represented by 0x4118 (CBOR encoding of the byte string
+      0x18).
+
+   *  0x38 is represented by 0x4138 (CBOR encoding of the byte string
+      0x38).
+
+   *  0xABCD is represented by 0x42ABCD (CBOR encoding of the byte
+      string 0xABCD).
+
+   One may view this representation of byte strings as a transport
+   encoding, i.e., a byte string that parses as the one-byte CBOR
+   encoding of an integer (i.e., integer in the interval -24, ..., 23)
+   is just copied directly into the message, and a byte string that does
+   not is encoded as a CBOR byte string during transport.
+
+      |  Implementation Note: When implementing the byte string
+      |  identifier representation, in some programming languages, it
+      |  can help to define a new type or other data structure, which
+      |  (in its user-facing API) behaves like a byte string but when
+      |  serializing to CBOR produces a CBOR byte string or a CBOR
+      |  integer depending on its value.
+
+3.3.3.  Use of Connection Identifiers with OSCORE
+
+   For OSCORE, the choice of connection identifier results in the
+   endpoint selecting its Recipient ID (see Section 3.1 of [RFC8613])
+   for which certain uniqueness requirements apply (see Section 3.3 of
+   [RFC8613]).  Therefore, the Initiator and Responder MUST NOT select
+   connection identifiers such that it results in the same OSCORE
+   Recipient ID.  Since the connection identifier is a byte string, it
+   is converted to an OSCORE Recipient ID equal to the byte string.
+
+   Examples:
+
+   *  A connection identifier 0xFF (represented in the EDHOC message as
+      0x41FF; see Section 3.3.2) is converted to the OSCORE Recipient ID
+      0xFF.
+
+   *  A connection identifier 0x21 (represented in the EDHOC message as
+      0x21; see Section 3.3.2) is converted to the OSCORE Recipient ID
+      0x21.
+
+3.4.  Transport
+
+   Cryptographically, EDHOC does not put requirements on the underlying
+   layers.  Received messages are processed as the expected next message
+   according to the protocol state; see Section 5.  If processing fails
+   for any reason, then typically an error message is attempted to be
+   sent and the EDHOC session is aborted.
+
+   EDHOC is not bound to a particular transport layer and can even be
+   used in environments without IP.  Ultimately, the application is free
+   to choose how to transport EDHOC messages including errors.  In order
+   to avoid unnecessary message processing or protocol termination, it
+   is RECOMMENDED to use reliable transport, such as CoAP in reliable
+   mode, which is the default transport; see Appendix A.2.  In general,
+   the transport SHOULD handle:
+
+   *  message loss,
+
+   *  message duplication (see Section 7 for an alternative),
+
+   *  flow control,
+
+   *  congestion control,
+
+   *  fragmentation and reassembly,
+
+   *  demultiplexing EDHOC messages from other types of messages,
+
+   *  denial-of-service mitigation, and
+
+   *  message correlation (see Section 3.4.1).
+
+   EDHOC does not require error-free transport since a change in message
+   content is detected through the transcript hashes in a subsequent
+   integrity verification; see Section 5.  The transport does not
+   require additional means to handle message reordering because of the
+   lockstep processing of EDHOC.
+
+   EDHOC is designed to enable an authenticated key exchange with small
+   messages, where the minimum message sizes are of the order
+   illustrated in the first column of Table 1.  There is no maximum
+   message size specified by the protocol; for example, this is
+   dependent on the size of the authentication credentials (if they are
+   transported, see Section 3.5).  The encryption of very large content
+   in message_2 when using certain hash algorithms is described in
+   Appendix G.
+
+   The use of transport is specified in the application profile, which
+   in particular, may specify limitations in message sizes; see
+   Section 3.9.
+
+3.4.1.  EDHOC Message Correlation
+
+   Correlation between EDHOC messages is needed to facilitate the
+   retrieval of the protocol state and security context during an EDHOC
+   session.  It is also helpful for the Responder to get an indication
+   that a received EDHOC message is the beginning of a new EDHOC
+   session, such that no existing protocol state or security context
+   needs to be retrieved.
+
+   Correlation may be based on existing mechanisms in the transport
+   protocol; for example, the CoAP Token may be used to correlate EDHOC
+   messages in a CoAP response and in an associated CoAP request.  The
+   connection identifiers may also be used to correlate EDHOC messages.
+
+   If correlation between consecutive messages is not provided by other
+   means, then the transport binding SHOULD mandate prepending of an
+   appropriate connection identifier (when available from the EDHOC
+   protocol) to the EDHOC message.  If message_1 indication is not
+   provided by other means, then the transport binding SHOULD mandate
+   prepending of message_1 with the CBOR simple value true (0xf5).
+
+   Transport of EDHOC in CoAP payloads is described in Appendix A.2,
+   including how to use connection identifiers and message_1 indication
+   with CoAP.  A similar construction is possible for other client-
+   server protocols.  Protocols that do not provide any correlation at
+   all can prescribe prepending of the peer's connection identifier to
+   all messages.
+
+   Note that correlation between EDHOC messages may be obtained without
+   transport support or connection identifiers, for example, if the
+   endpoints only accept a single instance of the protocol at a time and
+   execute conditionally on a correct sequence of messages.
+
+3.5.  Authentication Parameters
+
+   EDHOC supports various settings for how the other endpoint's public
+   key for authentication may be transported, identified, and trusted.
+   We shall use the term "authentication key" to mean key used for
+   authentication in general, or specifically, the public key, when
+   there is no risk for confusion.
+
+   EDHOC performs the following authentication-related operations:
+
+   *  EDHOC transports information about credentials in ID_CRED_I and
+      ID_CRED_R (described in Section 3.5.3).  Based on this
+      information, the authentication credentials CRED_I and CRED_R
+      (described in Section 3.5.2) can be obtained.  EDHOC may also
+      transport certain authentication-related information as external
+      authorization data (see Section 3.8).
+
+   *  EDHOC uses the authentication credentials in two ways (see
+      Sections 5.3.2 and 5.4.2):
+
+      -  The authentication credential is input to the integrity
+         verification using the MAC fields.
+
+      -  The authentication key of the authentication credential is used
+         with the Signature_or_MAC field to verify proof-of-possession
+         of the private key.
+
+   Other authentication-related verifications are out of scope for EDHOC
+   and are the responsibility of the application.  In particular, the
+   authentication credential needs to be validated in the context of the
+   connection for which EDHOC is used; see Appendix D.  EDHOC MUST allow
+   the application to read received information about credentials in
+   ID_CRED_R and ID_CRED_I.  EDHOC MUST have access to the
+   authentication key and the authentication credential.
+
+   Note that the type of authentication key, the type of authentication
+   credential, and the identification of the credential have a large
+   impact on the message size.  For example, the Signature_or_MAC field
+   is much smaller with a static DH key than with a signature key.  A
+   CWT Claims Set (CCS) is much smaller than a self-signed certificate /
+   CWT, but if it is possible to reference the credential with a COSE
+   header like 'kid', then that is in turn much smaller than a CCS.
+
+3.5.1.  Authentication Keys
+
+   The authentication key MUST be a signature key or a static Diffie-
+   Hellman key.  The Initiator and Responder MAY use different types of
+   authentication keys, e.g., one uses a signature key and the other
+   uses a static Diffie-Hellman key.
+
+   The authentication key algorithm needs to be compatible with the
+   method and the selected cipher suite (see Section 3.6).  The
+   authentication key algorithm needs to be compatible with the EDHOC
+   key exchange algorithm when static Diffie-Hellman authentication is
+   used and compatible with the EDHOC signature algorithm when signature
+   authentication is used.
+
+   Note that for most signature algorithms, the signature is determined
+   jointly by the signature algorithm and the authentication key
+   algorithm.  When using static Diffie-Hellman keys, the Initiator's
+   and the Responder's private authentication keys are denoted as I and
+   R, respectively, and the public authentication keys are denoted G_I
+   and G_R, respectively.
+
+   For X.509 certificates, the authentication key is represented by a
+   SubjectPublicKeyInfo field, which also contains information about
+   authentication key algorithm.  For CWT and CCS (see Section 3.5.2),
+   the authentication key is represented by a 'cnf' claim [RFC8747]
+   containing a COSE_Key [RFC9052], which contains information about
+   authentication key algorithm.  In EDHOC, a raw public key (RPK) is an
+   authentication key encoded as a COSE_Key wrapped in a CCS, an example
+   is given in Figure 4.
+
+3.5.2.  Authentication Credentials
+
+   The authentication credentials, CRED_I and CRED_R, contain the public
+   authentication key of the Initiator and Responder, respectively.  We
+   use the notation CRED_x to refer to CRED_I or CRED_R.  Requirements
+   on CRED_x applies both to CRED_I and to CRED_R.  The authentication
+   credential typically also contains other parameters that needs to be
+   verified by the application (see Appendix D) and in particular
+   information about the identity ("subject") of the endpoint to prevent
+   misbinding attacks (see Appendix D.2).
+
+   EDHOC relies on COSE for identification of credentials (see
+   Section 3.5.3), for example, X.509 certificates [RFC9360], C509
+   certificates [C509-CERTS], CWTs [RFC8392], and CCSs [RFC8392].  When
+   the identified credential is a chain or a bag, the authentication
+   credential CRED_x is just the end entity X.509 or C509 certificate /
+   CWT.  In the choice between a chain or a bag, it is RECOMMENDED to
+   use a chain, since the certificates in a bag are unordered and may
+   contain self-signed and extraneous certificates, which can add
+   complexity to the process of extracting the end entity certificate.
+   The Initiator and Responder MAY use different types of authentication
+   credentials, e.g., one uses an RPK and the other uses a public key
+   certificate.
+
+   Since CRED_R is used in the integrity verification (see
+   Section 5.3.2), it needs to be specified such that it is identical
+   when used by the Initiator or Responder.  Similarly for CRED_I, see
+   Section 5.4.2.  The Initiator and Responder are expected to agree on
+   the specific encoding of the authentication credentials; see
+   Section 3.9.  It is RECOMMENDED that the COSE 'kid' parameter, when
+   used to identify the authentication credential, refers to such a
+   specific encoding of the authentication credential.  The Initiator
+   and Responder SHOULD use an available authentication credential
+   without re-encoding, i.e. an authentication credential transported in
+   EDHOC by value, or otherwise provisioned, SHOULD be used as is.  If
+   for some reason re-encoding of an authentication credential passed by
+   reference may occur, then a potential common encoding for CBOR-based
+   credentials is deterministically encoded CBOR, as specified in
+   Sections 4.2.1 and 4.2.2 of [RFC8949].
+
+   *  When the authentication credential is an X.509 certificate, CRED_x
+      SHALL be the DER-encoded certificate, encoded as a bstr [RFC9360].
+
+   *  When the authentication credential is a C509 certificate, CRED_x
+      SHALL be the C509 certificate [C509-CERTS].
+
+   *  When the authentication credential is a CWT including a COSE_Key,
+      CRED_x SHALL be the untagged CWT.
+
+   *  When the authentication credential includes a COSE_Key but is not
+      in a CWT, CRED_x SHALL be an untagged CCS.  This is how RPKs are
+      encoded, see Figure 4 for an example.
+
+      -  Naked COSE_Keys are thus dressed as CCS when used in EDHOC, in
+         its simplest form by prefixing the COSE_Key with 0xA108A101 (a
+         map with a 'cnf' claim).  In that case, the resulting
+         authentication credential contains no other identity than the
+         public key itself; see Appendix D.2.
+
+   An example of CRED_x is shown below:
+
+   {                                              /CCS/
+     2 : "42-50-31-FF-EF-37-32-39",               /sub/
+     8 : {                                        /cnf/
+       1 : {                                      /COSE_Key/
+         1 : 1,                                   /kty/
+         2 : h'00',                               /kid/
+        -1 : 4,                                   /crv/
+        -2 : h'b1a3e89460e88d3a8d54211dc95f0b90   /x/
+               3ff205eb71912d6db8f4af980d2db83a'
+       }
+     }
+   }
+
+      Figure 4: CCS Containing an X25519 Static Diffie-Hellman Key and
+                             an EUI-64 Identity
+
+3.5.3.  Identification of Credentials
+
+   The ID_CRED fields, ID_CRED_R and ID_CRED_I, are transported in
+   message_2 and message_3, respectively; see Sections 5.3.2 and 5.4.2.
+   We use the notation ID_CRED_x to refer to ID_CRED_I or ID_CRED_R.
+   Requirements on ID_CRED_x applies both to ID_CRED_I and to ID_CRED_R.
+   The ID_CRED fields are used to identify and optionally transport
+   credentials:
+
+   *  ID_CRED_R is intended to facilitate for the Initiator retrieving
+      the authentication credential CRED_R and the authentication key of
+      R.
+
+   *  ID_CRED_I is intended to facilitate for the Responder retrieving
+      the authentication credential CRED_I and the authentication key of
+      I.
+
+   ID_CRED_x may contain the authentication credential CRED_x, for x = I
+   or R, but for many settings, it is not necessary to transport the
+   authentication credential within EDHOC.  For example, it may be pre-
+   provisioned or acquired out-of-band over less constrained links.
+   ID_CRED_I and ID_CRED_R do not have any cryptographic purpose in
+   EDHOC since the authentication credentials are integrity protected by
+   the Signature_or_MAC field.
+
+   EDHOC relies on COSE for identification of credentials and supports
+   all credential types for which COSE header parameters are defined,
+   including X.509 certificates [RFC9360], C509 certificates
+   [C509-CERTS], CWTs (Section 3.5.3.1) and CCSs (Section 3.5.3.1).
+
+   ID_CRED_I and ID_CRED_R are of type COSE header_map, as defined in
+   Section 3 of [RFC9052], and contain one or more COSE header
+   parameters.  If a map contains several header parameters, the labels
+   do not need to be sorted in bytewise lexicographic order.  ID_CRED_I
+   and ID_CRED_R MAY contain different header parameters.  The header
+   parameters typically provide some information about the format of the
+   credential.
+
+   Example: X.509 certificates can be identified by a hash value using
+   the 'x5t' parameter; see Section 2 of [RFC9360]:
+
+   *  ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R
+
+   Example: CWT or CCS can be identified by a key identifier using the
+   'kid' parameter; see Section 3.1 of [RFC9052]:
+
+   *  ID_CRED_x = { 4 : kid_x }, where kid_x : kid, for x = I or R
+
+   Note that COSE header parameters in ID_CRED_x are used to identify
+   the message sender's credential.  Therefore, there is no reason to
+   use the "-sender" header parameters, such as x5t-sender, defined in
+   Section 3 of [RFC9360].  Instead, the corresponding parameter without
+   "-sender", such as x5t, SHOULD be used.
+
+   As stated in Section 3.1 of [RFC9052], applications MUST NOT assume
+   that 'kid' values are unique and several keys associated with a 'kid'
+   may need to be checked before the correct one is found.  Applications
+   might use additional information such as 'kid context' or lower
+   layers to determine which key to try first.  Applications should
+   strive to make ID_CRED_x as unique as possible, since the recipient
+   may otherwise have to try several keys.
+
+   See Appendix C.3 for more examples.
+
+3.5.3.1.  COSE Header Parameters for CWT and CWT Claims Set
+
+   This document registers two new COSE header parameters, 'kcwt' and
+   'kccs', for use with CBOR Web Token (CWT) [RFC8392] and CWT Claims
+   Set (CCS) [RFC8392], respectively.  The CWT/CCS MUST contain a
+   COSE_Key in a 'cnf' claim [RFC8747].  There may be any number of
+   additional claims present in the CWT/CCS.
+
+   CWTs sent in 'kcwt' are protected using a MAC or a signature and are
+   similar to a certificate (when used with public key cryptography) or
+   a Kerberos ticket (when used with symmetric key cryptography).  CCSs
+   sent in 'kccs' are not protected and are therefore similar to raw
+   public keys or self-signed certificates.
+
+   Security considerations for 'kcwt' and 'kccs' are made in
+   Section 9.8.
+
+3.5.3.2.  Compact Encoding of ID_CRED Fields for 'kid'
+
+   To comply with the Lightweight Authenticated Key Exchange (LAKE)
+   message size requirements (see [LAKE-REQS]), two optimizations are
+   made for the case when ID_CRED_x, for x = I or R, contains a single
+   'kid' parameter.
+
+   1.  The CBOR map { 4 : kid_x } is replaced by the byte string kid_x.
+
+   2.  The representation of identifiers specified in Section 3.3.2 is
+       applied to kid_x.
+
+   These optimizations MUST be applied if and only if ID_CRED_x = { 4 :
+   kid_x } and ID_CRED_x in PLAINTEXT_y of message_y, y = 2 or 3; see
+   Sections 5.3.2 and 5.4.2.  Note that these optimizations are not
+   applied to instances of ID_CRED_x that have no impact on message
+   size, e.g., context_y, or the COSE protected header.  For example:
+
+   *  For ID_CRED_x = { 4 : h'FF' }, the encoding in PLAINTEXT_y is not
+      the CBOR map 0xA10441FF but the CBOR byte string h'FF', i.e.,
+      0x41FF.
+
+   *  For ID_CRED_x = { 4 : h'21' }, the encoding in PLAINTEXT_y is
+      neither the CBOR map 0xA1044121 nor the CBOR byte string h'21',
+      i.e., 0x4121, but the CBOR integer 0x21.
+
+3.6.  Cipher Suites
+
+   An EDHOC cipher suite consists of an ordered set of algorithms from
+   the "COSE Algorithms" and "COSE Elliptic Curves" registries as well
+   as the EDHOC MAC length.  All algorithm names and definitions follow
+   COSE Algorithms [RFC9053].  Note that COSE sometimes uses peculiar
+   names such as ES256 for Elliptic Curve Digital Signature Algorithm
+   (ECDSA) with SHA-256, A128 for AES-128, and Ed25519 for the curve
+   edwards25519.  Algorithms need to be specified with enough parameters
+   to make them completely determined.  The EDHOC MAC length MUST be at
+   least 8 bytes.  Any cryptographic algorithm used in the COSE header
+   parameters in ID_CRED fields is selected independently of the
+   selected cipher suite.  EDHOC is currently only specified for use
+   with key exchange algorithms of type ECDH curves, but any Key
+   Encapsulation Mechanism (KEM), including Post-Quantum Cryptography
+   (PQC) KEMs, can be used in method 0; see Section 9.4.  Use of other
+   types of key exchange algorithms to replace static DH authentication
+   (methods 1, 2, and 3) would likely require a specification updating
+   EDHOC with new methods.
+
+   EDHOC supports all signature algorithms defined by COSE.  Just like
+   in (D)TLS 1.3 [RFC8446] [RFC9147] and IKEv2 [RFC7296], a signature in
+   COSE is determined jointly by the signature algorithm and the
+   authentication key algorithm; see Section 3.5.1.  The exact details
+   of the authentication key algorithm depend on the type of
+   authentication credential.  COSE supports different formats for
+   storing the public authentication keys including COSE_Key and X.509,
+   which use different names and ways to represent the authentication
+   key and the authentication key algorithm.
+
+   An EDHOC cipher suite consists of the following parameters:
+
+   *  EDHOC AEAD algorithm,
+
+   *  EDHOC hash algorithm,
+
+   *  EDHOC MAC length in bytes (Static DH),
+
+   *  EDHOC key exchange algorithm (ECDH curve),
+
+   *  EDHOC signature algorithm,
+
+   *  application AEAD algorithm, and
+
+   *  application hash algorithm.
+
+   Each cipher suite is identified with a predefined integer label.
+
+   EDHOC can be used with all algorithms and curves defined for COSE.
+   Implementations can either use any combination of COSE algorithms and
+   parameters to define their own private cipher suite or use one of the
+   predefined cipher suites.  Private cipher suites can be identified
+   with any of the four values: -24, -23, -22, and -21.  The predefined
+   cipher suites are listed in the IANA registry (Section 10.2) with the
+   initial content outlined here:
+
+   *  Cipher suites 0-3, based on AES-CCM, are intended for constrained
+      IoT where message overhead is a very important factor.  Note that
+      AES-CCM-16-64-128 and AES-CCM-16-128-128 are compatible with the
+      IEEE AES-CCM* mode of operation defined in Annex B of
+      [IEEE.802.15.4-2015].
+
+      -  Cipher suites 1 and 3 use a larger tag length (128 bits) in
+         EDHOC than in the application AEAD algorithm (64 bits).
+
+   *  Cipher suites 4 and 5, based on ChaCha20, are intended for less
+      constrained applications and only use 128-bit tag lengths.
+
+   *  Cipher suite 6, based on AES-GCM, is for general non-constrained
+      applications.  It consists of high-performance algorithms that are
+      widely used in non-constrained applications.
+
+   *  Cipher suites 24 and 25 are intended for high security
+      applications such as government use and financial applications.
+      These cipher suites do not share any algorithms.  Cipher suite 24
+      consists of algorithms from the Commercial National Security
+      Algorithm (CNSA) 1.0 suite [CNSA].
+
+   The different methods (Section 3.2) use the same cipher suites, but
+   some algorithms are not used in some methods.  The EDHOC signature
+   algorithm is not used in methods without signature authentication.
+
+   The Initiator needs to have a list of cipher suites it supports in
+   order of preference.  The Responder needs to have a list of cipher
+   suites it supports.  SUITES_I contains cipher suites supported by the
+   Initiator and formatted and processed as detailed in Section 5.2.1 to
+   secure the cipher suite negotiation.  Examples of cipher suite
+   negotiation are given in Section 6.3.2.
+
+3.7.  Ephemeral Public Keys
+
+   The ephemeral public keys in EDHOC (G_X and G_Y) use compact
+   representation of elliptic curve points; see Appendix B.  In COSE,
+   compact representation is achieved by formatting the ECDH ephemeral
+   public keys as COSE_Keys of type EC2 or Octet Key Pair (OKP)
+   according to Sections 7.1 and 7.2 of [RFC9053] but only including the
+   'x' parameter in G_X and G_Y.  For Elliptic Curve Keys of type EC2,
+   compact representation MAY be used also in the COSE_Key.  COSE always
+   uses compact output for Elliptic Curve Keys of type EC2.  If the COSE
+   implementation requires a 'y' parameter, the value y = false or a
+   calculated y-coordinate can be used; see Appendix B.
+
+3.8.  External Authorization Data (EAD)
+
+   In order to reduce round trips and the number of messages or to
+   simplify processing, external security applications may be integrated
+   into EDHOC by transporting authorization-related data in the
+   messages.
+
+   EDHOC allows processing of external authorization data (EAD) to be
+   defined in a separate specification and sent in dedicated fields of
+   the four EDHOC messages: EAD_1, EAD_2, EAD_3, and EAD_4.  EAD is
+   opaque data to EDHOC.
+
+   Each EAD field, EAD_x, for x = 1, 2, 3, or 4, is a CBOR sequence (see
+   Appendix C.1) consisting of one or more EAD items.  EAD item ead is a
+   CBOR sequence of an ead_label and an optional ead_value; see Figure 5
+   and Appendix C.2 for the CDDL definitions.
+
+   ead = (
+     ead_label : int,
+     ? ead_value : bstr,
+   )
+
+                             Figure 5: EAD Item
+
+   A security application may register one or more EAD labels (see
+   Section 10.5) and specify the associated processing and security
+   considerations.  The IANA registry contains the absolute value of the
+   ead_label, |ead_label|; the same ead_value applies independently of
+   the sign of the ead_label.
+
+   An EAD item can be either critical or non-critical, determined by the
+   sign of the ead_label in the EAD item transported in the EAD field.
+   A negative value indicates that the EAD item is critical, and a
+   nonnegative value indicates that the EAD item is non-critical.
+
+   If an endpoint receives a critical EAD item it does not recognize or
+   a critical EAD item that contains information that it cannot process,
+   then the endpoint MUST send an EDHOC error message back as defined in
+   Section 6, and the EDHOC session MUST be aborted.  The EAD item
+   specification defines the error processing.  A non-critical EAD item
+   can be ignored.
+
+   The security application registering a new EAD item needs to describe
+   under what conditions the EAD item is critical or non-critical, and
+   thus whether the ead_label is used with a negative or positive sign.
+   ead_label = 0 is used for padding; see Section 3.8.1.
+
+   The security application may define multiple uses of certain EAD
+   items, e.g., the same EAD item may be used in different EDHOC
+   messages.  Multiple occurrences of an EAD item in one EAD field may
+   also be specified, but the criticality of the repeated EAD item is
+   expected to be the same.
+
+   The EAD fields of EDHOC MUST only be used with registered EAD items;
+   see Section 10.5.  Examples of the use of EAD are provided in
+   Appendix E.
+
+3.8.1.  Padding
+
+   EDHOC message_1 and the plaintext of message_2, message_3, and
+   message_4 can be padded with the use of the corresponding EAD_x
+   field, for x = 1, 2, 3, or 4.  Padding in EAD_1 mitigates
+   amplification attacks (see Section 9.7), and padding in EAD_2, EAD_3,
+   and EAD_4 hides the true length of the plaintext (see Section 9.6).
+   Padding MUST be ignored and discarded by the receiving application.
+
+   Padding is obtained by using an EAD item with ead_label = 0 and a
+   (pseudo)randomly generated byte string of appropriate length as
+   ead_value, noting that the ead_label and the CBOR encoding of
+   ead_value also add bytes.  For example:
+
+   *  One-byte padding (optional ead_value omitted):
+
+      EAD_x = 0x00
+
+   *  Two-byte padding, using the empty byte string (0x40) as ead_value:
+
+      EAD_x = 0x0040
+
+   *  Three-byte padding, constructed from the pseudorandomly generated
+      ead_value 0xe9 encoded as byte string:
+
+      EAD_x = 0x0041e9
+
+   Multiple occurrences of EAD items with ead_label = 0 are allowed.
+   Certain padding lengths require the use of at least two such EAD
+   items.
+
+   Note that padding is non-critical because the intended behavior when
+   receiving is to ignore it.
+
+3.9.  Application Profile
+
+   EDHOC requires certain parameters to be agreed upon between the
+   Initiator and Responder.  Some parameters can be negotiated through
+   the protocol execution (specifically, cipher suite; see Section 3.6),
+   but other parameters are only communicated and may not be negotiated
+   (e.g., which authentication method is used; see Section 3.2).  Yet,
+   other parameters need to be known out-of-band to ensure successful
+   completion, e.g., whether message_4 is used or not.  The application
+   decides which endpoint is the Initiator and which is the Responder.
+
+   The purpose of an application profile is to describe the intended use
+   of EDHOC to allow for the relevant processing and verifications to be
+   made, including things like the following:
+
+   1.  How the endpoint detects that an EDHOC message is received.  This
+       includes how EDHOC messages are transported, for example, in the
+       payload of a CoAP message with a certain Uri-Path or Content-
+       Format; see Appendix A.2.
+
+       The method of transporting EDHOC messages may also describe data
+       carried along with the messages that are needed for the transport
+       to satisfy the requirements of Section 3.4, e.g., connection
+       identifiers used with certain messages; see Appendix A.2.
+
+   2.  Authentication method (METHOD; see Section 3.2).
+
+   3.  Profile for authentication credentials (CRED_I and CRED_R; see
+       Section 3.5.2), e.g., profile for certificate or CCS, including
+       supported authentication key algorithms (subject public key
+       algorithm in X.509 or C509 certificate).
+
+   4.  Type used to identify credentials (ID_CRED_I and ID_CRED_R; see
+       Section 3.5.3).
+
+   5.  Use and type of external authorization data (EAD_1, EAD_2, EAD_3,
+       and EAD_4; see Section 3.8).
+
+   6.  Identifier used as the identity of the endpoint; see
+       Appendix D.2.
+
+   7.  If message_4 shall be sent/expected, and if not, how to ensure a
+       protected application message is sent from the Responder to the
+       Initiator; see Section 5.5.
+
+   The application profile may also contain information about supported
+   cipher suites.  The procedure for selecting and verifying a cipher
+   suite is still performed as described in Sections 5.2.1 and 6.3, but
+   it may become simplified by this knowledge.  EDHOC messages can be
+   processed without the application profile, i.e., the EDHOC messages
+   include information about the type and length of all fields.
+
+   An example of an application profile is shown in Appendix F.
+
+   For some parameters, like METHOD, the type of the ID_CRED field, or
+   EAD, the receiver of an EDHOC message is able to verify compliance
+   with the application profile and, if it needs to fail because of the
+   lack of compliance, to infer the reason why the EDHOC session failed.
+
+   For other encodings, like the profiling of CRED_x in the case that it
+   is not transported, it may not be possible to verify that the lack of
+   compliance with the application profile was the reason for failure.
+   For example, integrity verification in message_2 or message_3 may
+   fail not only because of a wrong credential.  For example, in case
+   the Initiator uses a public key certificate by reference (i.e., not
+   transported within the protocol), then both endpoints need to use an
+   identical data structure as CRED_I or else the integrity verification
+   will fail.
+
+   Note that it is not necessary for the endpoints to specify a single
+   transport for the EDHOC messages.  For example, a mix of CoAP and
+   HTTP may be used along the path, and this may still allow correlation
+   between messages.
+
+   The application profile may be dependent on the identity of the other
+   endpoint or other information carried in an EDHOC message, but it
+   then applies only to the later phases of the protocol when such
+   information is known.  (The Initiator does not know the identity of
+   the Responder before having verified message_2, and the Responder
+   does not know the identity of the Initiator before having verified
+   message_3.)
+
+   Other conditions may be part of the application profile, such as what
+   is the target application or use (if there is more than one
+   application/use) to the extent that EDHOC can distinguish between
+   them.  In case multiple application profiles are used, the receiver
+   needs to be able to determine which is applicable for a given EDHOC
+   session, for example, based on the URI to which the EDHOC message is
+   sent, or external authorization data type.
+
+4.  Key Derivation
+
+4.1.  Keys for EDHOC Message Processing
+
+   EDHOC uses Extract-and-Expand [RFC5869] with the EDHOC hash algorithm
+   in the selected cipher suite to derive keys used in message
+   processing.  This section defines EDHOC_Extract (Section 4.1.1) and
+   EDHOC_Expand (Section 4.1.2) and how to use them to derive PRK_out
+   (Section 4.1.3), which is the shared secret session key resulting
+   from a completed EDHOC session.
+
+   EDHOC_Extract is used to derive fixed-length uniformly pseudorandom
+   keys (PRKs) from ECDH shared secrets.  EDHOC_Expand is used to define
+   EDHOC_KDF for generating MACs and for deriving output keying material
+   (OKM) from PRKs.
+
+   In EDHOC, a specific message is protected with a certain PRK, but how
+   the key is derived depends on the authentication method
+   (Section 3.2), as detailed in Section 5.
+
+4.1.1.  EDHOC_Extract
+
+   The pseudorandom keys (PRKs) used for EDHOC message processing are
+   derived using EDHOC_Extract:
+
+      PRK = EDHOC_Extract( salt, IKM )
+
+   where the input keying material (IKM) and salt are defined for each
+   PRK below.
+
+   The definition of EDHOC_Extract depends on the EDHOC hash algorithm
+   of the selected cipher suite:
+
+   *  If the EDHOC hash algorithm is SHA-2, then EDHOC_Extract( salt,
+      IKM ) = HKDF-Extract( salt, IKM ) [RFC5869].
+
+   *  If the EDHOC hash algorithm is SHAKE128, then EDHOC_Extract( salt,
+      IKM ) = KMAC128( salt, IKM, 256, "" ).
+
+   *  If the EDHOC hash algorithm is SHAKE256, then EDHOC_Extract( salt,
+      IKM ) = KMAC256( salt, IKM, 512, "" ).
+
+   where the Keccak Message Authentication Code (KMAC) is specified in
+   [SP800-185].
+
+   The rest of the section defines the pseudorandom keys PRK_2e,
+   PRK_3e2m, and PRK_4e3m; their use is shown in Figure 6.  The index of
+   a PRK indicates its use or in what message protection operation it is
+   involved.  For example, PRK_3e2m is involved in the encryption of
+   message 3 and in calculating the MAC of message 2.
+
+4.1.1.1.  PRK_2e
+
+   The pseudorandom key PRK_2e is derived with the following input:
+
+   *  The salt SHALL be TH_2.
+
+   *  The IKM SHALL be the ephemeral-ephemeral ECDH shared secret G_XY
+      (calculated from G_X and Y or G_Y and X) as defined in
+      Section 6.3.1 of [RFC9053].  The use of G_XY gives forward secrecy
+      in the sense that compromise of the private authentication keys
+      does not compromise past session keys.
+
+   Example: Assuming the use of curve25519, the ECDH shared secret G_XY
+   is the output of the X25519 function [RFC7748]:
+
+      G_XY = X25519( Y, G_X ) = X25519( X, G_Y )
+
+   Example: Assuming the use of SHA-256, the extract phase of the key
+   derivation function is HKDF-Extract, which produces PRK_2e as
+   follows:
+
+      PRK_2e = HMAC-SHA-256( TH_2, G_XY )
+
+4.1.1.2.  PRK_3e2m
+
+   The pseudorandom key PRK_3e2m is derived as follows:
+
+   If the Responder authenticates with a static Diffie-Hellman key, then
+   PRK_3e2m = EDHOC_Extract( SALT_3e2m, G_RX ), where
+
+   *  SALT_3e2m is derived from PRK_2e (see Section 4.1.2) and
+
+   *  G_RX is the ECDH shared secret calculated from G_R and X, or G_X
+      and R (the Responder's private authentication key; see
+      Section 3.5.1),
+
+   else PRK_3e2m = PRK_2e.
+
+4.1.1.3.  PRK_4e3m
+
+   The pseudorandom key PRK_4e3m is derived as follows:
+
+   If the Initiator authenticates with a static Diffie-Hellman key, then
+   PRK_4e3m = EDHOC_Extract( SALT_4e3m, G_IY ), where
+
+   *  SALT_4e3m is derived from PRK_3e2m (see Section 4.1.2) and
+
+   *  G_IY is the ECDH shared secret calculated from G_I and Y, or G_Y
+      and I (the Initiator's private authentication key; see
+      Section 3.5.1),
+
+   else PRK_4e3m = PRK_3e2m.
+
+4.1.2.  EDHOC_Expand and EDHOC_KDF
+
+   The output keying material (OKM) -- including keys, initialization
+   vectors (IVs), and salts -- are derived from the PRKs using the
+   EDHOC_KDF, which is defined through EDHOC_Expand:
+
+      OKM = EDHOC_KDF( PRK, info_label, context, length )
+          = EDHOC_Expand( PRK, info, length )
+
+   where info is encoded as the CBOR sequence:
+
+   info = (
+     info_label : int,
+     context : bstr,
+     length : uint,
+   )
+
+   where:
+
+   *  info_label is an int,
+
+   *  context is a bstr, and
+
+   *  length is the length of OKM in bytes.
+
+   When EDHOC_KDF is used to derive OKM for EDHOC message processing,
+   then the context includes one of the transcript hashes, TH_2, TH_3,
+   or TH_4, defined in Sections 5.3.2 and 5.4.2.
+
+   The definition of EDHOC_Expand depends on the EDHOC hash algorithm of
+   the selected cipher suite:
+
+   *  If the EDHOC hash algorithm is SHA-2, then EDHOC_Expand( PRK,
+      info, length ) = HKDF-Expand( PRK, info, length ) [RFC5869].
+
+   *  If the EDHOC hash algorithm is SHAKE128, then EDHOC_Expand( PRK,
+      info, length ) = KMAC128( PRK, info, L, "" ).
+
+   *  If the EDHOC hash algorithm is SHAKE256, then EDHOC_Expand( PRK,
+      info, length ) = KMAC256( PRK, info, L, "" ).
+
+   where L = 8 ⋅ length, the output length in bits.
+
+   Figure 6 lists derivations made with EDHOC_KDF, where:
+
+   *  hash_length is the length of output size of the EDHOC hash
+      algorithm of the selected cipher suite,
+
+   *  key_length is the length of the encryption key of the EDHOC AEAD
+      algorithm of the selected cipher suite, and
+
+   *  iv_length is the length of the initialization vector of the EDHOC
+      AEAD algorithm of the selected cipher suite
+
+   Further details of the key derivation and how the output keying
+   material is used are specified in Section 5.
+
+   KEYSTREAM_2   = EDHOC_KDF( PRK_2e,   0, TH_2,      plaintext_length )
+   SALT_3e2m     = EDHOC_KDF( PRK_2e,   1, TH_2,      hash_length )
+   MAC_2         = EDHOC_KDF( PRK_3e2m, 2, context_2, mac_length_2 )
+   K_3           = EDHOC_KDF( PRK_3e2m, 3, TH_3,      key_length )
+   IV_3          = EDHOC_KDF( PRK_3e2m, 4, TH_3,      iv_length )
+   SALT_4e3m     = EDHOC_KDF( PRK_3e2m, 5, TH_3,      hash_length )
+   MAC_3         = EDHOC_KDF( PRK_4e3m, 6, context_3, mac_length_3 )
+   PRK_out       = EDHOC_KDF( PRK_4e3m, 7, TH_4,      hash_length )
+   K_4           = EDHOC_KDF( PRK_4e3m, 8, TH_4,      key_length )
+   IV_4          = EDHOC_KDF( PRK_4e3m, 9, TH_4,      iv_length )
+   PRK_exporter  = EDHOC_KDF( PRK_out, 10, h'',       hash_length )
+
+                 Figure 6: Key Derivations Using EDHOC_KDF
+
+   h'' is CBOR diagnostic notation for the empty byte string, 0x40.
+
+4.1.3.  PRK_out
+
+   The pseudorandom key PRK_out, derived as shown in Figure 6, is the
+   output session key of a completed EDHOC session.
+
+   Keys for applications are derived using EDHOC_Exporter (see
+   Section 4.2.1) from PRK_exporter, which in turn is derived from
+   PRK_out as shown in Figure 6.  For the purpose of generating
+   application keys, it is sufficient to store PRK_out or PRK_exporter.
+   (Note that the word "store" used here does not imply that the
+   application has access to the plaintext PRK_out since that may be
+   reserved for code within a Trusted Execution Environment (TEE); see
+   Section 9.8.)
+
+4.2.  Keys for EDHOC Applications
+
+   This section defines EDHOC_Exporter in terms of EDHOC_KDF and
+   PRK_exporter.  A key update function is defined in Appendix H.
+
+4.2.1.  EDHOC_Exporter
+
+   Keying material for the application can be derived using the
+   EDHOC_Exporter interface defined as:
+
+      EDHOC_Exporter(exporter_label, context, length)
+        = EDHOC_KDF(PRK_exporter, exporter_label, context, length)
+
+   where:
+
+   *  exporter_label is a registered uint from the "EDHOC Exporter
+      Labels" registry (Section 10.1),
+
+   *  context is a bstr defined by the application, and
+
+   *  length is a uint defined by the application.
+
+   The (exporter_label, context) pair used in EDHOC_Exporter must be
+   unique, i.e., an (exporter_label, context) MUST NOT be used for two
+   different purposes.  However, an application can re-derive the same
+   key several times as long as it is done securely.  For example, in
+   most encryption algorithms, the same key can be reused with different
+   nonces.  The context can, for example, be the empty CBOR byte string.
+
+   Examples of use of the EDHOC_Exporter are given in Appendix A.
+
+5.  Message Formatting and Processing
+
+   This section specifies formatting of the messages and processing
+   steps.  Error messages are specified in Section 6.  Annotated traces
+   of EDHOC sessions are provided in [RFC9529].
+
+   An EDHOC message is encoded as a sequence of CBOR data items (CBOR
+   Sequence [RFC8742]).  Additional optimizations are made to reduce
+   message overhead.
+
+   While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0
+   structures, only a subset of the parameters is included in the EDHOC
+   messages; see Appendix C.3.  In order to recreate the COSE object,
+   the recipient endpoint may need to add parameters to the COSE headers
+   not included in the EDHOC message, for example, the parameter 'alg'
+   to COSE_Sign1 or COSE_Encrypt0.
+
+5.1.  EDHOC Message Processing Outline
+
+   For each new/ongoing EDHOC session, the endpoints are assumed to keep
+   an associated protocol state containing identifiers, keying material,
+   etc. used for subsequent processing of protocol-related data.  The
+   protocol state is assumed to be associated with an application
+   profile (Section 3.9) that provides the context for how messages are
+   transported, identified, and processed.
+
+   EDHOC messages SHALL be processed according to the current protocol
+   state.  The following steps are expected to be performed at reception
+   of an EDHOC message:
+
+   1.  Detect that an EDHOC message has been received, for example, by
+       means of a port number, URI, or media type (Section 3.9).
+
+   2.  Retrieve the protocol state according to the message correlation;
+       see Section 3.4.1.  If there is no protocol state, in the case of
+       message_1, a new protocol state is created.  The Responder
+       endpoint needs to make use of available denial-of-service
+       mitigation (Section 9.7).
+
+   3.  If the message received is an error message, then process it
+       according to Section 6, else process it as the expected next
+       message according to the protocol state.
+
+   The message processing steps SHALL be processed in order, unless
+   otherwise stated.  If the processing fails for some reason, then
+   typically an error message is sent, the EDHOC session is aborted, and
+   the protocol state is erased.  When the composition and sending of
+   one message is completed and before the next message is received,
+   error messages SHALL NOT be sent.
+
+   After having successfully processed the last message (message_3 or
+   message_4 depending on application profile), the EDHOC session is
+   completed; after which, no error messages are sent and EDHOC session
+   output MAY be maintained even if error messages are received.
+   Further details are provided in the following subsections and in
+   Section 6.
+
+   Different instances of the same message MUST NOT be processed in one
+   EDHOC session.  Note that processing will fail if the same message
+   appears a second time for EDHOC processing in the same EDHOC session
+   because the state of the protocol has moved on and now expects
+   something else.  Message deduplication MUST be done by the transport
+   protocol (see Section 3.4) or, if not supported by the transport, as
+   described in Section 7.
+
+5.2.  EDHOC Message 1
+
+5.2.1.  Formatting of Message 1
+
+   message_1 SHALL be a CBOR Sequence (see Appendix C.1), as defined
+   below.
+
+   message_1 = (
+     METHOD : int,
+     SUITES_I : suites,
+     G_X : bstr,
+     C_I : bstr / -24..23,
+     ? EAD_1,
+   )
+
+   suites = [ 2* int ] / int
+   EAD_1 = 1* ead
+
+   where:
+
+   *  METHOD is an authentication method; see Section 3.2,
+
+   *  SUITES_I is an array of cipher suites that the Initiator supports
+      constructed as specified in Section 5.2.2,
+
+   *  G_X is the ephemeral public key of the Initiator, and
+
+   *  C_I is a variable-length connection identifier (note that
+      connection identifiers are byte strings but certain values are
+      represented as integers in the message; see Section 3.3.2), and
+
+   *  EAD_1 is external authorization data; see Section 3.8.
+
+5.2.2.  Initiator Composition of Message 1
+
+   The processing steps are detailed below and in Section 6.3.
+
+   The Initiator SHALL compose message_1 as follows:
+
+   *  Construct SUITES_I as an array of cipher suites supported by I in
+      order of preference by I with the first cipher suite in the array
+      being the most preferred by I and the last being the one selected
+      by I for this EDHOC session.  If the cipher suite most preferred
+      by I is selected, then SUITES_I contains only that cipher suite
+      and is encoded as an int.  All cipher suites, if any, preferred by
+      I over the selected one MUST be included.  (See also Section 6.3.)
+
+      -  The selected suite is based on what the Initiator can assume to
+         be supported by the Responder; if the Initiator previously
+         received from the Responder an error message with error code 2
+         containing SUITES_R (see Section 6.3) indicating cipher suites
+         supported by the Responder, then the Initiator SHOULD select
+         its most preferred supported cipher suite among those (bearing
+         in mind that error messages may be forged).
+
+      -  The Initiator MUST NOT change its order of preference for
+         cipher suites and MUST NOT omit a cipher suite preferred to the
+         selected one because of previous error messages received from
+         the Responder.
+
+   *  Generate an ephemeral ECDH key pair using the curve in the
+      selected cipher suite and format it as a COSE_Key.  Let G_X be the
+      'x' parameter of the COSE_Key.
+
+   *  Choose a connection identifier C_I and store it during the EDHOC
+      session.
+
+   *  Encode message_1 as a sequence of CBOR-encoded data items as
+      specified in Section 5.2.1
+
+5.2.3.  Responder Processing of Message 1
+
+   The Responder SHALL process message_1 in the following order:
+
+   1.  Decode message_1 (see Appendix C.1).
+
+   2.  Process message_1.  In particular, verify that the selected
+       cipher suite is supported and that no prior cipher suite as
+       ordered in SUITES_I is supported.
+
+   3.  If all processing completed successfully, and if EAD_1 is
+       present, then make it available to the application for EAD
+       processing.
+
+   If any processing step fails, then the Responder MUST send an EDHOC
+   error message back as defined in Section 6, and the EDHOC session
+   MUST be aborted.
+
+5.3.  EDHOC Message 2
+
+5.3.1.  Formatting of Message 2
+
+   message_2 SHALL be a CBOR Sequence (see Appendix C.1), as defined
+   below.
+
+   message_2 = (
+     G_Y_CIPHERTEXT_2 : bstr,
+   )
+
+   where:
+
+   *  G_Y_CIPHERTEXT_2 is the concatenation of G_Y (i.e., the ephemeral
+      public key of the Responder) and CIPHERTEXT_2.
+
+5.3.2.  Responder Composition of Message 2
+
+   The Responder SHALL compose message_2 as follows:
+
+   *  Generate an ephemeral ECDH key pair using the curve in the
+      selected cipher suite and format it as a COSE_Key.  Let G_Y be the
+      'x' parameter of the COSE_Key.
+
+   *  Choose a connection identifier C_R and store it for the length of
+      the EDHOC session.
+
+   *  Compute the transcript hash TH_2 = H( G_Y, H(message_1) ), where
+      H() is the EDHOC hash algorithm of the selected cipher suite.  The
+      input to the hash function is a CBOR Sequence.  Note that
+      H(message_1) can be computed and cached already in the processing
+      of message_1.
+
+   *  Compute MAC_2 as in Section 4.1.2 with context_2 = << C_R,
+      ID_CRED_R, TH_2, CRED_R, ? EAD_2 >> (see Appendix C.1 for
+      notation).
+
+      -  If the Responder authenticates with a static Diffie-Hellman key
+         (method equals 1 or 3), then mac_length_2 is the EDHOC MAC
+         length of the selected cipher suite.  If the Responder
+         authenticates with a signature key (method equals 0 or 2), then
+         mac_length_2 is equal to hash_length.
+
+      -  C_R is a variable-length connection identifier.  Note that
+         connection identifiers are byte strings but certain values are
+         represented as integers in the message; see Section 3.3.2.
+
+      -  ID_CRED_R is an identifier to facilitate the retrieval of
+         CRED_R; see Section 3.5.3.
+
+      -  CRED_R is a CBOR item containing the authentication credential
+         of the Responder; see Section 3.5.2.
+
+      -  EAD_2 is external authorization data; see Section 3.8.
+
+   *  If the Responder authenticates with a static Diffie-Hellman key
+      (method equals 1 or 3), then Signature_or_MAC_2 is MAC_2.  If the
+      Responder authenticates with a signature key (method equals 0 or
+      2), then Signature_or_MAC_2 is the 'signature' field of a
+      COSE_Sign1 object, computed as specified in Section 4.4 of
+      [RFC9052] using the signature algorithm of the selected cipher
+      suite, the private authentication key of the Responder, and the
+      following parameters as input (see Appendix C.3 for an overview of
+      COSE and Appendix C.1 for notation):
+
+      -  protected = << ID_CRED_R >>
+
+      -  external_aad = << TH_2, CRED_R, ? EAD_2 >>
+
+      -  payload = MAC_2
+
+   *  CIPHERTEXT_2 is calculated with a binary additive stream cipher,
+      using a keystream generated with EDHOC_Expand and the following
+      plaintext:
+
+      -  PLAINTEXT_2 = ( C_R, ID_CRED_R / bstr / -24..23,
+         Signature_or_MAC_2, ? EAD_2 )
+
+         o  If ID_CRED_R contains a single 'kid' parameter, i.e.,
+            ID_CRED_R = { 4 : kid_R }, then the compact encoding is
+            applied; see Section 3.5.3.2.
+
+         o  C_R is the variable-length connection identifier.  Note that
+            connection identifiers are byte strings, but certain values
+            are represented as integers in the message; see
+            Section 3.3.2.
+
+      -  Compute KEYSTREAM_2 as in Section 4.1.2, where plaintext_length
+         is the length of PLAINTEXT_2.  For the case of plaintext_length
+         exceeding the EDHOC_KDF output size, see Appendix G.
+
+      -  CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2
+
+   *  Encode message_2 as a sequence of CBOR-encoded data items as
+      specified in Section 5.3.1.
+
+5.3.3.  Initiator Processing of Message 2
+
+   The Initiator SHALL process message_2 in the following order:
+
+   1.  Decode message_2 (see Appendix C.1).
+
+   2.  Retrieve the protocol state using available message correlation
+       (e.g., the CoAP Token, the 5-tuple, or the prepended C_I; see
+       Section 3.4.1).
+
+   3.  Decrypt CIPHERTEXT_2; see Section 5.3.2.
+
+   4.  If all processing is completed successfully, then make ID_CRED_R
+       and (if present) EAD_2 available to the application for
+       authentication and EAD processing.  When and how to perform
+       authentication is up to the application.
+
+   5.  Obtain the authentication credential (CRED_R) and the
+       authentication key of R from the application (or by other means).
+
+   6.  Verify Signature_or_MAC_2 using the algorithm in the selected
+       cipher suite.  The verification process depends on the method;
+       see Section 5.3.2.  Make the result of the verification available
+       to the application.
+
+   If any processing step fails, then the Initiator MUST send an EDHOC
+   error message back as defined in Section 6, and the EDHOC session
+   MUST be aborted.
+
+5.4.  EDHOC Message 3
+
+5.4.1.  Formatting of Message 3
+
+   message_3 SHALL be a CBOR Sequence (see Appendix C.1), as defined
+   below.
+
+   message_3 = (
+     CIPHERTEXT_3 : bstr,
+   )
+
+5.4.2.  Initiator Composition of Message 3
+
+   The Initiator SHALL compose message_3 as follows:
+
+   *  Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2, CRED_R),
+      where H() is the EDHOC hash algorithm of the selected cipher
+      suite.  The input to the hash function is a CBOR Sequence.  Note
+      that TH_3 can be computed and cached already in the processing of
+      message_2.
+
+   *  Compute MAC_3 as in Section 4.1.2, with context_3 = << ID_CRED_I,
+      TH_3, CRED_I, ? EAD_3 >>
+
+      -  If the Initiator authenticates with a static Diffie-Hellman key
+         (method equals 2 or 3), then mac_length_3 is the EDHOC MAC
+         length of the selected cipher suite.  If the Initiator
+         authenticates with a signature key (method equals 0 or 1), then
+         mac_length_3 is equal to hash_length.
+
+      -  ID_CRED_I is an identifier to facilitate the retrieval of
+         CRED_I; see Section 3.5.3.
+
+      -  CRED_I is a CBOR item containing the authentication credential
+         of the Initiator; see Section 3.5.2.
+
+      -  EAD_3 is external authorization data; see Section 3.8.
+
+   *  If the Initiator authenticates with a static Diffie-Hellman key
+      (method equals 2 or 3), then Signature_or_MAC_3 is MAC_3.  If the
+      Initiator authenticates with a signature key (method equals 0 or
+      1), then Signature_or_MAC_3 is the 'signature' field of a
+      COSE_Sign1 object, computed as specified in Section 4.4 of
+      [RFC9052] using the signature algorithm of the selected cipher
+      suite, the private authentication key of the Initiator, and the
+      following parameters as input (see Appendix C.3):
+
+      -  protected = << ID_CRED_I >>
+
+      -  external_aad = << TH_3, CRED_I, ? EAD_3 >>
+
+      -  payload = MAC_3
+
+   *  Compute a COSE_Encrypt0 object as defined in Sections 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 (see Appendix C.3):
+
+      -  protected = h''
+
+      -  external_aad = TH_3
+
+      -  K_3 and IV_3 are defined in Section 4.1.2
+
+      -  PLAINTEXT_3 = ( ID_CRED_I / bstr / -24..23, Signature_or_MAC_3,
+         ? EAD_3 )
+
+         o  If ID_CRED_I contains a single 'kid' parameter, i.e.,
+            ID_CRED_I = { 4 : kid_I }, then the compact encoding is
+            applied; see Section 3.5.3.2.
+
+      CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.
+
+   *  Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I),
+      where H() is the EDHOC hash algorithm of the selected cipher
+      suite.  The input to the hash function is a CBOR Sequence.
+
+   *  Calculate PRK_out as defined in Figure 6.  The Initiator can now
+      derive application keys using the EDHOC_Exporter interface; see
+      Section 4.2.1.
+
+   *  Encode message_3 as a CBOR data item as specified in
+      Section 5.4.1.
+
+   *  Make the connection identifiers (C_I and C_R) and the application
+      algorithms in the selected cipher suite available to the
+      application.
+
+   After creating message_3, the Initiator can compute PRK_out (see
+   Section 4.1.3) and derive application keys using the EDHOC_Exporter
+   interface (see Section 4.2.1).  The Initiator SHOULD NOT persistently
+   store PRK_out or application keys until the Initiator has verified
+   message_4 or a message protected with a derived application key, such
+   as an OSCORE message, from the Responder and the application has
+   authenticated the Responder.  This is similar to waiting for an
+   acknowledgment (ACK) in a transport protocol.  The Initiator SHOULD
+   NOT send protected application data until the application has
+   authenticated the Responder.
+
+5.4.3.  Responder Processing of Message 3
+
+   The Responder SHALL process message_3 in the following order:
+
+   1.  Decode message_3 (see Appendix C.1).
+
+   2.  Retrieve the protocol state using available message correlation
+       (e.g., the CoAP Token, the 5-tuple, or the prepended C_R; see
+       Section 3.4.1).
+
+   3.  Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
+       and 5.3 of [RFC9052], with the EDHOC AEAD algorithm in the
+       selected cipher suite and the parameters defined in
+       Section 5.4.2.
+
+   4.  If all processing completed successfully, then make ID_CRED_I and
+       (if present) EAD_3 available to the application for
+       authentication and EAD processing.  When and how to perform
+       authentication is up to the application.
+
+   5.  Obtain the authentication credential (CRED_I) and the
+       authentication key of I from the application (or by other means).
+
+   6.  Verify Signature_or_MAC_3 using the algorithm in the selected
+       cipher suite.  The verification process depends on the method;
+       see Section 5.4.2.  Make the result of the verification available
+       to the application.
+
+   7.  Make the connection identifiers (C_I and C_R) and the application
+       algorithms in the selected cipher suite available to the
+       application.
+
+   After processing message_3, the Responder can compute PRK_out (see
+   Section 4.1.3) and derive application keys using the EDHOC_Exporter
+   interface (see Section 4.2.1).  The Responder SHOULD NOT persistently
+   store PRK_out or application keys until the application has
+   authenticated the Initiator.  The Responder SHOULD NOT send protected
+   application data until the application has authenticated the
+   Initiator.
+
+   If any processing step fails, then the Responder MUST send an EDHOC
+   error message back as defined in Section 6, and the EDHOC session
+   MUST be aborted.
+
+5.5.  EDHOC Message 4
+
+   This section specifies message_4, which is OPTIONAL to support.  Key
+   confirmation is normally provided by sending an application message
+   from the Responder to the Initiator protected with a key derived with
+   the EDHOC_Exporter, e.g., using OSCORE (see Appendix A).  In
+   deployments where no protected application message is sent from the
+   Responder to the Initiator, message_4 MUST be supported and MUST be
+   used.  Two examples of such deployments are:
+
+   1.  when EDHOC is only used for authentication and no application
+       data is sent and
+
+   2.  when application data is only sent from the Initiator to the
+       Responder.
+
+   Further considerations about when to use message_4 are provided in
+   Sections 3.9 and 9.1.
+
+5.5.1.  Formatting of Message 4
+
+   message_4 SHALL be a CBOR Sequence (see Appendix C.1), as defined
+   below.
+
+   message_4 = (
+     CIPHERTEXT_4 : bstr,
+
+   )
+
+5.5.2.  Responder Composition of Message 4
+
+   The Responder SHALL compose message_4 as follows:
+
+   *  Compute a COSE_Encrypt0 as defined in Sections 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 (see Appendix C.3):
+
+      -  protected = h''
+
+      -  external_aad = TH_4
+
+      -  K_4 and IV_4 are defined in Section 4.1.2
+
+      -  PLAINTEXT_4 = ( ? EAD_4 )
+
+         o  EAD_4 is external authorization data; see Section 3.8.
+
+      CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0.
+
+   *  Encode message_4 as a CBOR data item as specified in
+      Section 5.5.1.
+
+5.5.3.  Initiator Processing of Message 4
+
+   The Initiator SHALL process message_4 as follows:
+
+   *  Decode message_4 (see Appendix C.1).
+
+   *  Retrieve the protocol state using available message correlation
+      (e.g., the CoAP Token, the 5-tuple, or the prepended C_I; see
+      Section 3.4.1).
+
+   *  Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
+      and 5.3 of [RFC9052], with the EDHOC AEAD algorithm in the
+      selected cipher suite and the parameters defined in Section 5.5.2.
+
+   *  Make (if present) EAD_4 available to the application for EAD
+      processing.
+
+   If any processing step fails, then the Initiator MUST send an EDHOC
+   error message back as defined in Section 6, and the EDHOC session
+   MUST be aborted.
+
+   After verifying message_4, the Initiator is assured that the
+   Responder has calculated the key PRK_out (key confirmation) and that
+   no other party can derive the key.
+
+6.  Error Handling
+
+   This section defines the format for error messages and the processing
+   associated with the currently defined error codes.  Additional error
+   codes may be registered; see Section 10.4.
+
+   Many kinds of errors can occur during EDHOC processing.  As in CoAP,
+   an error can be triggered by errors in the received message or
+   internal errors in the receiving endpoint.  Except for processing and
+   formatting errors, it is up to the application when to send an error
+   message.  Sending error messages is essential for debugging but MAY
+   be skipped if, for example, an EDHOC session cannot be found or due
+   to denial-of-service reasons; see Section 9.7.  Error messages in
+   EDHOC are always fatal.  After sending an error message, the sender
+   MUST abort the EDHOC session.  The receiver SHOULD treat an error
+   message as an indication that the other party likely has aborted the
+   EDHOC session.  But since error messages might be forged, the
+   receiver MAY try to continue the EDHOC session.
+
+   An EDHOC error message can be sent by either endpoint as a reply to
+   any non-error EDHOC message.  How errors at the EDHOC layer are
+   transported depends on lower layers, which need to enable error
+   messages to be sent and processed as intended.
+
+   error SHALL be a CBOR Sequence (see Appendix C.1), as defined below.
+
+   error = (
+     ERR_CODE : int,
+     ERR_INFO : any,
+   )
+
+                       Figure 7: EDHOC Error Message
+
+   where:
+
+   *  ERR_CODE is an error code encoded as an integer.  The value 0 is
+      reserved for success and can only be used internally; all other
+      values (negative or positive) indicate errors.
+
+   *  ERR_INFO is error information.  Content and encoding depend on the
+      error code.
+
+   The remainder of this section specifies the currently defined error
+   codes; see Table 3.  Additional error codes and corresponding error
+   information may be specified.
+
+       +==========+===============+===============================+
+       | ERR_CODE | ERR_INFO Type | Description                   |
+       +==========+===============+===============================+
+       |        0 |               | Reserved for success          |
+       +----------+---------------+-------------------------------+
+       |        1 | tstr          | Unspecified error             |
+       +----------+---------------+-------------------------------+
+       |        2 | suites        | Wrong selected cipher suite   |
+       +----------+---------------+-------------------------------+
+       |        3 | true          | Unknown credential referenced |
+       +----------+---------------+-------------------------------+
+       |       23 |               | Reserved                      |
+       +----------+---------------+-------------------------------+
+
+             Table 3: EDHOC Error Codes and Error Information
+
+6.1.  Success
+
+   Error code 0 MAY be used internally in an application to indicate
+   success, i.e., as a standard value in case of no error, e.g., in
+   status reporting or log files.  Error code 0 MUST NOT be used as part
+   of the EDHOC message exchange.  If an endpoint receives an error
+   message with error code 0, then it MUST abort the EDHOC session and
+   MUST NOT send an error message.
+
+6.2.  Unspecified Error
+
+   Error code 1 is used for errors that do not have a specific error
+   code defined.  ERR_INFO MUST be a text string containing a human-
+   readable diagnostic message that SHOULD be written in English, for
+   example, "Method not supported".  The diagnostic text message is
+   mainly intended for software engineers who during debugging need to
+   interpret it in the context of the EDHOC specification.  The
+   diagnostic message SHOULD be provided to the calling application
+   where it SHOULD be logged.
+
+6.3.  Wrong Selected Cipher Suite
+
+   Error code 2 MUST only be used when replying to message_1 in case the
+   cipher suite selected by the Initiator is not supported by the
+   Responder or if the Responder supports a cipher suite more preferred
+   by the Initiator than the selected cipher suite; see Section 5.2.3.
+   In this case, ERR_INFO = SUITES_R and is of type suites; see
+   Section 5.2.1.  If the Responder does not support the selected cipher
+   suite, then SUITES_R MUST include one or more supported cipher
+   suites.  If the Responder supports a cipher suite in SUITES_I other
+   than the selected cipher suite (independently of if the selected
+   cipher suite is supported or not), then SUITES_R MUST include the
+   supported cipher suite in SUITES_I, which is most preferred by the
+   Initiator.  SUITES_R MAY include a single cipher suite; in which
+   case, it is encoded as an int.  If the Responder does not support any
+   cipher suite in SUITES_I, then it SHOULD include all its supported
+   cipher suites in SUITES_R.
+
+   In contrast to SUITES_I, the order of the cipher suites in SUITES_R
+   has no significance.
+
+6.3.1.  Cipher Suite Negotiation
+
+   After receiving SUITES_R, the Initiator can determine which cipher
+   suite to select (if any) for the next EDHOC run with the Responder.
+   The Initiator SHOULD remember which selected cipher suite to use
+   until the next message_1 has been sent; otherwise, the Initiator and
+   Responder will run into an infinite loop where the Initiator selects
+   its most preferred cipher suite and the Responder sends an error with
+   supported cipher suites.
+
+   After a completed EDHOC session, the Initiator MAY remember the
+   selected cipher suite to use in future EDHOC sessions with this
+   Responder.  Note that if the Initiator or Responder is updated with
+   new cipher suite policies, any cached information may be outdated.
+
+   Note that the Initiator's list of supported cipher suites and order
+   of preference is fixed (see Sections 5.2.1 and 5.2.2).  Furthermore,
+   the Responder SHALL only accept message_1 if the selected cipher
+   suite is the first cipher suite in SUITES_I that the Responder also
+   supports (see Section 5.2.3).  Following this procedure ensures that
+   the selected cipher suite is the most preferred (by the Initiator)
+   cipher suite supported by both parties.  For examples, see
+   Section 6.3.2.
+
+   If the selected cipher suite is not the first cipher suite that the
+   Responder supports in SUITES_I received in message_1, then the
+   Responder MUST abort the EDHOC session; see Section 5.2.3.  If
+   SUITES_I in message_1 is manipulated, then the integrity verification
+   of message_2 containing the transcript hash TH_2 will fail and the
+   Initiator will abort the EDHOC session.
+
+6.3.2.  Examples
+
+   Assume that the Initiator supports the five cipher suites, 5, 6, 7,
+   8, and 9, in decreasing order of preference.  Figures 8 and 9 show
+   two examples of how the Initiator can format SUITES_I and how
+   SUITES_R is used by Responders to give the Initiator information
+   about the cipher suites that the Responder supports.
+
+   In Example 1 (Figure 8), the Responder supports cipher suite 6 but
+   not the initially selected cipher suite 5.  The Responder rejects the
+   first message_1 with an error indicating support for suite 6 in
+   SUITES_R.  The Initiator also supports suite 6 and therefore selects
+   suite 6 in the second message_1.  The Initiator prepends in SUITES_I
+   the selected suite 6 with the more preferred suites, in this case
+   suite 5, to mitigate a potential attack on the cipher suite
+   negotiation.
+
+   Initiator                                                   Responder
+   |              METHOD, SUITES_I = 5, G_X, C_I, EAD_1                |
+   +------------------------------------------------------------------>|
+   |                             message_1                             |
+   |                                                                   |
+   |                   ERR_CODE = 2, SUITES_R = 6                      |
+   |<------------------------------------------------------------------+
+   |                               error                               |
+   |                                                                   |
+   |             METHOD, SUITES_I = [5, 6], G_X, C_I, EAD_1            |
+   +------------------------------------------------------------------>|
+   |                             message_1                             |
+
+                Figure 8: Cipher Suite Negotiation Example 1
+
+   In Example 2 (Figure 9), the Responder supports cipher suites 8 and 9
+   but not the more preferred (by the Initiator) cipher suites 5, 6 or
+   7.  To illustrate the negotiation mechanics, we let the Initiator
+   first make a guess that the Responder supports suite 6 but not suite
+   5.  Since the Responder supports neither 5 nor 6, it rejects the
+   first message_1 with an error indicating support for suites 8 and 9
+   in SUITES_R (in any order).  The Initiator also supports suites 8 and
+   9, and prefers suite 8, so it selects suite 8 in the second
+   message_1.  The Initiator prepends in SUITES_I the selected suite 8
+   with the more preferred suites in order of preference, in this case,
+   suites 5, 6 and 7, to mitigate a potential attack on the cipher suite
+   negotiation.
+
+   Note 1.  If the Responder had supported suite 5, then the first
+            message_1 would not have been accepted either, since the
+            Responder observes that suite 5 is more preferred by the
+            Initiator than the selected suite 6.  In that case, the
+            Responder would have included suite 5 in SUITES_R of the
+            response, and it would then have become the selected and
+            only suite in the second message_1.
+
+   Note 2.  For each message_1, the Initiator MUST generate a new
+            ephemeral ECDH key pair matching the selected cipher suite.
+
+   Initiator                                                   Responder
+   |            METHOD, SUITES_I = [5, 6], G_X, C_I, EAD_1             |
+   +------------------------------------------------------------------>|
+   |                             message_1                             |
+   |                                                                   |
+   |                  ERR_CODE = 2, SUITES_R = [9, 8]                  |
+   |<------------------------------------------------------------------+
+   |                               error                               |
+   |                                                                   |
+   |           METHOD, SUITES_I = [5, 6, 7, 8], G_X, C_I, EAD_1        |
+   +------------------------------------------------------------------>|
+   |                             message_1                             |
+
+                Figure 9: Cipher Suite Negotiation Example 2
+
+6.4.  Unknown Credential Referenced
+
+   Error code 3 is used for errors due to a received credential
+   identifier (ID_CRED_R in message_2 or ID_CRED_I message_3) containing
+   a reference to a credential that the receiving endpoint does not have
+   access to.  The intent with this error code is that the endpoint who
+   sent the credential identifier should, for the next EDHOC session,
+   try another credential identifier supported according to the
+   application profile.
+
+   For example, an application profile could list x5t and x5chain as
+   supported credential identifiers and state that x5t should be used if
+   it can be assumed that the X.509 certificate is available at the
+   receiving side.  This error code thus enables the certificate chain
+   to be sent only when needed, bearing in mind that error messages are
+   not protected so an adversary can try to cause unnecessary, large
+   credential identifiers.
+
+   For the error code 3, the error information SHALL be the CBOR simple
+   value true (0xf5).  Error code 3 MUST NOT be used when the received
+   credential identifier type is not supported.
+
+7.  EDHOC Message Deduplication
+
+   By default, EDHOC assumes that message duplication is handled by the
+   transport (which is exemplified by CoAP in this section); see
+   Appendix A.2.
+
+   Deduplication of CoAP messages is described in Section 4.5 of
+   [RFC7252].  This handles the case when the same Confirmable (CON)
+   message is received multiple times due to missing acknowledgment on
+   the CoAP messaging layer.  The recommended processing in [RFC7252] is
+   that the duplicate message is acknowledged, but the received message
+   is only processed once by the CoAP stack.
+
+   Message deduplication is resource demanding and therefore not
+   supported in all CoAP implementations.  Since EDHOC is targeting
+   constrained environments, it is desirable that EDHOC can optionally
+   support transport layers that do not handle message duplication.
+   Special care is needed to avoid issues with duplicate messages; see
+   Section 5.1.
+
+   The guiding principle here is similar to the deduplication processing
+   on the CoAP messaging layer, i.e., a received duplicate EDHOC message
+   SHALL NOT result in another instance of the next EDHOC message.  The
+   result MAY be that a duplicate next EDHOC message is sent, provided
+   it is still relevant with respect to the current protocol state.  In
+   any case, the received message MUST NOT be processed more than once
+   in the same EDHOC session.  This is called "EDHOC message
+   deduplication".
+
+   An EDHOC implementation MAY store the previously sent EDHOC message
+   to be able to resend it.
+
+   In principle, if the EDHOC implementation would deterministically
+   regenerate the identical EDHOC message previously sent, it would be
+   possible to instead store the protocol state to be able to recreate
+   and resend the previously sent EDHOC message.  However, even if the
+   protocol state is fixed, the message generation may introduce
+   differences that compromise security.  For example, in the generation
+   of message_3, if I is performing a (non-deterministic) ECDSA
+   signature (say, method 0 or 1 and cipher suite 2 or 3), then
+   PLAINTEXT_3 is randomized, but K_3 and IV_3 are the same, leading to
+   a key and nonce reuse.
+
+   The EDHOC implementation MUST NOT store the previous protocol state
+   and regenerate an EDHOC message if there is a risk that the same key
+   and IV are used for two (or more) distinct messages.
+
+   The previous message or protocol state MUST NOT be kept longer than
+   what is required for retransmission, for example, in the case of CoAP
+   transport, no longer than the EXCHANGE_LIFETIME (see Section 4.8.2 of
+   [RFC7252]).
+
+8.  Compliance Requirements
+
+   In the absence of an application profile specifying otherwise:
+
+   *  An implementation MAY support only an Initiator or only a
+      Responder.
+
+   *  An implementation MAY support only a single method.  None of the
+      methods are mandatory to implement.
+
+   *  Implementations MUST support 'kid' parameters.  None of the other
+      COSE header parameters are mandatory to implement.
+
+   *  An implementation MAY support only a single credential type (CCS,
+      CWT, X.509, or C509).  None of the credential types are mandatory
+      to implement.
+
+   *  Implementations MUST support the EDHOC_Exporter.
+
+   *  Implementations MAY support message_4.  Error codes (ERR_CODE) 1
+      and 2 MUST be supported.
+
+   *  Implementations MUST support EAD.
+
+   *  Implementations MUST support cipher suites 2 and 3.  Cipher suites
+      2 (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128,
+      SHA-256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256,
+      AES-CCM-16-64-128, SHA-256) only differ in the size of the MAC
+      length, so supporting one or both of these is not significantly
+      different.  Implementations only need to implement the algorithms
+      needed for their supported methods.
+
+9.  Security Considerations
+
+9.1.  Security Properties
+
+   EDHOC has similar security properties as can be expected from the
+   theoretical SIGMA-I protocol [SIGMA] and the Noise XX pattern
+   [Noise], which are similar to methods 0 and 3, respectively.  Proven
+   security properties are detailed in the security analysis
+   publications referenced at the end of this section.
+
+   Using the terminology from [SIGMA], EDHOC provides forward secrecy,
+   mutual authentication with aliveness, consistency, and peer
+   awareness.  As described in [SIGMA], message_3 provides peer
+   awareness to the Responder, while message_4 provides peer awareness
+   to the Initiator.  By including the authentication credentials in the
+   transcript hash, EDHOC protects against an identity misbinding attack
+   like the Duplicate Signature Key Selection (DSKS) that the MAC-then-
+   Sign variant of SIGMA-I is otherwise vulnerable to.
+
+   As described in [SIGMA], different levels of identity protection are
+   provided to the Initiator and Responder.  EDHOC provides identity
+   protection of the Initiator against active attacks and identity
+   protection of the Responder against passive attacks.  An active
+   attacker can get the credential identifier of the Responder by
+   eavesdropping on the destination address used for transporting
+   message_1 and then sending its own message_1 to the same address.
+   The roles should be assigned to protect the most sensitive identity/
+   identifier, typically that which is not possible to infer from
+   routing information in the lower layers.
+
+   EDHOC messages might change in transit due to a noisy channel or
+   through modification by an attacker.  Changes in message_1 and
+   message_2 (except Signature_or_MAC_2 when the signature scheme is not
+   strongly unforgeable) are detected when verifying Signature_or_MAC_2.
+   Changes to not strongly unforgeable Signature_or_MAC_2 and message_3
+   are detected when verifying CIPHERTEXT_3.  Changes to message_4 are
+   detected when verifying CIPHERTEXT_4.
+
+   Compared to [SIGMA], EDHOC adds an explicit method type and expands
+   the message authentication coverage to additional elements such as
+   algorithms, external authorization data, and previous plaintext
+   messages.  This protects against an attacker replaying messages or
+   injecting messages from another EDHOC session.
+
+   EDHOC also adds the selection of connection identifiers and
+   downgrade-protected negotiation of cryptographic parameters, i.e., an
+   attacker cannot affect the negotiated parameters.  A single session
+   of EDHOC does not include negotiation of cipher suites, but it
+   enables the Responder to verify that the selected cipher suite is the
+   most preferred cipher suite by the Initiator that is supported by
+   both the Initiator and Responder and to abort the EDHOC session if
+   not.
+
+   As required by [RFC7258], IETF protocols need to mitigate pervasive
+   monitoring when possible.  Therefore, EDHOC only supports methods
+   with ephemeral Diffie-Hellman and provides a key update function (see
+   Appendix H) for lightweight application protocol rekeying.  Either of
+   these provides forward secrecy, in the sense that compromise of the
+   private authentication keys does not compromise past session keys
+   (PRK_out) and compromise of a session key does not compromise past
+   session keys.  Frequently re-running EDHOC with ephemeral Diffie-
+   Hellman forces attackers to perform dynamic key exfiltration where
+   the attacker must have continuous interactions with the collaborator,
+   which is a significant sustained attack.
+
+   To limit the effect of breaches, it is important to limit the use of
+   symmetric group keys for bootstrapping.  Therefore, EDHOC strives to
+   make the additional cost of using raw public keys and self-signed
+   certificates as small as possible.  Raw public keys and self-signed
+   certificates are not a replacement for a public key infrastructure
+   but SHOULD be used instead of symmetric group keys for bootstrapping.
+
+   Compromise of the long-term keys (private signature or static DH
+   keys) does not compromise the security of completed EDHOC sessions.
+   Compromising the private authentication keys of one party lets an
+   active attacker impersonate that compromised party in EDHOC sessions
+   with other parties but does not let the attacker impersonate other
+   parties in EDHOC sessions with the compromised party.  Compromise of
+   the long-term keys does not enable a passive attacker to compromise
+   future session keys (PRK_out).  Compromise of the HKDF input
+   parameters (ECDH shared secret) leads to compromise of all session
+   keys derived from that compromised shared secret.  Compromise of one
+   session key does not compromise other session keys.  Compromise of
+   PRK_out leads to compromise of all keying material derived with the
+   EDHOC_Exporter.
+
+   Based on the cryptographic algorithm requirements (Section 9.3),
+   EDHOC provides a minimum of 64-bit security against online brute
+   force attacks and a minimum of 128-bit security against offline brute
+   force attacks.  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 forgery against a 64-bit MAC in EDHOC breaks the
+   security of all future application data, while a forgery against a
+   64-bit MAC in the subsequent application protocol (e.g., OSCORE
+   [RFC8613]) typically only breaks the security of the data in the
+   forged packet.
+
+   As the EDHOC session is aborted when verification fails, the security
+   against online attacks is given by the sum of the strength of the
+   verified signatures and MACs (including MAC in AEAD).  As an example,
+   if EDHOC is used with method 3, cipher suite 2, and message_4, the
+   Responder is authenticated with 128-bit security against online
+   attacks (the sum of the 64-bit MACs in message_2 and message_4).  The
+   same principle applies for MACs in an application protocol keyed by
+   EDHOC as long as EDHOC is re-run when verification of the first MACs
+   in the application protocol fails.  As an example, if EDHOC with
+   method 3 and cipher suite 2 is used as in Figure 2 of
+   [EDHOC-CoAP-OSCORE], 128-bit mutual authentication against online
+   attacks can be achieved after completion of the first OSCORE request
+   and response.
+
+   After sending message_3, the Initiator is assured that no other party
+   than the Responder can compute the key PRK_out.  While the Initiator
+   can securely send protected application data, the Initiator SHOULD
+   NOT persistently store the keying material PRK_out until the
+   Initiator has verified message_4 or a message protected with a
+   derived application key, such as an OSCORE message, from the
+   Responder.  After verifying message_3, the Responder is assured that
+   an honest Initiator has computed the key PRK_out.  The Responder can
+   securely derive and store the keying material PRK_out and send
+   protected application data.
+
+   External authorization data sent in message_1 (EAD_1) or message_2
+   (EAD_2) should be considered unprotected by EDHOC; see Section 9.5.
+   EAD_2 is encrypted, but the Responder has not yet authenticated the
+   Initiator and the encryption does not provide confidentiality against
+   active attacks.
+
+   External authorization data sent in message_3 (EAD_3) or message_4
+   (EAD_4) is protected between the Initiator and Responder by the
+   protocol, but note that EAD fields may be used by the application
+   before the message verification is completed; see Section 3.8.
+   Designing a secure mechanism that uses EAD is not necessarily
+   straightforward.  This document only provides the EAD transport
+   mechanism, but the problem of agreeing on the surrounding context and
+   the meaning of the information passed to and from the application
+   remains.  Any new uses of EAD should be subject to careful review.
+
+   Key Compromise Impersonation (KCI):  In EDHOC authenticated with
+      signature keys, EDHOC provides KCI protection against an attacker
+      having access to the long-term key or the ephemeral secret key.
+      With static Diffie-Hellman key authentication, KCI protection
+      would be provided against an attacker having access to the long-
+      term Diffie-Hellman key but not to an attacker having access to
+      the ephemeral secret key.  Note that the term KCI has typically
+      been used for compromise of long-term keys and that an attacker
+      with access to the ephemeral secret key can only attack that
+      specific EDHOC session.
+
+   Repudiation:  If an endpoint authenticates with a signature, the
+      other endpoint can prove that the endpoint performed a run of the
+      protocol by presenting the data being signed as well as the
+      signature itself.  With static Diffie-Hellman key authentication,
+      the authenticating endpoint can deny having participated in the
+      protocol.
+
+   Earlier versions of EDHOC have been formally analyzed [Bruni18]
+   [Norrman20] [CottierPointcheval22] [Jacomme23] [GuentherIlunga22],
+   and the specification has been updated based on the analysis.
+
+9.2.  Cryptographic Considerations
+
+   The SIGMA protocol requires that the encryption of message_3 provides
+   confidentiality against active attackers and EDHOC message_4 relies
+   on the use of authenticated encryption.  Hence, the message
+   authenticating functionality of the authenticated encryption in EDHOC
+   is critical, i.e., authenticated encryption MUST NOT be replaced by
+   plain encryption only, even if authentication is provided at another
+   level or through a different mechanism.
+
+   To reduce message overhead, EDHOC does not use explicit nonces and
+   instead relies on the ephemeral public keys to provide randomness to
+   each EDHOC session.  A good amount of randomness is important for the
+   key generation to provide liveness and to protect against
+   interleaving attacks.  For this reason, the ephemeral keys MUST NOT
+   be used in more than one EDHOC message, and both parties SHALL
+   generate fresh, random ephemeral key pairs.  Note that an ephemeral
+   key may be used to calculate several ECDH shared secrets.  When
+   static Diffie-Hellman authentication is used, the same ephemeral key
+   is used in both ephemeral-ephemeral and ephemeral-static ECDH.
+
+   As discussed in [SIGMA], the encryption of message_2 only needs to
+   protect against a passive attacker since active attackers can always
+   get the Responder's identity by sending their own message_1.  EDHOC
+   uses the EDHOC_Expand function (typically HKDF-Expand) as a binary
+   additive stream cipher that is proven secure as long as the expand
+   function is a Pseudorandom Function (PRF).  HKDF-Expand is not often
+   used as a stream cipher as it is slow on long messages, and most
+   applications require both confidentiality with indistinguishability
+   under adaptive chosen ciphertext attack (IND-CCA2) as well as
+   integrity protection.  For the encryption of message_2, any speed
+   difference is negligible, IND-CCA2 does not increase security, and
+   integrity is provided by the inner MAC (and signature depending on
+   method).
+
+   Requirements for how to securely generate, validate, and process the
+   public keys depend on the elliptic curve.  For X25519 and X448, the
+   requirements are defined in [RFC7748].  For X25519 and X448, the
+   check for all-zero output as specified in Section 6 of [RFC7748] MUST
+   be done.  For secp256r1, secp384r1, and secp521r1, the requirements
+   are defined in Section 5 of [SP-800-56A].  For secp256r1, secp384r1,
+   and secp521r1, at least partial public key validation MUST be done.
+
+   The same authentication credential MAY be used for both the Initiator
+   and Responder roles.  As noted in Section 12 of [RFC9052], the use of
+   a single key for multiple algorithms is strongly discouraged unless
+   proven secure by a dedicated cryptographic analysis.  In particular,
+   this recommendation applies to using the same private key for static
+   Diffie-Hellman authentication and digital signature authentication.
+   A preliminary conjecture is that a minor change to EDHOC may be
+   sufficient to fit the analysis of a secure shared signature and ECDH
+   key usage in [Degabriele11] and [Thormarker21].  Note that
+   Section 5.6.3.2 of [SP-800-56A] allows a key agreement key pair to be
+   used with a signature algorithm in certificate requests.
+
+   The property that a completed EDHOC session implies that another
+   identity has been active is upheld as long as the Initiator does not
+   have its own identity in the set of Responder identities it is
+   allowed to communicate with.  In trust-on-first-use (TOFU) use cases
+   (see Appendix D.5), the Initiator should verify that the Responder's
+   identity is not equal to its own.  Any future EDHOC methods using,
+   e.g., PSKs might need to mitigate this in other ways.  However, an
+   active attacker can gain information about the set of identities an
+   Initiator is willing to communicate with.  If the Initiator is
+   willing to communicate with all identities except its own, an
+   attacker can determine that a guessed Initiator identity is correct.
+   To not leak any long-term identifiers, using a freshly generated
+   authentication key as an identity in each initial TOFU session is
+   RECOMMENDED.
+
+   NIST SP 800-56A [SP-800-56A] forbids deriving secret and non-secret
+   randomness from the same Key Derivation Function (KDF) instance, but
+   this decision has been criticized by Krawczyk in [HKDFpaper] and
+   doing so is common practice.  In addition to IVs, other examples are
+   the challenge in Extensible Authentication Protocol Tunneled
+   Transport Layer Security (EAP-TTLS), the RAND in 3GPP Authentication
+   and Key Agreement (AKA), and the Session-Id in EAP-TLS 1.3.  Note
+   that part of KEYSTREAM_2 is also non-secret randomness, as it is
+   known or predictable to an attacker.  The more recent NIST SP 800-108
+   [SP-800-108] aligns with [HKDFpaper] and states that, for a secure
+   KDF, the revelation of one portion of the derived keying material
+   must not degrade the security of any other portion of that keying
+   material.
+
+9.3.  Cipher Suites and Cryptographic Algorithms
+
+   When using a private cipher suite or registering new cipher suites,
+   the choice of the key length used in the different algorithms needs
+   to be harmonized so that a sufficient security level is maintained
+   for authentication credentials, the EDHOC session, and the protection
+   of application data.  The Initiator and Responder should enforce a
+   minimum security level.
+
+   The output size of the EDHOC hash algorithm MUST be at least 256
+   bits.  In particular, the hash algorithms SHA-1 and SHA-256/64
+   (SHA-256 truncated to 64 bits) SHALL NOT be supported for use in
+   EDHOC except for certificate identification with x5t and c5t.  For
+   security considerations of SHA-1, see [RFC6194].  As EDHOC integrity
+   protects all the authentication credentials, the choice of hash
+   algorithm in x5t and c5t does not affect security and using the same
+   hash algorithm as in the cipher suite, but with as much truncation as
+   possible, is RECOMMENDED.  That is, when the EDHOC hash algorithm is
+   SHA-256, using SHA-256/64 in x5t and c5t is RECOMMENDED.  The EDHOC
+   MAC length MUST be at least 8 bytes and the tag length of the EDHOC
+   AEAD algorithm MUST be at least 64 bits.  Note that secp256k1 is only
+   defined for use with ECDSA and not for ECDH.  Note that some COSE
+   algorithms are marked as not recommended in the COSE IANA registry.
+
+9.4.  Post-Quantum Considerations
+
+   As of the publication of this specification, it is unclear when or
+   even if a quantum computer of sufficient size and power to exploit
+   public key cryptography will exist.  Deployments that need to
+   consider risks decades into the future should transition to Post-
+   Quantum Cryptography (PQC) in the not-too-distant future.  Many other
+   systems should take a slower wait-and-see approach where PQC is
+   phased in when the quantum threat is more imminent.  Current PQC
+   algorithms have limitations compared to Elliptic Curve Cryptography
+   (ECC), and the data sizes would be problematic in many constrained
+   IoT systems.
+
+   Symmetric algorithms used in EDHOC, such as SHA-256 and AES-CCM-
+   16-64-128, are practically secure against even large quantum
+   computers.  Two of NIST's security levels for quantum-resistant
+   public key cryptography are based on AES-128 and SHA-256.  A quantum
+   computer will likely be expensive and slow due to heavy error
+   correction.  Grover's algorithm, which is proven to be optimal,
+   cannot effectively be parallelized.  It will provide little or no
+   advantage in attacking AES, and AES-128 will remain secure for
+   decades to come [NISTPQC].
+
+   EDHOC supports all signature algorithms defined by COSE, including
+   PQC signature algorithms such as HSS-LMS.  EDHOC is currently only
+   specified for use with key exchange algorithms of type ECDH curves,
+   but any Key Encapsulation Method (KEM), including PQC KEMs, can be
+   used in method 0.  While the key exchange in method 0 is specified
+   with the terms of the Diffie-Hellman protocol, the key exchange
+   adheres to a KEM interface: G_X is then the public key of the
+   Initiator, G_Y is the encapsulation, and G_XY is the shared secret.
+   Use of PQC KEMs to replace static DH authentication would likely
+   require a specification updating EDHOC with new methods.
+
+9.5.  Unprotected Data and Privacy
+
+   The Initiator and Responder must make sure that unprotected data and
+   metadata do not reveal any sensitive information.  This also applies
+   for encrypted data sent to an unauthenticated party.  In particular,
+   it applies to EAD_1, ID_CRED_R, EAD_2, and error messages.  Using the
+   same EAD_1 in several EDHOC sessions allows passive eavesdroppers to
+   correlate the different sessions.  Note that even if ead_value is
+   encrypted outside of EDHOC, the ead_labels in EAD_1 are revealed to
+   passive attackers and the ead_labels in EAD_2 are revealed to active
+   attackers.  Another consideration is that the list of supported
+   cipher suites may potentially be used to identify the application.
+   The Initiator and Responder must also make sure that unauthenticated
+   data does not trigger any harmful actions.  In particular, this
+   applies to EAD_1 and error messages.
+
+   An attacker observing network traffic may use connection identifiers
+   sent in clear in EDHOC or the subsequent application protocol to
+   correlate packets sent on different paths or at different times.  The
+   attacker may use this information for traffic flow analysis or to
+   track an endpoint.  Application protocols using connection
+   identifiers from EDHOC SHOULD provide mechanisms to update the
+   connection identifiers and MAY provide mechanisms to issue several
+   simultaneously active connection identifiers.  See [RFC9000] for a
+   non-constrained example of such mechanisms.  Connection identifiers
+   can, e.g., be chosen randomly among the set of unused 1-byte
+   connection identifiers.  Connection identity privacy mechanisms are
+   only useful when there are not fixed identifiers, such as IP address
+   or MAC address in the lower layers.
+
+9.6.  Updated Internet Threat Model Considerations
+
+   Since the publication of [RFC3552], there has been an increased
+   awareness of the need to protect against endpoints that are
+   compromised or malicious or whose interests simply do not align with
+   the interests of users [THREAT-MODEL-GUIDANCE].  [RFC7624] describes
+   an updated threat model for Internet confidentiality; see
+   Section 9.1.  [THREAT-MODEL-GUIDANCE] further expands the threat
+   model.  Implementations and users should take these threat models
+   into account and consider actions to reduce the risk of tracking by
+   other endpoints.  In particular, even data sent protected to the
+   other endpoint, such as ID_CRED fields and EAD fields, can be used
+   for tracking; see Section 2.7 of [THREAT-MODEL-GUIDANCE].
+
+   The fields ID_CRED_I, ID_CRED_R, EAD_2, EAD_3, and EAD_4 have
+   variable length, and information regarding the length may leak to an
+   attacker.  A passive attacker may, e.g., be able to differentiate
+   endpoints using identifiers of different length.  To mitigate this
+   information leakage, an implementation may ensure that the fields
+   have a fixed length or use padding.  An implementation may, e.g.,
+   only use fixed length identifiers like 'kid' of length 1.
+   Alternatively, padding may be used (see Section 3.8.1) to hide the
+   true length of, e.g., certificates by value in 'x5chain' or 'c5c'.
+
+9.7.  Denial of Service
+
+   EDHOC itself does not provide countermeasures against denial-of-
+   service attacks.  In particular, by sending a number of new or
+   replayed message_1, an attacker may cause the Responder to allocate
+   the state, perform cryptographic operations, and amplify messages.
+   To mitigate such attacks, an implementation SHOULD make use of
+   available lower layer mechanisms.  For instance, when EDHOC is
+   transferred as an exchange of CoAP messages, the CoAP server can use
+   the Echo option defined in [RFC9175], which forces the CoAP client to
+   demonstrate reachability at its apparent network address.  To avoid
+   an additional round trip, the Initiator can reduce the amplification
+   factor by padding message_1, i.e., using EAD_1; see Section 3.8.1.
+   Note that while the Echo option mitigates some resource exhaustion
+   aspects of spoofing, it does not protect against a distributed
+   denial-of-service attack made by real, potentially compromised,
+   clients.  Similarly, limiting amplification only reduces the impact,
+   which still may be significant because of a large number of clients
+   engaged in the attack.
+
+   An attacker can also send a faked message_2, message_3, message_4, or
+   error in an attempt to trick the receiving party to send an error
+   message and abort the EDHOC session.  EDHOC implementations MAY
+   evaluate if a received message is likely to have been forged by an
+   attacker and ignore it without sending an error message or aborting
+   the EDHOC session.
+
+9.8.  Implementation Considerations
+
+   The availability of a secure random number generator is essential for
+   the security of EDHOC.  If no true random number generator is
+   available, a random seed MUST be provided from an external source and
+   used with a cryptographically secure pseudorandom number generator.
+   As each pseudorandom number must only be used once, an implementation
+   needs to get a unique input to the pseudorandom number generator
+   after reboot or continuously store state in nonvolatile memory.
+   Appendix B.1.1 of [RFC8613] describes issues and solution approaches
+   for writing to nonvolatile memory.  Intentionally or unintentionally
+   weak or predictable pseudorandom number generators can be abused or
+   exploited for malicious purposes.  [RFC8937] describes a way for
+   security protocol implementations to augment their (pseudo)random
+   number generators using a long-term private key and a deterministic
+   signature function.  This improves randomness from broken or
+   otherwise subverted random number generators.  The same idea can be
+   used with other secrets and functions, such as a Diffie-Hellman
+   function or a symmetric secret, and a PRF like HMAC or KMAC.  It is
+   RECOMMENDED to not trust a single source of randomness and to not put
+   unaugmented random numbers on the wire.
+
+   For many constrained IoT devices, it is problematic to support
+   several crypto primitives.  Existing devices can be expected to
+   support either ECDSA or Edwards-curve Digital Signature Algorithm
+   (EdDSA).  If ECDSA is supported, "deterministic ECDSA", as specified
+   in [RFC6979], MAY be used.  Pure deterministic elliptic-curve
+   signatures, such as deterministic ECDSA and EdDSA, have gained
+   popularity over randomized ECDSA as their security does not depend on
+   a source of high-quality randomness.  Recent research has however
+   found that implementations of these signature algorithms may be
+   vulnerable to certain side-channel and fault injection attacks due to
+   their determinism.  For example, see Section 1 of [HEDGED-ECC-SIGS]
+   for a list of attack papers.  As suggested in Section 2.1.1 of
+   [RFC9053], this can be addressed by combining randomness and
+   determinism.
+
+   Appendix D of [CURVE-REPR] describes how Montgomery curves, such as
+   X25519 and X448, and (twisted) Edwards curves, such as Ed25519 and
+   Ed448, can be mapped to and from short-Weierstrass form for
+   implementations on platforms that accelerate elliptic curve group
+   operations in short-Weierstrass form.
+
+   All private keys, symmetric keys, and IVs MUST be secret.  Only the
+   Responder SHALL have access to the Responder's private authentication
+   key, and only the Initiator SHALL have access to the Initiator's
+   private authentication key.  Implementations should provide
+   countermeasures to side-channel attacks, such as timing attacks.
+   Intermediate computed values, such as ephemeral ECDH keys and ECDH
+   shared secrets, MUST be deleted after key derivation is completed.
+
+   The Initiator and Responder are responsible for verifying the
+   integrity and validity of certificates.  Verification of validity may
+   require the use of a Real-Time Clock (RTC).  The selection of trusted
+   certification authorities (CAs) should be done very carefully and
+   certificate revocation should be supported.  The choice of revocation
+   mechanism is left to the application.  For example, in case of X.509
+   certificates, Certificate Revocation Lists [RFC5280] or the Online
+   Certificate Status Protocol (OCSP) [RFC6960] may be used.
+
+   Similar considerations as for certificates are needed for CWT/CCS.
+   The endpoints are responsible for verifying the integrity and
+   validity of CWT/CCS and to handle revocation.  The application needs
+   to determine what trust anchors are relevant and have a well-defined
+   trust-establishment process.  A self-signed certificate / CWT or CCS
+   appearing in the protocol cannot be a trigger to modify the set of
+   trust anchors.  One common way for a new trust anchor to be added to
+   (or removed from) a device is by means firmware upgrade.  See
+   [RFC9360] for a longer discussion on trust and validation in
+   constrained devices.
+
+   Just like for certificates, the contents of the COSE header
+   parameters 'kcwt' and 'kccs' defined in Section 10.6 must be
+   processed as untrusted inputs.  Endpoints that intend to rely on the
+   assertions made by a CWT/CCS obtained from any of these methods need
+   to validate the contents.  For 'kccs', which enables transport of raw
+   public keys, the data structure used does not include any protection
+   or verification data. 'kccs' may be used for unauthenticated
+   operations, e.g., trust on first use, with the limitations and
+   caveats entailed; see Appendix D.5.
+
+   The Initiator and Responder are allowed to select connection
+   identifiers C_I and C_R, respectively, for the other party to use in
+   the ongoing EDHOC session as well as in a subsequent application
+   protocol (e.g., OSCORE [RFC8613]).  The choice of the connection
+   identifier is not security critical in EDHOC but intended to simplify
+   the retrieval of the right security context in combination with using
+   short identifiers.  If the wrong connection identifier of the other
+   party is used in a protocol message, it will result in the receiving
+   party not being able to retrieve a security context (which will abort
+   the EDHOC session) or retrieve the wrong security context (which also
+   aborts the EDHOC session as the message cannot be verified).
+
+   If two nodes unintentionally initiate two simultaneous EDHOC sessions
+   with each other, even if they only want to complete a single EDHOC
+   session, they MAY abort the EDHOC session with the lexicographically
+   smallest G_X.  Note that in cases where several EDHOC sessions with
+   different parameter sets (method, COSE headers, etc.) are used, an
+   attacker can affect which parameter set will be used by blocking some
+   of the parameter sets.
+
+   If supported by the device, it is RECOMMENDED that at least the long-
+   term private keys are stored in a Trusted Execution Environment (TEE)
+   (for example, see [RFC9397]) and that sensitive operations using
+   these keys are performed inside the TEE.  To achieve even higher
+   security, it is RECOMMENDED that additional operations such as
+   ephemeral key generation, all computations of shared secrets, and
+   storage of the PRK keys can be done inside the TEE.  The use of a TEE
+   aims at preventing code within that environment to be tampered with
+   and preventing data used by such code to be read or tampered with by
+   code outside that environment.
+
+   Note that HKDF-Expand has a relatively small maximum output length of
+   255 ⋅ hash_length, where hash_length is the output size in bytes of
+   the EDHOC hash algorithm of the selected cipher suite.  This means
+   that when SHA-256 is used as a hash algorithm, PLAINTEXT_2 cannot be
+   longer than 8160 bytes.  This is probably not a limitation for most
+   intended applications, but to be able to support, for example, long
+   certificate chains or large external authorization data, there is a
+   backwards compatible method specified in Appendix G.
+
+   The sequence of transcript hashes in EDHOC (TH_2, TH_3, and TH_4)
+   does not make use of a so-called running hash.  This is a design
+   choice, as running hashes are often not supported on constrained
+   platforms.
+
+   When parsing a received EDHOC message, implementations MUST abort the
+   EDHOC session if the message does not comply with the CDDL for that
+   message.  Implementations are not required to support non-
+   deterministic encodings and MAY abort the EDHOC session if the
+   received EDHOC message is not encoded using deterministic CBOR.
+   Implementations MUST abort the EDHOC session if validation of a
+   received public key fails or if any cryptographic field has the wrong
+   length.  It is RECOMMENDED to abort the EDHOC session if the received
+   EDHOC message is not encoded using deterministic CBOR.
+
+10.  IANA Considerations
+
+   This section gives IANA considerations and, unless otherwise noted,
+   conforms with [RFC8126].
+
+10.1.  EDHOC Exporter Label Registry
+
+   IANA has created a new registry under the new registry group
+   "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:
+
+   Registry Name:  EDHOC Exporter Labels
+
+   Reference:  RFC 9528
+
+        +=============+==============================+===========+
+        | Label       | Description                  | Reference |
+        +=============+==============================+===========+
+        | 0           | Derived OSCORE Master Secret | RFC 9528  |
+        +-------------+------------------------------+-----------+
+        | 1           | Derived OSCORE Master Salt   | RFC 9528  |
+        +-------------+------------------------------+-----------+
+        | 2-22        | Unassigned                   |           |
+        +-------------+------------------------------+-----------+
+        | 23          | Reserved                     | RFC 9528  |
+        +-------------+------------------------------+-----------+
+        | 24-32767    | Unassigned                   |           |
+        +-------------+------------------------------+-----------+
+        | 32768-65535 | Reserved for Private Use     |           |
+        +-------------+------------------------------+-----------+
+
+                      Table 4: EDHOC Exporter Labels
+
+   This registry also has a "Change Controller" field.  For
+   registrations made by IETF documents, the IETF is listed.
+
+                 +=============+=========================+
+                 | Range       | Registration Procedures |
+                 +=============+=========================+
+                 | 0-23        | Standards Action        |
+                 +-------------+-------------------------+
+                 | 24-32767    | Expert Review           |
+                 +-------------+-------------------------+
+                 | 32768-65535 | Private Use             |
+                 +-------------+-------------------------+
+
+                    Table 5: Registration Procedures for
+                           EDHOC Exporter Labels
+
+10.2.  EDHOC Cipher Suites Registry
+
+   IANA has created a new registry under the new registry group
+   "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:
+
+   Registry Name:  EDHOC Cipher Suites
+
+   Reference:  RFC 9528
+
+   The columns of the registry are Value, Array, Description, and
+   Reference, where Value is an integer and the other columns are text
+   strings.  The initial contents of the registry are:
+
+   +=======+================+=============================+===========+
+   | Value | Array          | Description                 | Reference |
+   +=======+================+=============================+===========+
+   | -24   | N/A            | Private Use                 | RFC 9528  |
+   +-------+----------------+-----------------------------+-----------+
+   | -23   | N/A            | Private Use                 | RFC 9528  |
+   +-------+----------------+-----------------------------+-----------+
+   | -22   | N/A            | Private Use                 | RFC 9528  |
+   +-------+----------------+-----------------------------+-----------+
+   | -21   | N/A            | Private Use                 | RFC 9528  |
+   +-------+----------------+-----------------------------+-----------+
+   | 0     | 10, -16, 8, 4, | AES-CCM-16-64-128, SHA-256, | RFC 9528  |
+   |       | -8, 10, -16    | 8, X25519, EdDSA,           |           |
+   |       |                | AES-CCM-16-64-128, SHA-256  |           |
+   +-------+----------------+-----------------------------+-----------+
+   | 1     | 30, -16, 16,   | AES-CCM-16-128-128,         | RFC 9528  |
+   |       | 4, -8, 10, -16 | SHA-256, 16, X25519, EdDSA, |           |
+   |       |                | AES-CCM-16-64-128, SHA-256  |           |
+   +-------+----------------+-----------------------------+-----------+
+   | 2     | 10, -16, 8, 1, | AES-CCM-16-64-128, SHA-256, | RFC 9528  |
+   |       | -7, 10, -16    | 8, P-256, ES256,            |           |
+   |       |                | AES-CCM-16-64-128, SHA-256  |           |
+   +-------+----------------+-----------------------------+-----------+
+   | 3     | 30, -16, 16,   | AES-CCM-16-128-128,         | RFC 9528  |
+   |       | 1, -7, 10, -16 | SHA-256, 16, P-256, ES256,  |           |
+   |       |                | AES-CCM-16-64-128, SHA-256  |           |
+   +-------+----------------+-----------------------------+-----------+
+   | 4     | 24, -16, 16,   | ChaCha20/Poly1305, SHA-256, | RFC 9528  |
+   |       | 4, -8, 24, -16 | 16, X25519, EdDSA,          |           |
+   |       |                | ChaCha20/Poly1305, SHA-256  |           |
+   +-------+----------------+-----------------------------+-----------+
+   | 5     | 24, -16, 16,   | ChaCha20/Poly1305, SHA-256, | RFC 9528  |
+   |       | 1, -7, 24, -16 | 16, P-256, ES256,           |           |
+   |       |                | ChaCha20/Poly1305, SHA-256  |           |
+   +-------+----------------+-----------------------------+-----------+
+   | 6     | 1, -16, 16, 4, | A128GCM, SHA-256, 16,       | RFC 9528  |
+   |       | -7, 1, -16     | X25519, ES256, A128GCM,     |           |
+   |       |                | SHA-256                     |           |
+   +-------+----------------+-----------------------------+-----------+
+   | 23    |                | Reserved                    | RFC 9528  |
+   +-------+----------------+-----------------------------+-----------+
+   | 24    | 3, -43, 16, 2, | A256GCM, SHA-384, 16,       | RFC 9528  |
+   |       | -35, 3, -43    | P-384, ES384, A256GCM,      |           |
+   |       |                | SHA-384                     |           |
+   +-------+----------------+-----------------------------+-----------+
+   | 25    | 24, -45, 16,   | ChaCha20/Poly1305,          | RFC 9528  |
+   |       | 5, -8, 24, -45 | SHAKE256, 16, X448, EdDSA,  |           |
+   |       |                | ChaCha20/Poly1305, SHAKE256 |           |
+   +-------+----------------+-----------------------------+-----------+
+
+                       Table 6: EDHOC Cipher Suites
+
+          +===============+=====================================+
+          | Range         | Registration Procedures             |
+          +===============+=====================================+
+          | -65536 to -25 | Specification Required              |
+          +---------------+-------------------------------------+
+          | -24 to -21    | Private Use                         |
+          +---------------+-------------------------------------+
+          | -20 to 23     | Standards Action with Expert Review |
+          +---------------+-------------------------------------+
+          | 24 to 65535   | Specification Required              |
+          +---------------+-------------------------------------+
+
+             Table 7: Registration Procedures for EDHOC Cipher
+                                   Suites
+
+10.3.  EDHOC Method Type Registry
+
+   IANA has created a new registry under the new registry group
+   "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:
+
+   Registry Name:  EDHOC Method Types
+
+   Reference:  RFC 9528
+
+   The columns of the registry are Value, Initiator Authentication Key,
+   Responder Authentication Key, and Reference, where Value is an
+   integer and the key columns are text strings describing the
+   authentication keys.
+
+   The initial contents of the registry are shown in Table 2.  Method 23
+   is Reserved.
+
+          +===============+=====================================+
+          | Range         | Registration Procedures             |
+          +===============+=====================================+
+          | -65536 to -25 | Specification Required              |
+          +---------------+-------------------------------------+
+          | -24 to 23     | Standards Action with Expert Review |
+          +---------------+-------------------------------------+
+          | 24 to 65535   | Specification Required              |
+          +---------------+-------------------------------------+
+
+          Table 8: Registration Procedures for EDHOC Method Types
+
+10.4.  EDHOC Error Codes Registry
+
+   IANA has created a new registry under the new registry group
+   "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:
+
+   Registry Name:  EDHOC Error Codes
+
+   Reference:  RFC 9528
+
+   The columns of the registry are ERR_CODE, ERR_INFO Type, Description,
+   Change Controller, and Reference, where ERR_CODE is an integer,
+   ERR_INFO is a CDDL defined type, and Description is a text string.
+   The initial contents of the registry are shown in Table 3.  Error
+   code 23 is Reserved.  This registry also has a "Change Controller"
+   field.  For registrations made by IETF documents, the IETF is listed.
+
+                +===============+=========================+
+                | Range         | Registration Procedures |
+                +===============+=========================+
+                | -65536 to -25 | Expert Review           |
+                +---------------+-------------------------+
+                | -24 to 23     | Standards Action        |
+                +---------------+-------------------------+
+                | 24 to 65535   | Expert Review           |
+                +---------------+-------------------------+
+
+                    Table 9: Registration Procedures for
+                             EDHOC Error Codes
+
+10.5.  EDHOC External Authorization Data Registry
+
+   IANA has created a new registry under the new registry group
+   "Ephemeral Diffie-Hellman Over COSE (EDHOC)" as follows:
+
+   Registry Name:  EDHOC External Authorization Data
+
+   Reference:  RFC 9528
+
+   The columns of the registry are Name, Label, Description, and
+   Reference, where Label is a nonnegative integer and the other columns
+   are text strings.  The initial contents of the registry are shown in
+   Table 10.  EAD label 23 is Reserved.
+
+         +=========+=======+====================+===============+
+         | Name    | Label | Description        | Reference     |
+         +=========+=======+====================+===============+
+         | Padding | 0     | Randomly generated | RFC 9528,     |
+         |         |       | CBOR byte string   | Section 3.8.1 |
+         +---------+-------+--------------------+---------------+
+         |         | 23    | Reserved           | RFC 9528      |
+         +---------+-------+--------------------+---------------+
+
+                        Table 10: EDHOC EAD Labels
+
+           +=============+=====================================+
+           | Range       | Registration Procedures             |
+           +=============+=====================================+
+           | 0 to 23     | Standards Action with Expert Review |
+           +-------------+-------------------------------------+
+           | 24 to 65535 | Specification Required              |
+           +-------------+-------------------------------------+
+
+              Table 11: Registration Procedures for EDHOC EAD
+                                   Labels
+
+10.6.  COSE Header Parameters Registry
+
+   IANA has registered the following entries in the "COSE Header
+   Parameters" registry under the registry group "CBOR Object Signing
+   and Encryption (COSE)" (see Table 12).  The value of the 'kcwt'
+   header parameter is a COSE Web Token (CWT) [RFC8392], and the value
+   of the 'kccs' header parameter is a CWT Claims Set (CCS); see
+   Section 1.4.  The CWT/CCS must contain a COSE_Key in a 'cnf' claim
+   [RFC8747].  The Value Registry column for this item is empty and
+   omitted from the table below.
+
+     +======+=======+===============+===============================+
+     | Name | Label | Value Type    | Description                   |
+     +======+=======+===============+===============================+
+     | kcwt | 13    | COSE_Messages | A CBOR Web Token (CWT)        |
+     |      |       |               | containing a COSE_Key in a    |
+     |      |       |               | 'cnf' claim and possibly      |
+     |      |       |               | other claims.  CWT is defined |
+     |      |       |               | in RFC 8392.  COSE_Messages   |
+     |      |       |               | is defined in RFC 9052.       |
+     +------+-------+---------------+-------------------------------+
+     | kccs | 14    | map           | A CWT Claims Set (CCS)        |
+     |      |       |               | containing a COSE_Key in a    |
+     |      |       |               | 'cnf' claim and possibly      |
+     |      |       |               | other claims.  CCS is defined |
+     |      |       |               | in RFC 8392.                  |
+     +------+-------+---------------+-------------------------------+
+
+                  Table 12: COSE Header Parameter Labels
+
+10.7.  Well-Known URI Registry
+
+   IANA has added the well-known URI "edhoc" to the "Well-Known URIs"
+   registry.
+
+   URI Suffix:  edhoc
+
+   Change Controller:  IETF
+
+   Reference:  RFC 9528
+
+   Related Information:  None
+
+10.8.  Media Types Registry
+
+   IANA has added the media types "application/edhoc+cbor-seq" and
+   "application/cid-edhoc+cbor-seq" to the "Media Types" registry.
+
+10.8.1.  application/edhoc+cbor-seq Media Type Registration
+
+   Type name:  application
+
+   Subtype name:  edhoc+cbor-seq
+
+   Required parameters:  N/A
+
+   Optional parameters:  N/A
+
+   Encoding considerations:  binary
+
+   Security considerations:  See Section 7 of RFC 9528.
+
+   Interoperability considerations:  N/A
+
+   Published specification:  RFC 9528
+
+   Applications that use this media type:  To be identified
+
+   Fragment identifier considerations:  N/A
+
+   Additional information:
+
+      Magic number(s):  N/A
+
+      File extension(s):  N/A
+
+      Macintosh file type code(s):  N/A
+
+   Person & email address to contact for further information:  See
+      "Authors' Addresses" section in RFC 9528.
+
+   Intended usage:  COMMON
+
+   Restrictions on usage:  N/A
+
+   Author:  See "Authors' Addresses" section.
+
+   Change Controller:  IETF
+
+10.8.2.  application/cid-edhoc+cbor-seq Media Type Registration
+
+   Type name:  application
+
+   Subtype name:  cid-edhoc+cbor-seq
+
+   Required parameters:  N/A
+
+   Optional parameters:  N/A
+
+   Encoding considerations:  binary
+
+   Security considerations:  See Section 7 of RFC 9528.
+
+   Interoperability considerations:  N/A
+
+   Published specification:  RFC 9528
+
+   Applications that use this media type:  To be identified
+
+   Fragment identifier considerations:  N/A
+
+   Additional information:
+
+      Magic number(s):  N/A
+
+      File extension(s):  N/A
+
+      Macintosh file type code(s):  N/A
+
+   Person & email address to contact for further information:  See
+      "Authors' Addresses" section in RFC 9528.
+
+   Intended usage:  COMMON
+
+   Restrictions on usage:  N/A
+
+   Author:  See "Authors' Addresses" section.
+
+   Change Controller:  IETF
+
+10.9.  CoAP Content-Formats Registry
+
+   IANA has added the media types "application/edhoc+cbor-seq" and
+   "application/cid-edhoc+cbor-seq" to the "CoAP Content-Formats"
+   registry under the registry group "Constrained RESTful Environments
+   (CoRE) Parameters".
+
+   +================================+================+====+===========+
+   | Content Type                   | Content Coding | ID | Reference |
+   +================================+================+====+===========+
+   | application/edhoc+cbor-seq     | -              | 64 | RFC 9528  |
+   +--------------------------------+----------------+----+-----------+
+   | application/cid-edhoc+cbor-seq | -              | 65 | RFC 9528  |
+   +--------------------------------+----------------+----+-----------+
+
+                    Table 13: CoAP Content-Format IDs
+
+10.10.  Resource Type (rt=) Link Target Attribute Values Registry
+
+   IANA has added the resource type "core.edhoc" to the "Resource Type
+   (rt=) Link Target Attribute Values" registry under the registry group
+   "Constrained RESTful Environments (CoRE) Parameters".
+
+   Value:  core.edhoc
+
+   Description:  EDHOC resource
+
+   Reference:  RFC 9528
+
+10.11.  Expert Review Instructions
+
+   The IANA registries established in this document are defined as
+   "Expert Review", "Specification Required", or "Standards Action with
+   Expert Review".  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:
+
+   *  The clarity and correctness of registrations.  Experts are
+      expected to check the clarity of purpose and use of the requested
+      entries.  Expert needs to make sure the values of algorithms are
+      taken from the right registry when that is required.  Experts
+      should consider requesting an opinion on the correctness of
+      registered parameters from relevant IETF working groups.
+      Encodings that do not meet these objectives of clarity and
+      completeness should not be registered.
+
+   *  The expected usage of fields when approving code point assignment.
+      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.
+
+   *  It is recommended to have a specification even if the registration
+      procedure is "Expert Review".  When specifications are not
+      provided for a request where Expert Review is the assignment
+      policy, the description provided needs to have sufficient
+      information to verify the code points as above.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
+              2002, <https://www.rfc-editor.org/info/rfc3279>.
+
+   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
+              Text on Security Considerations", BCP 72, RFC 3552,
+              DOI 10.17487/RFC3552, July 2003,
+              <https://www.rfc-editor.org/info/rfc3552>.
+
+   [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>.
+
+   [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/info/rfc5869>.
+
+   [RFC6090]  McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
+              Curve Cryptography Algorithms", RFC 6090,
+              DOI 10.17487/RFC6090, February 2011,
+              <https://www.rfc-editor.org/info/rfc6090>.
+
+   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
+              Galperin, S., and C. Adams, "X.509 Internet Public Key
+              Infrastructure Online Certificate Status Protocol - OCSP",
+              RFC 6960, DOI 10.17487/RFC6960, June 2013,
+              <https://www.rfc-editor.org/info/rfc6960>.
+
+   [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
+              Algorithm (DSA) and Elliptic Curve Digital Signature
+              Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
+              2013, <https://www.rfc-editor.org/info/rfc6979>.
+
+   [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/info/rfc7252>.
+
+   [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>.
+
+   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
+              the Constrained Application Protocol (CoAP)", RFC 7959,
+              DOI 10.17487/RFC7959, August 2016,
+              <https://www.rfc-editor.org/info/rfc7959>.
+
+   [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/info/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/info/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/info/rfc8392>.
+
+   [RFC8410]  Josefsson, S. and J. Schaad, "Algorithm Identifiers for
+              Ed25519, Ed448, X25519, and X448 for Use in the Internet
+              X.509 Public Key Infrastructure", RFC 8410,
+              DOI 10.17487/RFC8410, August 2018,
+              <https://www.rfc-editor.org/info/rfc8410>.
+
+   [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/info/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/info/rfc8613>.
+
+   [RFC8724]  Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
+              Zuniga, "SCHC: Generic Framework for Static Context Header
+              Compression and Fragmentation", RFC 8724,
+              DOI 10.17487/RFC8724, April 2020,
+              <https://www.rfc-editor.org/info/rfc8724>.
+
+   [RFC8742]  Bormann, C., "Concise Binary Object Representation (CBOR)
+              Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
+              <https://www.rfc-editor.org/info/rfc8742>.
+
+   [RFC8747]  Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
+              Tschofenig, "Proof-of-Possession Key Semantics for CBOR
+              Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
+              2020, <https://www.rfc-editor.org/info/rfc8747>.
+
+   [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>.
+
+   [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>.
+
+   [RFC9175]  Amsüss, C., Preuß Mattsson, J., and G. Selander,
+              "Constrained Application Protocol (CoAP): Echo, Request-
+              Tag, and Token Processing", RFC 9175,
+              DOI 10.17487/RFC9175, February 2022,
+              <https://www.rfc-editor.org/info/rfc9175>.
+
+   [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>.
+
+11.2.  Informative References
+
+   [Bruni18]  Bruni, A., Sahl Jørgensen, T., Grønbech Petersen, T., and
+              C. Schürmann, "Formal Verification of Ephemeral Diffie-
+              Hellman Over COSE (EDHOC)", November 2018,
+              <https://www.springerprofessional.de/en/formal-
+              verification-of-ephemeral-diffie-hellman-over-cose-
+              edhoc/16284348>.
+
+   [C509-CERTS]
+              Preuß Mattsson, J., 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-09, 4 March 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
+              cbor-encoded-cert-09>.
+
+   [CborMe]   Bormann, C., "CBOR Playground", <https://cbor.me/>.
+
+   [CNSA]     Wikipedia, "Commercial National Security Algorithm Suite",
+              October 2023, <https://en.wikipedia.org/w/index.php?title=
+              Commercial_National_Security_Algorithm_Suite&oldid=1181333
+              611>.
+
+   [CoAP-SEC-PROT]
+              Mattsson, J. P., Palombini, F., and M. Vučinić,
+              "Comparison of CoAP Security Protocols", Work in Progress,
+              Internet-Draft, draft-ietf-iotops-security-protocol-
+              comparison-04, 4 March 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-iotops-
+              security-protocol-comparison-04>.
+
+   [CottierPointcheval22]
+              Cottier, B. and D. Pointcheval, "Security Analysis of the
+              EDHOC protocol", September 2022,
+              <https://arxiv.org/abs/2209.03599>.
+
+   [CURVE-REPR]
+              Struik, R., "Alternative Elliptic Curve Representations",
+              Work in Progress, Internet-Draft, draft-ietf-lwig-curve-
+              representations-23, 21 January 2022,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-
+              curve-representations-23>.
+
+   [Degabriele11]
+              Degabriele, J., Lehmann, A., Paterson, K., Smart, N., and
+              M. Strefler, "On the Joint Security of Encryption and
+              Signature in EMV", December 2011,
+              <https://eprint.iacr.org/2011/615>.
+
+   [EAT]      Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
+              Wallace, "The Entity Attestation Token (EAT)", Work in
+              Progress, Internet-Draft, draft-ietf-rats-eat-25, 15
+              January 2024, <https://datatracker.ietf.org/doc/html/
+              draft-ietf-rats-eat-25>.
+
+   [EDHOC-CoAP-OSCORE]
+              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)", Work in Progress, Internet-Draft, draft-ietf-
+              core-oscore-edhoc-10, 29 November 2023,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
+              oscore-edhoc-10>.
+
+   [GuentherIlunga22]
+              Günther, F. and M. Mukendi, "Careful with MAc-then-SIGn: A
+              Computational Analysis of the EDHOC Lightweight
+              Authenticated Key Exchange Protocol", December 2022,
+              <https://eprint.iacr.org/2022/1705>.
+
+   [HEDGED-ECC-SIGS]
+              Preuß Mattsson, J., Thormarker, E., and S. Ruohomaa,
+              "Hedged ECDSA and EdDSA Signatures", Work in Progress,
+              Internet-Draft, draft-irtf-cfrg-det-sigs-with-noise-02, 1
+              March 2024, <https://datatracker.ietf.org/doc/html/draft-
+              irtf-cfrg-det-sigs-with-noise-02>.
+
+   [HKDFpaper]
+              Krawczyk, H., "Cryptographic Extraction and Key
+              Derivation: The HKDF Scheme", May 2010,
+              <https://eprint.iacr.org/2010/264.pdf>.
+
+   [IEEE.802.15.4-2015]
+              IEEE, "IEEE Standard for Low-Rate Wireless Networks",
+              DOI 10.1109/IEEESTD.2016.7460875, April 2016,
+              <https://ieeexplore.ieee.org/document/7460875>.
+
+   [Jacomme23]
+              Jacomme, C., Klein, E., Kremer, S., and M. Racouchot, "A
+              comprehensive, formal and automated analysis of the EDHOC
+              protocol", October 2022,
+              <https://hal.inria.fr/hal-03810102/>.
+
+   [KUDOS]    Höglund, R. and M. Tiloca, "Key Update for OSCORE
+              (KUDOS)", Work in Progress, Internet-Draft, draft-ietf-
+              core-oscore-key-update-07, 4 March 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
+              oscore-key-update-07>.
+
+   [LAKE-AUTHZ]
+              Selander, G., Mattsson, J. P., Vučinić, M., Fedrecheski,
+              G., and M. Richardson, "Lightweight Authorization using
+              Ephemeral Diffie-Hellman Over COSE", Work in Progress,
+              Internet-Draft, draft-ietf-lake-authz-01, 4 March 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-lake-
+              authz-01>.
+
+   [LAKE-REQS]
+              Vučinić, M., Selander, G., Preuß Mattsson, J., and D.
+              Garcia-Carillo, "Requirements for a Lightweight AKE for
+              OSCORE", Work in Progress, Internet-Draft, draft-ietf-
+              lake-reqs-04, 8 June 2020,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-lake-
+              reqs-04>.
+
+   [NISTPQC]  National Institute Standards and Technology (NIST), "Post-
+              Quantum Cryptography FAQs",
+              <https://csrc.nist.gov/Projects/post-quantum-cryptography/
+              faqs>.
+
+   [Noise]    Perrin, T., "The Noise Protocol Framework", Revision 34,
+              July 2018, <https://noiseprotocol.org/noise.html>.
+
+   [Norrman20]
+              Norrman, K., Sundararajan, V., and A. Bruni, "Formal
+              Analysis of EDHOC Key Establishment for Constrained IoT
+              Devices", September 2020,
+              <https://arxiv.org/abs/2007.11427>.
+
+   [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/info/rfc2986>.
+
+   [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>.
+
+   [RFC6194]  Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
+              Considerations for the SHA-0 and SHA-1 Message-Digest
+              Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
+              <https://www.rfc-editor.org/info/rfc6194>.
+
+   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
+              Constrained-Node Networks", RFC 7228,
+              DOI 10.17487/RFC7228, May 2014,
+              <https://www.rfc-editor.org/info/rfc7228>.
+
+   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
+              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
+              2014, <https://www.rfc-editor.org/info/rfc7258>.
+
+   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
+              Kivinen, "Internet Key Exchange Protocol Version 2
+              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
+              2014, <https://www.rfc-editor.org/info/rfc7296>.
+
+   [RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
+              Trammell, B., Huitema, C., and D. Borkmann,
+              "Confidentiality in the Face of Pervasive Surveillance: A
+              Threat Model and Problem Statement", RFC 7624,
+              DOI 10.17487/RFC7624, August 2015,
+              <https://www.rfc-editor.org/info/rfc7624>.
+
+   [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
+              "A Voucher Artifact for Bootstrapping Protocols",
+              RFC 8366, DOI 10.17487/RFC8366, May 2018,
+              <https://www.rfc-editor.org/info/rfc8366>.
+
+   [RFC8376]  Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
+              Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
+              <https://www.rfc-editor.org/info/rfc8376>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [RFC8937]  Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
+              and C. Wood, "Randomness Improvements for Security
+              Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
+              <https://www.rfc-editor.org/info/rfc8937>.
+
+   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
+              Multiplexed and Secure Transport", RFC 9000,
+              DOI 10.17487/RFC9000, May 2021,
+              <https://www.rfc-editor.org/info/rfc9000>.
+
+   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
+              Datagram Transport Layer Security (DTLS) Protocol Version
+              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
+              <https://www.rfc-editor.org/info/rfc9147>.
+
+   [RFC9176]  Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
+              P. van der Stok, "Constrained RESTful Environments (CoRE)
+              Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
+              2022, <https://www.rfc-editor.org/info/rfc9176>.
+
+   [RFC9397]  Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
+              "Trusted Execution Environment Provisioning (TEEP)
+              Architecture", RFC 9397, DOI 10.17487/RFC9397, July 2023,
+              <https://www.rfc-editor.org/info/rfc9397>.
+
+   [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/info/rfc9529>.
+
+   [SECG]     Certicom Research, "SEC 1: Elliptic Curve Cryptography",
+              Standards for Efficient Cryptography, May 2009,
+              <https://www.secg.org/sec1-v2.pdf>.
+
+   [SIGMA]    Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to
+              Authenticated Diffie-Hellman and Its Use in the IKE-
+              Protocols", June 2003,
+              <https://www.iacr.org/cryptodb/archive/2003/
+              CRYPTO/1495/1495.pdf>.
+
+   [SP-800-108]
+              Chen, L., "Recommendation for Key Derivation Using
+              Pseudorandom Functions", NIST Special Publication 800-108
+              Revision 1, DOI 10.6028/NIST.SP.800-108r1-upd1, August
+              2022, <https://doi.org/10.6028/NIST.SP.800-108r1-upd1>.
+
+   [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,
+              DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
+              <https://doi.org/10.6028/NIST.SP.800-56Ar3>.
+
+   [SP800-185]
+              Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived
+              Functions cSHAKE, KMAC, TupleHash and ParallelHash",
+              NIST Special Publication 800-185,
+              DOI 10.6028/NIST.SP.800-185, December 2016,
+              <https://doi.org/10.6028/NIST.SP.800-185>.
+
+   [Thormarker21]
+              Thormarker, E., "On using the same key pair for Ed25519
+              and an X25519 based KEM", April 2021,
+              <https://eprint.iacr.org/2021/509.pdf>.
+
+   [THREAT-MODEL-GUIDANCE]
+              Arkko, J. and S. Farrell, "Internet Threat Model
+              Guidance", Work in Progress, Internet-Draft, draft-arkko-
+              arch-internet-threat-model-guidance-00, 12 July 2021,
+              <https://datatracker.ietf.org/doc/html/draft-arkko-arch-
+              internet-threat-model-guidance-00>.
+
+Appendix A.  Use with OSCORE and Transfer over CoAP
+
+   This appendix describes how to derive an OSCORE security context when
+   EDHOC is used to key OSCORE and how to transfer EDHOC messages over
+   CoAP.  The use of CoAP or OSCORE with EDHOC is optional, but if you
+   are using CoAP or OSCORE, then certain normative requirements apply
+   as detailed in the subsections.
+
+A.1.  Deriving the OSCORE Security Context
+
+   This section specifies how to use EDHOC output to derive the OSCORE
+   security context.
+
+   After successful processing of EDHOC message_3, the Client and Server
+   derive Security Context parameters for OSCORE as follows (see
+   Section 3.2 of [RFC8613]):
+
+   *  The Master Secret and Master Salt SHALL be derived by using the
+      EDHOC_Exporter interface (see Section 4.2.1):
+
+      -  The EDHOC Exporter Labels for deriving the OSCORE Master Secret
+         and OSCORE Master Salt are the uints 0 and 1, respectively.
+
+      -  The context parameter is h'' (0x40), the empty CBOR byte
+         string.
+
+      -  By default, oscore_key_length is the key length (in bytes) of
+         the application AEAD Algorithm of the selected cipher suite for
+         the EDHOC session.  Also by default, oscore_salt_length has
+         value 8.  The Initiator and Responder MAY agree out-of-band on
+         a longer oscore_key_length than the default and on shorter or
+         longer than the default oscore_salt_length.
+
+      Master Secret = EDHOC_Exporter( 0, h'', oscore_key_length )
+      Master Salt   = EDHOC_Exporter( 1, h'', oscore_salt_length )
+
+   *  The AEAD Algorithm SHALL be the application AEAD algorithm of the
+      selected cipher suite for the EDHOC session.
+
+   *  The HKDF Algorithm SHALL be the one based on the application hash
+      algorithm of the selected cipher suite for the EDHOC session.  For
+      example, if SHA-256 is the application hash algorithm of the
+      selected cipher suite, HKDF SHA-256 is used as the HKDF Algorithm
+      in the OSCORE Security Context.
+
+   *  The relationship between identifiers in OSCORE and EDHOC is
+      specified in Section 3.3.3.  The OSCORE Sender ID and Recipient ID
+      SHALL be determined by EDHOC connection identifiers C_R and C_I
+      for the EDHOC session as shown in Table 14.
+
+       +=================+==================+=====================+
+       |                 | OSCORE Sender ID | OSCORE Recipient ID |
+       +=================+==================+=====================+
+       | EDHOC Initiator |       C_R        |         C_I         |
+       +-----------------+------------------+---------------------+
+       | EDHOC Responder |       C_I        |         C_R         |
+       +-----------------+------------------+---------------------+
+
+           Table 14: Usage of Connection Identifiers in OSCORE
+
+   The Client and Server SHALL use the parameters above to establish an
+   OSCORE Security Context, as per Section 3.2.1 of [RFC8613].
+
+   From then on, the Client and Server retrieve the OSCORE protocol
+   state using the Recipient ID and optionally other transport
+   information such as the 5-tuple.
+
+A.2.  Transferring EDHOC over CoAP
+
+   This section specifies how EDHOC can be transferred as an exchange of
+   CoAP [RFC7252] messages.  CoAP provides a reliable transport that can
+   preserve packet ordering, provides flow and congestion control, and
+   handles message duplication.  CoAP can also perform fragmentation and
+   mitigate certain denial-of-service attacks.  The underlying CoAP
+   transport should be used in reliable mode, in particular, when
+   fragmentation is used, to avoid, e.g., situations with hanging
+   endpoints waiting for each other.
+
+   EDHOC may run with the Initiator either being a CoAP client or CoAP
+   server.  We denote the former by the "forward message flow" (see
+   Appendix A.2.1) and the latter by the "reverse message flow" (see
+   Appendix A.2.2).  By default, we assume the forward message flow, but
+   the roles SHOULD be chosen to protect the most sensitive identity;
+   see Section 9.
+
+   According to this specification, EDHOC is transferred in POST
+   requests to the Uri-Path: "/.well-known/edhoc" (see Section 10.7) and
+   2.04 (Changed) responses.  An application may define its own path
+   that can be discovered, e.g., using a resource directory [RFC9176].
+   Client applications can use the resource type "core.edhoc" to
+   discover a server's EDHOC resource, i.e., where to send a request for
+   executing the EDHOC protocol; see Section 10.10.  An alternative
+   transfer of the forward message flow is specified in
+   [EDHOC-CoAP-OSCORE].
+
+   In order for the server to correlate a message received from a client
+   to a message previously sent in the same EDHOC session over CoAP,
+   messages sent by the client SHALL be prepended with the CBOR
+   serialization of the connection identifier that the server has
+   selected; see Section 3.4.1.  This applies both to the forward and
+   the reverse message flows.  To indicate a new EDHOC session in the
+   forward message flow, message_1 SHALL be prepended with the CBOR
+   simple value true (0xf5).  Even if CoAP is carried over a reliable
+   transport protocol, such as TCP, the prepending of identifiers
+   specified here SHALL be practiced to enable interoperability
+   independent of how CoAP is transported.
+
+   The prepended identifiers are encoded in CBOR and thus self-
+   delimiting.  The representation of identifiers described in
+   Section 3.3.2 SHALL be used.  They are sent in front of the actual
+   EDHOC message to keep track of messages in an EDHOC session, and only
+   the part of the body following the identifier is used for EDHOC
+   processing.  In particular, the connection identifiers within the
+   EDHOC messages are not impacted by the prepended identifiers.
+
+   An EDHOC message has media type "application/edhoc+cbor-seq", whereas
+   an EDHOC message prepended by a connection identifier has media type
+   "application/cid-edhoc+cbor-seq"; see Section 10.9.
+
+   To mitigate certain denial-of-service attacks, the CoAP server MAY
+   respond to the first POST request with a 4.01 (Unauthorized)
+   containing an Echo option [RFC9175].  This forces the Initiator to
+   demonstrate reachability at its apparent network address.  If message
+   fragmentation is needed, the EDHOC messages may be fragmented using
+   the CoAP Block-Wise Transfer mechanism [RFC7959].
+
+   EDHOC error messages need to be transported in response to a message
+   that failed (see Section 6).  EDHOC error messages transported with
+   CoAP are carried in the payload.
+
+   Note that the transport over CoAP can serve as a blueprint for other
+   client-server protocols:
+
+   *  The client prepends the connection identifier selected by the
+      server (or, for message_1, the CBOR simple value true) to any
+      request message it sends.
+
+   *  The server does not send any such indicator, as responses are
+      matched to request by the client-server protocol design.
+
+A.2.1.  The Forward Message Flow
+
+   In the forward message flow, the CoAP client is the Initiator and the
+   CoAP server is the Responder.  This flow protects the client identity
+   against active attackers and the server identity against passive
+   attackers.
+
+   In the forward message flow, the CoAP Token enables correlation on
+   the Initiator (client) side, and the prepended C_R enables
+   correlation on the Responder (server) side.
+
+   *  EDHOC message_1 is sent in the payload of a POST request from the
+      client to the server's resource for EDHOC, prepended with the
+      identifier true (0xf5), indicating a new EDHOC session.
+
+   *  EDHOC message_2 or the EDHOC error message is sent from the server
+      to the client in the payload of the response, in the former case
+      with response code 2.04 (Changed) and in the latter with response
+      code as specified in Appendix A.2.3.
+
+   *  EDHOC message_3 or the EDHOC error message is sent from the client
+      to the server's resource in the payload of a POST request,
+      prepended with connection identifier C_R.
+
+   *  If EDHOC message_4 is used, or in case of an error message, it is
+      sent from the server to the client in the payload of the response,
+      with response codes analogously to message_2.  In case of an error
+      message sent in response to message_4, it is sent analogously to
+      the error message sent in response to message_2.
+
+   An example of a completed EDHOC session over CoAP in the forward
+   message flow is shown in Figure 10.
+
+       Client    Server
+         |          |
+         +--------->| Header: POST (Code=0.02)
+         |   POST   | Uri-Path: "/.well-known/edhoc"
+         |          | Content-Format: application/cid-edhoc+cbor-seq
+         |          | Payload: true, EDHOC message_1
+         |          |
+         |<---------+ Header: 2.04 Changed
+         |   2.04   | Content-Format: application/edhoc+cbor-seq
+         |          | Payload: EDHOC message_2
+         |          |
+         +--------->| Header: POST (Code=0.02)
+         |   POST   | Uri-Path: "/.well-known/edhoc"
+         |          | Content-Format: application/cid-edhoc+cbor-seq
+         |          | Payload: C_R, EDHOC message_3
+         |          |
+         |<---------+ Header: 2.04 Changed
+         |   2.04   | Content-Format: application/edhoc+cbor-seq
+         |          | Payload: EDHOC message_4
+         |          |
+
+               Figure 10: Example of the Forward Message Flow
+
+   The forward message flow of EDHOC can be combined with an OSCORE
+   exchange in a total of two round trips; see [EDHOC-CoAP-OSCORE].
+
+A.2.2.  The Reverse Message Flow
+
+   In the reverse message flow, the CoAP client is the Responder and the
+   CoAP server is the Initiator.  This flow protects the server identity
+   against active attackers and the client identity against passive
+   attackers.
+
+   In the reverse message flow, the CoAP Token enables correlation on
+   the Responder (client) side, and the prepended C_I enables
+   correlation on the Initiator (server) side.
+
+   *  To trigger a new EDHOC session, the client makes an empty POST
+      request to the server's resource for EDHOC.
+
+   *  EDHOC message_1 is sent from the server to the client in the
+      payload of the response with response code 2.04 (Changed).
+
+   *  EDHOC message_2 or the EDHOC error message is sent from the client
+      to the server's resource in the payload of a POST request,
+      prepended with connection identifier C_I.
+
+   *  EDHOC message_3 or the EDHOC error message is sent from the server
+      to the client in the payload of the response, in the former case
+      with response code 2.04 (Changed) and in the latter with response
+      code as specified in Appendix A.2.3.
+
+   *  If EDHOC message_4 is used, or in case of an error message, it is
+      sent from the client to the server's resource in the payload of a
+      POST request, prepended with connection identifier C_I.  In case
+      of an error message sent in response to message_4, it is sent
+      analogously to an error message sent in response to message_2.
+
+   An example of a completed EDHOC session over CoAP in the reverse
+   message flow is shown in Figure 11.
+
+       Client    Server
+         |          |
+         +--------->| Header: POST (Code=0.02)
+         |   POST   | Uri-Path: "/.well-known/edhoc"
+         |          |
+         |<---------+ Header: 2.04 Changed
+         |   2.04   | Content-Format: application/edhoc+cbor-seq
+         |          | Payload: EDHOC message_1
+         |          |
+         +--------->| Header: POST (Code=0.02)
+         |   POST   | Uri-Path: "/.well-known/edhoc"
+         |          | Content-Format: application/cid-edhoc+cbor-seq
+         |          | Payload: C_I, EDHOC message_2
+         |          |
+         |<---------+ Header: 2.04 Changed
+         |   2.04   | Content-Format: application/edhoc+cbor-seq
+         |          | Payload: EDHOC message_3
+         |          |
+
+               Figure 11: Example of the Reverse Message Flow
+
+A.2.3.  Errors in EDHOC over CoAP
+
+   When using EDHOC over CoAP, EDHOC error messages sent as CoAP
+   responses MUST be sent in the payload of error responses, i.e., they
+   MUST specify a CoAP error response code.  In particular, it is
+   RECOMMENDED that such error responses have response code either 4.00
+   (Bad Request) in case of client error (e.g., due to a malformed EDHOC
+   message) or 5.00 (Internal Server Error) in case of server error
+   (e.g., due to failure in deriving EDHOC keying material).  The
+   Content-Format of the error response MUST be set to "application/
+   edhoc+cbor-seq"; see Section 10.9.
+
+Appendix B.  Compact Representation
+
+   This section defines a format for compact representation based on the
+   Elliptic-Curve-Point-to-Octet-String Conversion defined in
+   Section 2.3.3 of [SECG].
+
+   As described in Section 4.2 of [RFC6090], the x-coordinate of an
+   elliptic curve public key is a suitable representative for the entire
+   point whenever scalar multiplication is used as a one-way function.
+   One example is ECDH with compact output, where only the x-coordinate
+   of the computed value is used as the shared secret.
+
+   In EDHOC, compact representation is used for the ephemeral public
+   keys (G_X and G_Y); see Section 3.7.  Using the notation from [SECG],
+   the output is an octet string of length ceil( (log2 q) / 8 ), where
+   ceil(x) is the smallest integer not less than x.  See [SECG] for a
+   definition of q, M, X, xp, and ~yp.  The steps in Section 2.3.3 of
+   [SECG] are replaced with the following steps:
+
+   1.  Convert the field element xp to an octet string X of length ceil(
+       (log2 q) / 8 ) octets using the conversion routine specified in
+       Section 2.3.5 of [SECG].
+
+   2.  Output M = X.
+
+   The encoding of the point at infinity is not supported.
+
+   Compact representation does not change any requirements on
+   validation; see Section 9.2.  Using compact representation has some
+   security benefits.  An implementation does not need to check that the
+   point is not the point at infinity (the identity element).
+   Similarly, as not even the sign of the y-coordinate is encoded,
+   compact representation trivially avoids so-called "benign
+   malleability" attacks where an attacker changes the sign; see [SECG].
+
+   The following may be needed for validation or compatibility with APIs
+   that do not support compact representation or do not support the full
+   [SECG] format:
+
+   *  If a compressed y-coordinate is required, then the value ~yp set
+      to zero can be used.  In such a case, the compact representation
+      described above can be transformed into the Standards for
+      Efficient Cryptography Group (SECG) point-compressed format by
+      prepending it with the single byte 0x02 (i.e., M = 0x02 || X).
+
+   *  If an uncompressed y-coordinate is required, then a y-coordinate
+      has to be calculated following Section 2.3.4 of [SECG] or
+      Appendix C of [RFC6090].  Any of the square roots (see [SECG] or
+      [RFC6090]) can be used.  The uncompressed SECG format is M =
+      0x04 || X || Y.
+
+   For example: The curve P-256 has the parameters (using the notation
+   in [RFC6090]):
+
+   *  p = 2^256 - 2^224 + 2^192 + 2^96 - 1
+
+   *  a = -3
+
+   *  b = 410583637251521421293261297800472684091144410159937255
+      54835256314039467401291
+
+   Given an example x:
+
+   *  x = 115792089183396302095546807154740558443406795108653336
+      398970697772788799766525
+
+   We can calculate y as the square root w = (x^3 + a ⋅ x + b)^((p +
+   1)/4) (mod p).
+
+   *  y = 834387180070192806820075864918626005281451259964015754
+      16632522940595860276856
+
+   Note that this does not guarantee that (x, y) is on the correct
+   elliptic curve.  A full validation according to Section 5.6.2.3.3 of
+   [SP-800-56A] is done by also checking that 0 ≤ x < p and that y^2 ≡
+   x^3 + a ⋅ x + b (mod p).
+
+Appendix C.  Use of CBOR, CDDL, and COSE in EDHOC
+
+   This appendix is intended to help implementors not familiar with CBOR
+   [RFC8949], CDDL [RFC8610], COSE [RFC9052], and HKDF [RFC5869].
+
+C.1.  CBOR and CDDL
+
+   The Concise Binary Object Representation (CBOR) [RFC8949] is a data
+   format designed for small code size and small message size.  CBOR
+   builds on the JSON data model but extends it by, e.g., encoding
+   binary data directly without base64 conversion.  In addition to the
+   binary CBOR encoding, CBOR also has a diagnostic notation that is
+   readable and editable by humans.  The Concise Data Definition
+   Language (CDDL) [RFC8610] provides a way to express structures for
+   protocol messages and APIs that use CBOR.  [RFC8610] also extends the
+   diagnostic notation.
+
+   CBOR data items are encoded to or decoded from byte strings using a
+   type-length-value encoding scheme, where the three highest order bits
+   of the initial byte contain information about the major type.  CBOR
+   supports several types of data items, integers (int, uint), simple
+   values, byte strings (bstr), and text strings (tstr).  CBOR also
+   supports arrays [] of data items, maps {} of pairs of data items, and
+   sequences [RFC8742] of data items.  Some examples are given below.
+
+   The EDHOC specification sometimes use CDDL names in CBOR diagnostic
+   notation as in, e.g., << ID_CRED_R, ? EAD_2 >>.  This means that
+   EAD_2 is optional and that ID_CRED_R and EAD_2 should be substituted
+   with their values before evaluation.  That is, if ID_CRED_R = { 4 :
+   h'' } and EAD_2 is omitted, then << ID_CRED_R, ? EAD_2 >> = << { 4 :
+   h'' } >>, which encodes to 0x43a10440.  We also make use of the
+   occurrence symbol "*", like in, e.g., 2* int, meaning two or more
+   CBOR integers.
+
+   For a complete specification and more examples, see [RFC8949] and
+   [RFC8610].  We recommend implementors get used to CBOR by using the
+   CBOR playground [CborMe].
+
+          +==================+==============+==================+
+          | Diagnostic       | Encoded      | Type             |
+          +==================+==============+==================+
+          | 1                | 0x01         | unsigned integer |
+          +------------------+--------------+------------------+
+          | 24               | 0x1818       | unsigned integer |
+          +------------------+--------------+------------------+
+          | -24              | 0x37         | negative integer |
+          +------------------+--------------+------------------+
+          | -25              | 0x3818       | negative integer |
+          +------------------+--------------+------------------+
+          | true             | 0xf5         | simple value     |
+          +------------------+--------------+------------------+
+          | h''              | 0x40         | byte string      |
+          +------------------+--------------+------------------+
+          | h'12cd'          | 0x4212cd     | byte string      |
+          +------------------+--------------+------------------+
+          | '12cd'           | 0x4431326364 | byte string      |
+          +------------------+--------------+------------------+
+          | "12cd"           | 0x6431326364 | text string      |
+          +------------------+--------------+------------------+
+          | { 4 : h'cd' }    | 0xa10441cd   | map              |
+          +------------------+--------------+------------------+
+          | << 1, 2, true >> | 0x430102f5   | byte string      |
+          +------------------+--------------+------------------+
+          | [ 1, 2, true ]   | 0x830102f5   | array            |
+          +------------------+--------------+------------------+
+          | ( 1, 2, true )   | 0x0102f5     | sequence         |
+          +------------------+--------------+------------------+
+          | 1, 2, true       | 0x0102f5     | sequence         |
+          +------------------+--------------+------------------+
+
+                Table 15: Examples of Use of CBOR and CDDL
+
+C.2.  CDDL Definitions
+
+   This section compiles the CDDL definitions for ease of reference.
+
+   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_2 = (
+     C_R,
+     ID_CRED_R : map / bstr / -24..23,
+     Signature_or_MAC_2 : bstr,
+     ? EAD_2,
+   )
+
+   message_3 = (
+     CIPHERTEXT_3 : bstr,
+   )
+
+   PLAINTEXT_3 = (
+     ID_CRED_I : map / bstr / -24..23,
+     Signature_or_MAC_3 : bstr,
+     ? EAD_3,
+   )
+
+   message_4 = (
+     CIPHERTEXT_4 : bstr,
+   )
+
+   PLAINTEXT_4 = (
+     ? EAD_4,
+   )
+
+   error = (
+     ERR_CODE : int,
+     ERR_INFO : any,
+   )
+
+   info = (
+     info_label : int,
+     context : bstr,
+     length : uint,
+   )
+
+C.3.  COSE
+
+   CBOR Object Signing and Encryption (COSE) [RFC9052] describes how to
+   create and process signatures, MACs, and encryptions using CBOR.
+   COSE builds on JSON Object Signing and Encryption (JOSE) but is
+   adapted to allow more efficient processing in constrained devices.
+   EDHOC makes use of COSE_Key, COSE_Encrypt0, and COSE_Sign1 objects in
+   the message processing:
+
+   *  ECDH ephemeral public keys of type EC2 or OKP in message_1 and
+      message_2 consist of the COSE_Key parameter named 'x'; see
+      Sections 7.1 and 7.2 of [RFC9053].
+
+   *  The ciphertexts in message_3 and message_4 consist of a subset of
+      the single recipient encrypted data object COSE_Encrypt0, which is
+      described in Sections 5.2 and 5.3 of [RFC9052].  The ciphertext is
+      computed over the plaintext and associated data, using an
+      encryption key and an initialization vector.  The associated data
+      is an Enc_structure consisting of protected headers and externally
+      supplied data (external_aad).  COSE constructs the input to the
+      AEAD [RFC5116] for message_i (i = 3 or 4; see Sections 5.4 and
+      5.5, respectively) as follows:
+
+      -  Secret key K = K_i
+
+      -  Nonce N = IV_i
+
+      -  Plaintext P for message_i
+
+      -  Associated Data A = [ "Encrypt0", h'', TH_i ]
+
+   *  Signatures in message_2 of method 0 and 2, and in message_3 of
+      method 0 and 1, consist of a subset of the single signer data
+      object COSE_Sign1, which is described in Sections 4.2 and 4.4 of
+      [RFC9052].  The signature is computed over a Sig_structure
+      containing payload, protected headers and externally supplied data
+      (external_aad) using a private signature key, and verified using
+      the corresponding public signature key.  For COSE_Sign1, the
+      message to be signed is:
+
+       [ "Signature1", protected, external_aad, payload ]
+
+      where protected, external_aad, and payload are specified in
+      Sections 5.3 and 5.4.
+
+   Different header parameters to identify X.509 or C509 certificates by
+   reference are defined in [RFC9360] and [C509-CERTS]:
+
+   *  by a hash value with the 'x5t' or 'c5t' parameters, respectively:
+
+      -  ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R and
+
+      -  ID_CRED_x = { 22 : COSE_CertHash }, for x = I or R,
+
+   *  or by a URI with the 'x5u' or 'c5u' parameters, respectively:
+
+      -  ID_CRED_x = { 35 : uri }, for x = I or R, and
+
+      -  ID_CRED_x = { 23 : uri }, for x = I or R.
+
+   When ID_CRED_x does not contain the actual credential, it may be very
+   short, e.g., if the endpoints have agreed to use a key identifier
+   parameter 'kid':
+
+   *  ID_CRED_x = { 4 : kid_x }, where kid_x : kid, for x = I or R.  For
+      further optimization, see Section 3.5.3.
+
+   Note that ID_CRED_x can contain several header parameters, for
+   example, { x5u, x5t } or { kid, kid_context }.
+
+   ID_CRED_x MAY also identify the credential by value.  For example, a
+   certificate chain can be transported in an ID_CRED field with COSE
+   header parameter c5c or x5chain, as defined in [C509-CERTS] and
+   [RFC9360].  Credentials of type CWT and CCS can be transported with
+   the COSE header parameters registered in Section 10.6.
+
+Appendix D.  Authentication-Related Verifications
+
+   EDHOC performs certain authentication-related operations (see
+   Section 3.5), but in general, it is necessary to make additional
+   verifications beyond EDHOC message processing.  Which verifications
+   that are needed depend on the deployment, in particular, the trust
+   model and the security policies, but most commonly, it can be
+   expressed in terms of verifications of credential content.
+
+   EDHOC assumes the existence of mechanisms (certification authority or
+   other trusted third party, pre-provisioning, etc.) for generating and
+   distributing authentication credentials and other credentials, as
+   well as the existence of trust anchors (CA certificates, trusted
+   public keys, etc.).  For example, a public key certificate or CWT may
+   rely on a trusted third party whose public key is pre-provisioned,
+   whereas a CCS or a self-signed certificate / CWT may be used when
+   trust in the public key can be achieved by other means, or in the
+   case of trust on first use, see Appendix D.5.
+
+   In this section, we provide some examples of such verifications.
+   These verifications are the responsibility of the application but may
+   be implemented as part of an EDHOC library.
+
+D.1.  Validating the Authentication Credential
+
+   In addition to the authentication key, the authentication credential
+   may contain other parameters that need to be verified.  For example:
+
+   *  In X.509 and C509 certificates, signature keys typically have key
+      usage "digitalSignature", and Diffie-Hellman public keys typically
+      have key usage "keyAgreement" [RFC3279] [RFC8410].
+
+   *  In X.509 and C509 certificates, validity is expressed using Not
+      After and Not Before.  In CWT and CCS, the "exp" and "nbf" claims
+      have similar meanings.
+
+D.2.  Identities
+
+   The application must decide on allowing a connection or not,
+   depending on the intended endpoint, and in particular whether it is a
+   specific identity or in a set of identities.  To prevent misbinding
+   attacks, the identity of the endpoint is included in a MAC verified
+   through the protocol.  More details and examples are provided in this
+   section.
+
+   Policies for what connections to allow are typically set based on the
+   identity of the other endpoint, and endpoints typically only allow
+   connections from a specific identity or a small restricted set of
+   identities.  For example, in the case of a device connecting to a
+   network, the network may only allow connections from devices that
+   authenticate with certificates having a particular range of serial
+   numbers and signed by a particular CA.  Conversely, a device may only
+   be allowed to connect to a network that authenticates with a
+   particular public key.
+
+   *  When a Public Key Infrastructure (PKI) is used with certificates,
+      the identity is the subject whose unique name, e.g., a domain
+      name, a Network Access Identifier (NAI), or an Extended Unique
+      Identifier (EUI), is included in the endpoint's certificate.
+
+   *  Similarly, when a PKI is used with CWTs, the identity is the
+      subject identified by the relevant claim(s), such as 'sub'
+      (subject).
+
+   *  When PKI is not used (e.g., CCS, self-signed certificate / CWT),
+      the identity is typically directly associated with the
+      authentication key of the other party.  For example, if identities
+      can be expressed in the form of unique subject names assigned to
+      public keys, then a binding to identity is achieved by including
+      both the public key and associated subject name in the
+      authentication credential.  CRED_I or CRED_R may be a self-signed
+      certificate / CWT or CCS containing the authentication key and the
+      subject name; see Section 3.5.2.  Thus, each endpoint needs to
+      know the specific authentication key / unique associated subject
+      name or set of public authentication keys / unique associated
+      subject names, which it is allowed to communicate with.
+
+   To prevent misbinding attacks in systems where an attacker can
+   register public keys without proving knowledge of the private key,
+   SIGMA [SIGMA] enforces a MAC to be calculated over the "identity".
+   EDHOC follows SIGMA by calculating a MAC over the whole
+   authentication credential, which in case of an X.509 or C509
+   certificate, includes the "subject" and "subjectAltName" fields and,
+   in the case of CWT or CCS, includes the "sub" claim.
+
+   (While the SIGMA paper only focuses on the identity, the same
+   principle is true for other information such as policies associated
+   with the public key.)
+
+D.3.  Certification Path and Trust Anchors
+
+   When a Public Key Infrastructure (PKI) is used with certificates, the
+   trust anchor is a certification authority (CA) certificate.  Each
+   party needs at least one CA public key certificate or just the CA
+   public key.  The certification path contains proof that the subject
+   of the certificate owns the public key in the certificate.  Only
+   validated public key certificates are to be accepted.
+
+   Similarly, when a PKI is used with CWTs, each party needs to have at
+   least one trusted third-party public key as a trust anchor to verify
+   the end entity CWTs.  The trusted third-party public key can, e.g.,
+   be stored in a self-signed CWT or in a CCS.
+
+   The signature of the authentication credential needs to be verified
+   with the public key of the issuer.  X.509 and C509 certificates
+   includes the "Issuer" field.  In CWT and CCS, the "iss" claim has a
+   similar meaning.  The public key is either a trust anchor or the
+   public key in another valid and trusted credential in a certification
+   path from the trust anchor to the authentication credential.
+
+   Similar verifications as made with the authentication credential (see
+   Appendix D.1) are also needed for the other credentials in the
+   certification path.
+
+   When PKI is not used (CCS and self-signed certificate / CWT), the
+   trust anchor is the authentication key of the other party; in which
+   case, there is no certification path.
+
+D.4.  Revocation Status
+
+   The application may need to verify that the credentials are not
+   revoked; see Section 9.8.  Some use cases may be served by short-
+   lived credentials, for example, where the validity of the credential
+   is on par with the interval between revocation checks.  But, in
+   general, credential lifetime and revocation checking are
+   complementary measures to control credential status.  Revocation
+   information may be transported as External Authorization Data (EAD);
+   see Appendix E.
+
+D.5.  Unauthenticated Operation
+
+   EDHOC might be used without authentication by allowing the Initiator
+   or Responder to communicate with any identity except its own.  Note
+   that EDHOC without mutual authentication is vulnerable to active on-
+   path attacks and therefore unsafe for general use.  However, it is
+   possible to later establish a trust relationship with an unknown or
+   not-yet-trusted endpoint.  Some examples are listed below:
+
+   *  The EDHOC authentication credential can be verified out-of-band at
+      a later stage.
+
+   *  The EDHOC session key can be bound to an identity out-of-band at a
+      later stage.
+
+   *  Trust on first use (TOFU) can be used to verify that several EDHOC
+      connections are made to the same identity.  TOFU combined with
+      proximity is a common IoT deployment model that provides good
+      security if done correctly.  Note that secure proximity based on
+      short range wireless technology requires very low signal strength
+      or very low latency.
+
+Appendix E.  Use of External Authorization Data
+
+   In order to reduce the number of messages and round trips, or to
+   simplify processing, external security applications may be integrated
+   into EDHOC by transporting related external authorization data (EAD)
+   in the messages.
+
+   The EAD format is specified in Section 3.8.  This section contains
+   examples and further details of how EAD may be used with an
+   appropriate accompanying specification.
+
+   *  One example is third-party-assisted authorization, requested with
+      EAD_1, and an authorization artifact ("voucher", cf. [RFC8366])
+      returned in EAD_2; see [LAKE-AUTHZ].
+
+   *  Another example is remote attestation, requested in EAD_2, and an
+      Entity Attestation Token (EAT) [EAT] returned in EAD_3.
+
+   *  A third example is certificate enrollment, where a Certificate
+      Signing Request (CSR) [RFC2986] is included in EAD_3, and the
+      issued public key certificate (X.509 [RFC5280] and C509
+      [C509-CERTS]) or a reference thereof is returned in EAD_4.
+
+   External authorization data should be considered unprotected by
+   EDHOC, and the protection of EAD is the responsibility of the
+   security application (third-party authorization, remote attestation,
+   certificate enrollment, etc.).  The security properties of the EAD
+   fields (after EDHOC processing) are discussed in Section 9.1.
+
+   The content of the EAD field may be used in the EDHOC processing of
+   the message in which they are contained.  For example,
+   authentication-related information, like assertions and revocation
+   information, transported in EAD fields may provide input about trust
+   anchors or validity of credentials relevant to the authentication
+   processing.  The EAD fields (like ID_CRED fields) are therefore made
+   available to the application before the message is verified; see
+   details of message processing in Section 5.  In the first example
+   above, a voucher in EAD_2 made available to the application can
+   enable the Initiator to verify the identity or the public key of the
+   Responder before verifying the signature.  An application allowing
+   EAD fields containing authentication information thus may need to
+   handle authentication-related verifications associated with EAD
+   processing.
+
+   Conversely, the security application may need to wait for EDHOC
+   message verification to complete.  In the third example above, the
+   validation of a CSR carried in EAD_3 is not started by the Responder
+   before EDHOC has successfully verified message_3 and proven the
+   possession of the private key of the Initiator.
+
+   The security application may reuse EDHOC protocol fields that
+   therefore need to be available to the application.  For example, the
+   security application may use the same crypto algorithms as in the
+   EDHOC session and therefore needs access to the selected cipher suite
+   (or the whole SUITES_I).  The application may use the ephemeral
+   public keys G_X and G_Y as ephemeral keys or as nonces; see
+   [LAKE-AUTHZ].
+
+   The processing of the EAD item (ead_label, ? ead_value) by the
+   security application needs to be described in the specification where
+   the ead_label is registered (see Section 10.5), including the
+   optional ead_value for each message and actions in case of errors.
+   An application may support multiple security applications that make
+   use of EAD, which may result in multiple EAD items in one EAD field;
+   see Section 3.8.  Any dependencies on security applications with
+   previously registered EAD items need to be documented, and the
+   processing needs to consider their simultaneous use.
+
+   Since data carried in EAD may not be protected, or processed by the
+   application before the EDHOC message is verified, special
+   considerations need to be made such that it does not violate security
+   and privacy requirements of the service that uses this data; see
+   Section 9.5.  The content in an EAD item may impact the security
+   properties provided by EDHOC.  Security applications making use of
+   the EAD items must perform the necessary security analysis.
+
+Appendix F.  Application Profile Example
+
+   This appendix contains a rudimentary example of an application
+   profile; see Section 3.9.
+
+   For use of EDHOC with application X, the following assumptions are
+   made:
+
+   1.  Transfer in CoAP as specified in Appendix A.2 with requests
+       expected by the CoAP server (= Responder) at /app1-edh, no
+       Content-Format needed.
+
+   2.  METHOD = 1 (I uses signature key; R uses static DH key.)
+
+   3.  CRED_I is an IEEE 802.1AR Initial Device Identifier (IDevID)
+       encoded as a C509 certificate of type 0 [C509-CERTS].
+
+       *  R acquires CRED_I out-of-band, indicated in EAD_1.
+
+       *  ID_CRED_I = {4: h''} is a 'kid' with the value of the empty
+          CBOR byte string.
+
+   4.  CRED_R is a CCS of type OKP as specified in Section 3.5.2.
+
+       *  The CBOR map has parameters 1 (kty), -1 (crv), and -2
+          (x-coordinate).
+
+       *  ID_CRED_R is {14 : CCS}.
+
+   5.  External authorization data is defined and processed as specified
+       in [LAKE-AUTHZ].
+
+   6.  EUI-64 is used as the identity of the endpoint (see an example in
+       Section 3.5.2).
+
+   7.  No use of message_4.  The application sends protected messages
+       from R to I.
+
+Appendix G.  Long PLAINTEXT_2
+
+   By the definition of encryption of PLAINTEXT_2 with KEYSTREAM_2, it
+   is limited to lengths of PLAINTEXT_2 not exceeding the output of
+   EDHOC_KDF; see Section 4.1.2.  If the EDHOC hash algorithm is SHA-2,
+   then HKDF-Expand is used, which limits the length of the EDHOC_KDF
+   output to 255 ⋅ hash_length, where hash_length is the length of the
+   output of the EDHOC hash algorithm given by the cipher suite.  For
+   example, with SHA-256 as the EDHOC hash algorithm, the length of the
+   hash output is 32 bytes and the maximum length of PLAINTEXT_2 is 255
+   ⋅ 32 = 8160 bytes.
+
+   While PLAINTEXT_2 is expected to be much shorter than 8 kB for the
+   intended use cases, it seems nevertheless prudent to specify a
+   solution for the event that this should turn out to be a limitation.
+
+   A potential work-around is to use a cipher suite with a different
+   hash function.  In particular, the use of KMAC removes all practical
+   limitations in this respect.
+
+   This section specifies a solution that works with any hash function
+   by making use of multiple invocations of HKDF-Expand and negative
+   values of info_label.
+
+   Consider the PLAINTEXT_2 partitioned in parts P(i) of length equal to
+   M = 255 ⋅ hash_length, except possibly the last part P(last), which
+   has 0 < length ≤ M.
+
+   PLAINTEXT_2 = P(0) | P(1) | ... | P(last)
+
+   where "|" indicates concatenation.
+
+   The object is to define a matching KEYSTREAM_2 of the same length and
+   perform the encryption in the same way as defined in Section 5.3.2:
+
+   CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2
+
+   Define the keystream as:
+
+   KEYSTREAM_2 = OKM(0) | OKM(1)  | ... | OKM(last)
+
+   where:
+
+   OKM(i) = EDHOC_KDF( PRK_2e, -i, TH_2, length(P(i)) )
+
+   Note that if length(PLAINTEXT_2) ≤ M, then P(0) = PLAINTEXT_2 and the
+   definition of KEYSTREAM_2 = OKM(0) coincides with Figure 6.
+
+   This describes the processing of the Responder when sending
+   message_2.  The Initiator makes the same calculations when receiving
+   message_2 but interchanging PLAINTEXT_2 and CIPHERTEXT_2.
+
+   An application profile may specify if it supports or does not support
+   the method described in this appendix.
+
+Appendix H.  EDHOC_KeyUpdate
+
+   To provide forward secrecy in an even more efficient way than re-
+   running EDHOC, this section specifies the optional function
+   EDHOC_KeyUpdate in terms of EDHOC_KDF and PRK_out.
+
+   When EDHOC_KeyUpdate is called, a new PRK_out is calculated as the
+   output of the EDHOC_Expand function with the old PRK_out as input.
+   The change of PRK_out causes a change to PRK_exporter, which enables
+   the derivation of new application keys superseding the old ones,
+   using EDHOC_Exporter; see Section 4.2.1.  The process is illustrated
+   by the following pseudocode.
+
+   EDHOC_KeyUpdate( context ):
+      new PRK_out = EDHOC_KDF( old PRK_out, 11, context, hash_length )
+      new PRK_exporter = EDHOC_KDF( new PRK_out, 10, h'', hash_length )
+
+   where hash_length denotes the output size in bytes of the EDHOC hash
+   algorithm of the selected cipher suite.
+
+   The EDHOC_KeyUpdate takes a context as input to enable binding of the
+   updated PRK_out to some event that triggered the key update.  The
+   Initiator and Responder need to agree on the context, which can,
+   e.g., be a counter, a pseudorandom number, or a hash.  To provide
+   forward secrecy, the old PRK_out and keys derived from it (old
+   PRK_exporter and old application keys) must be deleted as soon as
+   they are not needed.  When to delete the old keys and how to verify
+   that they are not needed is up to the application.  Note that the
+   security properties depend on the type of context and the number of
+   KeyUpdate iterations.
+
+   An application using EDHOC_KeyUpdate needs to store PRK_out.
+   Compromise of PRK_out leads to compromise of all keying material
+   derived with the EDHOC_Exporter since the last invocation of the
+   EDHOC_KeyUpdate function.
+
+   While this key update method provides forward secrecy, it does not
+   give as strong security properties as re-running EDHOC.
+   EDHOC_KeyUpdate can be used to meet cryptographic limits and provide
+   partial protection against key leakage, but it provides significantly
+   weaker security properties than re-running EDHOC with ephemeral
+   Diffie-Hellman.  Even with frequent use of EDHOC_KeyUpdate,
+   compromise of one session key compromises all future session keys,
+   and an attacker therefore only needs to perform static key
+   exfiltration [RFC7624], which is less complicated and has a lower
+   risk profile than the dynamic case; see Section 9.1.
+
+   A similar method to do a key update for OSCORE is KUDOS; see [KUDOS].
+
+Appendix I.  Example Protocol State Machine
+
+   This appendix describes an example protocol state machine for the
+   Initiator and Responder.  States are denoted in all capitals, and
+   parentheses denote actions taken only in some circumstances.
+
+   Note that this state machine is just an example, and that details of
+   processing are omitted.  For example:
+
+   *  when error messages are being sent (with one exception);
+
+   *  how credentials and EAD are processed by EDHOC and the application
+      in the RCVD state; and
+
+   *  what verifications are made, which includes not only MACs and
+      signatures.
+
+I.1.  Initiator State Machine
+
+   The Initiator sends message_1, triggering the state machine to
+   transition from START to WAIT_M2, and waits for message_2.
+
+   If the incoming message is an error message, then the Initiator
+   transitions from WAIT_M2 to ABORTED.  In case of error code 2 (Wrong
+   Selected Cipher Suite), the Initiator remembers the supported cipher
+   suites for this particular Responder and transitions from ABORTED to
+   START.  The message_1 that the Initiator subsequently sends takes
+   into account the cipher suites supported by the Responder.
+
+   Upon receiving a non-error message, the Initiator transitions from
+   WAIT_M2 to RCVD_M2 and processes the message.  If a processing error
+   occurs on message_2, then the Initiator transitions from RCVD_M2 to
+   ABORTED.  In case of successful processing of message_2, the
+   Initiator transitions from RCVD_M2 to VRFD_M2.
+
+   The Initiator prepares and processes message_3 for sending.  If any
+   processing error is encountered, the Initiator transitions from
+   VRFD_M2 to ABORTED.  If message_3 is successfully sent, the Initiator
+   transitions from VRFD_M2 to COMPLETED.
+
+   If the application profile includes message_4, then the Initiator
+   waits for message_4.  If the incoming message is an error message,
+   then the Initiator transitions from COMPLETED to ABORTED.  Upon
+   receiving a non-error message, the Initiator transitions from
+   COMPLETED (="WAIT_M4") to RCVD_M4 and processes the message.  If a
+   processing error occurs on message_4, then the Initiator transitions
+   from RCVD_M4 to ABORTED.  In case of successful processing of
+   message_4, the Initiator transitions from RCVD_M4 to PERSISTED
+   (="VRFD_M4").
+
+   If the application profile does not include message_4, then the
+   Initiator waits for an incoming application message.  If the
+   decryption and verification of the application message is successful,
+   then the Initiator transitions from COMPLETED to PERSISTED.
+
+        +- - - - - - - - - -> START
+        |                       |
+                                | Send message_1
+        |                       |
+              Receive error     v
+    ABORTED <---------------- WAIT_M2
+        ^                       |
+        |                       | Receive message_2
+        |                       |
+        |    Processing error   v
+        +-------------------- RCVD_M2
+        ^                       |
+        |                       | Verify message_2
+        |                       |
+        |    Processing error   v
+        +-------------------- VRFD_M2
+        ^                       |
+        |                       | Send message_3
+        |                       |
+        |    (Receive error)    v
+        +-------------------- COMPLETED ----------------+
+        ^                       |                       |
+        |                       | (Receive message_4)   |
+        |                       |                       |
+        |   (Processing error)  v                       | (Verify
+        +------------------- (RCVD_M4)                  |  application
+                                |                       |  message)
+                                | (Verify message_4)    |
+                                |                       |
+                                v                       |
+                              PERSISTED <---------------+
+
+                     Figure 12: Initiator State Machine
+
+I.2.  Responder State Machine
+
+   Upon receiving message_1, the Responder transitions from START to
+   RCVD_M1.
+
+   If a processing error occurs on message_1, the Responder transitions
+   from RCVD_M1 to ABORTED.  This includes sending an error message with
+   error code 2 (Wrong Selected Cipher Suite) if the selected cipher
+   suite in message_1 is not supported.  In case of successful
+   processing of message_1, the Responder transitions from RCVD_M1 to
+   VRFD_M1.
+
+   The Responder prepares and processes message_2 for sending.  If any
+   processing error is encountered, the Responder transitions from
+   VRFD_M1 to ABORTED.  If message_2 is successfully sent, the Initiator
+   transitions from VRFD_M2 to WAIT_M3 and waits for message_3.
+
+   If the incoming message is an error message, then the Responder
+   transitions from WAIT_M3 to ABORTED.
+
+   Upon receiving message_3, the Responder transitions from WAIT_M3 to
+   RCVD_M3.  If a processing error occurs on message_3, the Responder
+   transitions from RCVD_M3 to ABORTED.  In case of successful
+   processing of message_3, the Responder transitions from RCVD_M3 to
+   COMPLETED (="VRFD_M3").
+
+   If the application profile includes message_4, the Responder prepares
+   and processes message_4 for sending.  If any processing error is
+   encountered, the Responder transitions from COMPLETED to ABORTED.
+
+   If message_4 is successfully sent, or if the application profile does
+   not include message_4, the Responder transitions from COMPLETED to
+   PERSISTED.
+
+                                        START
+                                          |
+                                          | Receive message_1
+                                          |
+                       Processing error   v
+              ABORTED <---------------- RCVD_M1
+                  ^                       |
+                  |                       | Verify message_1
+                  |                       |
+                  |    Processing error   v
+                  +-------------------- VRFD_M1
+                  ^                       |
+                  |                       | Send message_2
+                  |                       |
+                  |     Receive error     v
+                  +-------------------- WAIT_M3
+                  ^                       |
+                  |                       | Receive message_3
+                  |                       |
+                  |    Processing error   v
+                  +-------------------- RCVD_M3
+                  ^                       |
+                  |                       | Verify message_3
+                  |                       |
+                  |   (Processing error)  v
+                  +------------------- COMPLETED
+                                          |
+                                          | (Send message_4)
+                                          |
+                                          v
+                                       PERSISTED
+
+                     Figure 13: Responder State Machine
+
+Acknowledgments
+
+   The authors want to thank Christian Amsüss, Karthikeyan Bhargavan,
+   Carsten Bormann, Alessandro Bruni, Timothy Claeys, Baptiste Cottier,
+   Roman Danyliw, Martin Disch, Martin Duke, Donald Eastlake 3rd, Lars
+   Eggert, Stephen Farrell, Loïc Ferreira, Theis Grønbech Petersen,
+   Felix Günther, Dan Harkins, Klaus Hartke, Russ Housley, Stefan
+   Hristozov, Marc Ilunga, Charlie Jacomme, Elise Klein, Erik Kline,
+   Steve Kremer, Alexandros Krontiris, Ilari Liusvaara, Rafa Marín-
+   López, Kathleen Moriarty, David Navarro, Karl Norrman, Salvador
+   Pérez, Radia Perlman, David Pointcheval, Maïwenn Racouchot, Eric
+   Rescorla, Michael Richardson, Thorvald Sahl Jørgensen, Zaheduzzaman
+   Sarker, Jim Schaad, Michael Scharf, Carsten Schürmann, John Scudder,
+   Ludwig Seitz, Brian Sipos, Stanislav Smyshlyaev, Valery Smyslov,
+   Peter van der Stok, Rene Struik, Vaishnavi Sundararajan, Erik
+   Thormarker, Marco Tiloca, Sean Turner, Michel Veillette, Mališa
+   Vučinić, Paul Wouters, and Lei Yan for reviewing and commenting on
+   intermediate draft versions of this document.
+
+   We are especially indebted to the late Jim Schaad for his continuous
+   review and implementation of draft versions of this document, as well
+   as his work on other technologies such as COSE and OSCORE without
+   which EDHOC would not have been.
+
+   Work on this document has in part been supported by the H2020 project
+   SIFIS-Home (grant agreement 952652).
+
+Authors' Addresses
+
+   Göran Selander
+   Ericsson AB
+   SE-164 80 Stockholm
+   Sweden
+   Email: goran.selander@ericsson.com
+
+
+   John Preuß Mattsson
+   Ericsson AB
+   SE-164 80 Stockholm
+   Sweden
+   Email: john.mattsson@ericsson.com
+
+
+   Francesca Palombini
+   Ericsson AB
+   SE-164 80 Stockholm
+   Sweden
+   Email: francesca.palombini@ericsson.com