Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC)

1.1. Terminology

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

The reader is expected to be familiar with terms and concepts defined in EDHOC [RFC9528], and with the use of EDHOC with CoAP [RFC7252] and OSCORE [RFC8613] defined in [RFC9668].¶

Concise Binary Object Representation (CBOR) [RFC8949] and Concise Data Definition Language (CDDL) [RFC8610] are used in this document. CDDL predefined type names, especially bstr for CBOR byte strings and tstr for CBOR text strings, are used extensively in this document.¶

CBOR data items are represented using the CBOR extended diagnostic notation as defined in Section 8 of [RFC8949] and Appendix G of [RFC8610] ("diagnostic notation"). Diagnostic notation comments are used to provide a textual representation of the parameters' keys and values.¶

In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in Figure 6 of Appendix A. For example, {e'methods' : [0, 1, 2, 3], e'cipher_suites': 3} stands for {1 : [0, 1, 2, 3], 2 : 3}.¶

Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL model shown in Figure 6 of Appendix A. Finally, please delete this note.¶

3.1. In Web Linking

Section 6 of [RFC9668] defines a number of target attributes that can be used in a web link [RFC8288] with resource type "core.edhoc" (see Section 10.10 of [RFC9528]). This is the case, e.g., when using a link-format document [RFC6690] describing EDHOC resources at a server, when EDHOC is transferred over CoAP [RFC7252] as defined in Appendix A.2 of [RFC9528]. This allows a client to obtain relevant information about the EDHOC application profile(s) to be used with a certain EDHOC resource.¶

In the same spirit, this section defines the following additional parameter, which can be optionally specified as a target attribute with the same name in the link to the respective EDHOC resource, or among the filter criteria in a discovery request from a client.¶

• 'ed-prof', specifying an EDHOC application profile supported by the server. This parameter MUST specify a single value, which is taken from the 'Profile ID' column of the "EDHOC Application Profiles" registry defined in Section 10.8 of this document. This parameter MAY occur multiple times, with each occurrence specifying an EDHOC application profile.¶

When specifying the parameter 'ed-prof' in a link to an EDHOC resource, the target attribute rt="core.edhoc" MUST be included.¶

If a link to an EDHOC resource includes occurrences of the target attribute 'ed-prof', then the following applies.¶

• The link MUST NOT include other target attributes that provide information about an EDHOC application profile (see, e.g., Section 6 of [RFC9668] and Section 4 of this document), with the exception of the target attribute 'ed-ead' that MAY be included.¶

  The recipient MUST ignore other target attributes that provide information about an EDHOC application profile, with the exception of the target attribute 'ed-ead'.¶

• If the link includes occurrences of the target attribute 'ed-ead', the link provides the following information: when using the target EDHOC resource as per the EDHOC application profile indicated by any occurrence of the target attribute 'ed-prof', the server supports the External Authorization Data (EAD) items that are specified in the definition of that EDHOC application profile, as well as the EAD items indicated by the occurrences of the target attribute 'ed-ead'.¶

The example in Figure 2 shows how a CoAP client discovers two EDHOC resources at a CoAP server, and obtains information about the application profile corresponding to each of those resources. The Link Format notation from Section 5 of [RFC6690] is used.¶

The example assumes the existence of an EDHOC application profile identified by the integer Profile ID 500, which is supported by the EDHOC resource at /edhoc-alt and whose definition includes the support for the EAD items with EAD label 111 and 222.¶

Therefore, the link to the EDHOC resource at /edhoc-alt indicates that, when using that EDHOC resource as per the EDHOC application profile with Profile ID 500, the server supports the EAD items with EAD label 111, 222, and 333.¶

REQ: GET /.well-known/core

RES: 2.05 Content
    </sensors/temp>;osc,
    </sensors/light>;if=sensor,
    </.well-known/edhoc>;rt=core.edhoc;ed-csuite=0;ed-csuite=2;
        ed-method=0;ed-cred-t=1;ed-cred-t=3;ed-idcred-t=4;
        ed-i;ed-r;ed-comb-req,
    </edhoc-alt>;rt=core.edhoc;ed-prof=500;ed-ead=333

3.2. In the EDHOC_Information Object

Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile] defines the EDHOC_Information object, as including information that guides two peers towards executing the EDHOC protocol, and defines an initial set of its parameters.¶

This document defines the new parameter "app_prof" of the EDHOC_Information object, as summarized in Table 1 and described further below.¶

• app_prof: This parameter specifies a set of supported EDHOC application profiles, identified by their Profile ID. If the set is composed of a single EDHOC application profile, its Profile ID is encoded as an integer. Otherwise, the set is encoded as an array of integers, where each array element encodes one Profile ID. In JSON, the "app_prof" value is an integer or an array of integers. In CBOR, "app_prof" is an integer or an array of integers, and has label 23. The integer values are taken from the 'Profile ID' column of the "EDHOC Application Profiles" registry defined in Section 10.8 of this document.¶

5.1. In EDHOC Message 1 and Message 2

This section defines the EDHOC EAD item "Supported EDHOC application profiles", which is registered in Section 10.5 of this document.¶

The EAD item MAY be included:¶

• In the EAD_1 field of EDHOC message_1, in order to specify EDHOC application profiles supported by the Initiator.¶

• In the EAD_2 field of EDHOC message_2, in order to specify EDHOC application profiles supported by the Responder.¶

When the EAD item is present, its ead_label TBD_EAD_LABEL MUST be used only with negative sign, i.e., the use of the EAD item is always critical (see Section 3.8 of [RFC9528]).¶

The EAD item MUST NOT occur more than once in the EAD fields of EDHOC message_1 or message_2. The recipient peer MUST abort the EDHOC session and MUST reply with an EDHOC error message if the EAD item occurs multiple times in the EAD fields of EDHOC message_1 or message_2.¶

The EAD item MUST NOT be included in the EAD fields of EDHOC message_3 or message_4. In case the recipient peer supports the EAD item, the recipient peer MUST silently ignore the EAD item if this is included in the EAD fields of EDHOC message_3 or message_4.¶

The EAD item MUST specify an ead_value, as a CBOR byte string with value the binary representation of a CBOR sequence [RFC8742], namely APP_PROF_SEQ. The CBOR sequence is composed of one or more items, whose order has no meaning.¶

Each item of the CBOR sequence MUST be either of the following:¶

• A CBOR integer, specifying the Profile ID of an EDHOC application profile. The integer value is taken from the 'Profile ID' column of the "EDHOC Application Profiles" registry defined in Section 10.8 of this document.¶

  This item of the CBOR sequence indicates that the message sender supports the EDHOC application profile identified by the Profile ID.¶

• A CBOR array including at least one element. In particular:¶

  • The first element MUST be a CBOR integer, specifying the Profile ID of an EDHOC application profile. The integer value is taken from the 'Profile ID' column of the "EDHOC Application Profiles" registry.¶

  • Each of the elements following the first one MUST be a CBOR unsigned integer, specifying the ead_label of an EAD item.¶

  This item of the CBOR sequence indicates that the message sender supports:¶

  • The EDHOC application profile PROFILE identified by the Profile ID in the first element of the array; and¶

  • The EAD items identified by the ead_label in the elements following the first one, in addition to the EAD items that are specified in the definition of the EDHOC application profile PROFILE.¶

• An EDHOC_Information object encoded in CBOR, i.e., as a CBOR map (see Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile]).¶

  The EDHOC_Information object MUST NOT include the element "app_prof" and MUST NOT include elements that are not allowed within the EDHOC_Application_Profile object defined in Section 2, with the exception of the element "trust_anchor" that MAY be included. The recipient peer MUST ignore elements that are not allowed if they are present in the EDHOC_Information object.¶

  This item of the CBOR sequence indicates that the message sender supports an EDHOC application profile consistent with the pieces of information specified by the EDHOC_Information object.¶

When composing ead_value, the sender peer MUST comply with the content restrictions specified in Section 5.1.1.¶

The recipient peer MUST abort the EDHOC session and MUST reply with an EDHOC error message if ead_value is malformed or does not conform with the format defined above.¶

The CDDL grammar describing ead_value for the EAD item "Supported EDHOC application profiles" is shown in Figure 3.¶

ead_value = << APP_PROF_SEQ >>

; This defines an array, the elements of which
; are to be used in the CBOR Sequence APP_PROF_SEQ:
APP_PROF_SEQ = [1* element]

element = profile_id / profile_id_with_eads / EDHOC_Information

profile_id = int

profile_id_with_eads = [profile_id, 1* uint]

; The full definition is provided in
; draft-ietf-ace-edhoc-oscore-profile
EDHOC_Information : map

5.2. In the EDHOC Error Message

This section defines the error code TBD_ERROR_CODE, which is registered in Section 10.6 of this document.¶

Error code TBD_ERROR_CODE MUST only be used when replying to EDHOC message_1. If an EDHOC error message with error code TBD_ERROR_CODE is received as reply to an EDHOC message different from EDHOC message_1, then the recipient of the error message MUST ignore what is specified in ERR_INFO.¶

The Responder MUST NOT abort an EDHOC session exclusively due to the wish of sending an error message with error code TBD_ERROR_CODE. Instead, the Responder can advertise the EDHOC application profiles that it supports to the Initiator by means of the EAD item "Supported EDHOC application profiles" defined in Section 5.1, specifying it in the EAD_2 field of the EDHOC message_2 to send in the EDHOC session.¶

When replying to an EDHOC message_1 with an error message, the Responder has to consider the reason for which it is aborting the EDHOC session and MUST NOT specify error code TBD_ERROR_CODE if a different, more appropriate error code can be specified instead. For example, if the negotiation of the selected cipher suite fails (see Section 6.3 of [RFC9528]), the error message MUST NOT specify error code TBD_ERROR_CODE, since the error message intended to be used in that case specifies error code 2 (Wrong selected cipher suite) and conveys SUITES_R as ERR_INFO.¶

When using error code TBD_ERROR_CODE, the error information specified in ERR_INFO MUST be a CBOR byte string with value the binary representation of a CBOR sequence APP_PROF_SEQ. This CBOR sequence has the same format and semantics of the one used for ead_value of the EAD item "Supported EDHOC application profiles" (see Section 5.1).¶

The recipient peer MUST silently ignore elements of the CBOR sequence APP_PROF_SEQ that are malformed or do not conform with the intended format.¶

7.1. Well-Known Application Profile MINIMAL_CS_2

{
        e'methods' : 3, / EDHOC Method Type 3 /
  e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
     e'cred_types' : 1, / CWT Claims Set (CCS) /
  e'id_cred_types' : 4, / kid /
       e'app_prof' : e'APP-PROF-MINIMAL-CS-2'
}

This application profile is aligned with the example trace of EDHOC compiled in Section 3 of [RFC9529].¶

7.2. Well-Known Application Profile MINIMAL_CS_0

{
        e'methods' : 3, / EDHOC Method Type 3 /
  e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
     e'cred_types' : 1, / CWT Claims Set (CCS) /
  e'id_cred_types' : 4, / kid /
       e'app_prof' : e'APP-PROF-MINIMAL-CS-0'
}

7.3. Well-Known Application Profile BASIC_CS_2_X509

{
        e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
  e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
     e'cred_types' : [1, 2], / CWT Claims Set (CCS)
                             and X.509 certificate /
  e'id_cred_types' : [4, 34], / kid and x5t /
       e'app_prof' : e'APP-PROF-BASIC-CS-2-X509'
}

This application profile is aligned with the example trace of EDHOC compiled in Section 3 of [RFC9529].¶

7.4. Well-Known Application Profile BASIC_CS_0_X509

{
        e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
  e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
     e'cred_types' : [1, 2], / CWT Claims Set (CCS)
                             and X.509 certificate /
  e'id_cred_types' : [4, 34], / kid and x5t /
       e'app_prof' : e'APP-PROF-BASIC-CS-0-X509'
}

This application profile is aligned with the example trace of EDHOC compiled in Section 2 of [RFC9529].¶

7.5. Well-Known Application Profile BASIC_CS_2_C509

{
        e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
  e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
     e'cred_types' : [1, e'c509_cert'], / CWT Claims Set (CCS)
                                        and C509 certificate /
  e'id_cred_types' : [4, e'c5t'], / kid and c5t /
       e'app_prof' : e'APP-PROF-BASIC-CS-2-C509'
}

7.6. Well-Known Application Profile BASIC_CS_0_C509

{
        e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
  e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
     e'cred_types' : [1, e'c509_cert'], / CWT Claims Set (CCS)
                                        and C509 certificate /
  e'id_cred_types' : [4, e'c5t'], / kid and c5t /
       e'app_prof' : e'APP-PROF-BASIC-CS-0-C509'
}

7.7. Well-Known Application Profile INTERMEDIATE_CS_2

{
        e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
  e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
     e'cred_types' : [1, 2, e'c509_cert'], / CWT Claims Set (CCS),
                                           X.509 certificate,
                                           and C509 certificate /
  e'id_cred_types' : [4, 14, 34, 33, e'c5t', e'c5c'], / kid, kccs,
                                                      x5t, x5chain,
                                                      c5t, and c5c /
       e'app_prof' : e'APP-PROF-INTERMEDIATE-CS-2'
}

This application profile is aligned with the example trace of EDHOC compiled in Section 3 of [RFC9529].¶

7.8. Well-Known Application Profile INTERMEDIATE_CS_0

{
        e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
  e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
     e'cred_types' : [1, 2, e'c509_cert'], / CWT Claims Set (CCS),
                                             X.509 certificate,
                                             and C509 certificate /
  e'id_cred_types' : [4, 14, 34, 33, e'c5t', e'c5c'], / kid, kccs,
                                                      x5t, x5chain,
                                                      c5t, and c5c /
       e'app_prof' : e'APP-PROF-INTERMEDIATE-CS-0'
}

This application profile is aligned with the example trace of EDHOC compiled in Section 2 of [RFC9529].¶

7.9. Well-Known Application Profile EXTENSIVE

{
        e'methods' : [0, 1, 2, 3], / EDHOC Method Types
                                     0, 1, 2, and 3 /
  e'cipher_suites' : [0, 1, 2, 3], / EDHOC Cipher Suites
                                     0, 1, 2, and 3 /
     e'cred_types' : [1, 0, 2, e'c509_cert'], / CWT Claims Set (CCS),
                                              CWT, X.509 certificate,
                                              and C509 certificate /
  e'id_cred_types' : [4, 14, 13, 34, 33, e'c5t', e'c5c'], / kid,
                                                          kccs, kcwt,
                                                          x5t,
                                                          x5chain,
                                                          c5t, and
                                                          c5c /
       e'app_prof' : e'APP-PROF-EXTENSIVE'
}

This application profile is aligned with the example traces of EDHOC compiled in Sections 2 and 3 of [RFC9529].¶

10.1. Media Type Registrations

IANA is asked to register the media type "application/edhoc-app-profile+cbor-seq". This registration follows the procedures specified in [RFC6838].¶

Type name: application¶

Subtype name: edhoc-app-profile+cbor-seq¶

Required parameters: N/A¶

Optional parameters: N/A¶

Encoding considerations: Must be encoded as a CBOR sequence [RFC8742] of CBOR maps [RFC8949]. Each element of each CBOR map is also defined as an element of the CBOR-encoded EDHOC_Information object from Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile].¶

Security considerations: See Section 9 of [RFC-XXXX].¶

Interoperability considerations: N/A¶

Published specification: [RFC-XXXX]¶

Applications that use this media type: Applications that need to describe, distribute, and store a representation of an EDHOC application profile (see Section 3.9 of [RFC9528]).¶

Fragment identifier considerations: N/A¶

Additional information: N/A¶

Person & email address to contact for further information: LAKE WG mailing list (lake@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)¶

Intended usage: COMMON¶

Restrictions on usage: None¶

Author/Change controller: IETF¶

Provisional registration: No¶

10.2. CoAP Content-Formats Registry

IANA is asked to add the following entry to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.¶

Content Type: application/edhoc-app-profile+cbor-seq¶

Content Coding: -¶

ID: TBD (range 0-255)¶

Reference: [RFC-XXXX]¶

10.3. Target Attributes Registry

IANA is asked to register the following entries in the "Target Attributes" registry within the "Constrained RESTful Environments (CoRE) Parameters", as per [RFC9423].¶

• Attribute Name: ed-max-msgsize¶

• Brief Description: The admitted maximum size of EDHOC messages in bytes¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Attribute Name: ed-coap-ct¶

• Brief Description: Requested use of the CoAP Content-Format Option in CoAP messages whose payload includes exclusively an EDHOC message, possibly prepended by an EDHOC connection identifier¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Attribute Name: ed-epid-t¶

• Brief Description: A supported type of endpoint identity for EDHOC¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Attribute Name: ed-tp¶

• Brief Description: A supported means for transporting EDHOC messages¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Attribute Name: ed-prof¶

• Brief Description: A supported EDHOC application profile¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Attribute Name: ed-ta-edcred-uuid¶

• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other EDHOC peers, as a UUID¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Attribute Name: ed-ta-edcred-kid¶

• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other EDHOC peers, as a binary key identifier¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Attribute Name: ed-ta-edcred-c5t¶

• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other EDHOC peers, as a hash of a C509 certificate¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Attribute Name: ed-ta-edcred-c5u¶

• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other EDHOC peers, as a URI pointing to a C509 certificate¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Attribute Name: ed-ta-edcred-x5t¶

• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other EDHOC peers, as a hash of an X.509 certificate¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Attribute Name: ed-ta-edcred-x5u¶

• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other EDHOC peers, as a URI pointing to an X.509 certificate¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

10.4. EDHOC Information Registry

IANA is asked to register the following entry in the "EDHOC Information" registry defined in [I-D.ietf-ace-edhoc-oscore-profile].¶

• Name: app_prof¶

• CBOR label: 23 (suggested)¶

• CBOR type: int or array¶

• Registry: EDHOC Application Profiles registry¶

• Description: Set of supported EDHOC application profiles¶

• Specification: [RFC-XXXX][RFC9528]¶

10.5. EDHOC External Authorization Data Registry

IANA is asked to register the following entry in the "EDHOC External Authorization Data" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in [RFC9528].¶

• Name: Supported EDHOC application profiles¶

• Label: TBD_EAD_LABEL (range 0-23)¶

• Description: Set of supported EDHOC application profiles¶

• Reference: [RFC-XXXX]¶

10.6. EDHOC Error Codes Registry

IANA is asked to register the following entry in the "EDHOC Error Codes" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in [RFC9528].¶

• ERR_CODE: TBD_ERROR_CODE (range -24 to 23)¶

• ERR_INFO Type: app_profiles¶

• Description: Supported EDHOC application profiles¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

10.7. DNS SVCB Service Parameter Keys (SvcParamKeys)

IANA is asked to add the following entries to the "Service Parameter Keys (SvcParamKeys)" registry within the "DNS Service Bindings (SVCB)" registry group. The definition of these parameters can be found in Section 6.¶

• Number: 11 (suggested)¶

• Name: edhocpath¶

• Meaning: EDHOC resource path¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Number: 12 (suggested)¶

• Name: edhoc-app-prof¶

• Meaning: Supported EDHOC application profiles¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

10.8. EDHOC Application Profiles Registry

IANA is requested to create a new "EDHOC Application Profiles" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in [RFC9528].¶

The registration policy is either "Private Use", "Standards Action with Expert Review", or "Specification Required" per Section 4.6 of [RFC8126]. "Expert Review" guidelines are provided in Section 10.9.¶

All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per Section 4.9 of [RFC8126], with Expert Review additionally required per Section 4.5 of [RFC8126]. The procedure for early IANA allocation of Standards Track code points defined in [RFC7120] also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in Section 3.1 of [RFC7120].¶

The columns of this registry are:¶

• Profile ID: This field contains the value used to identify the EDHOC application profile. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies [RFC8126]. Integer values from -24 to 23 are designated as "Standards Action With Expert Review". Integer values from -65536 to -25 and from 24 to 65535 are designated as "Specification Required". Integer values smaller than -65536 and greater than 65535 are marked as "Private Use".¶

• Name: This field contains the name of the EDHOC application profile.¶

• Description: This field contains a short description of the EDHOC application profile.¶

• Reference: This field contains a pointer to the public specification for the EDHOC application profile.¶

This registry has been initially populated with the values in Table 2.¶

10.9. Expert Review Instructions

"Standards Action with Expert Review" and "Specification Required" are two of the registration policies defined for the IANA registry established in this document. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude.¶

Expert reviewers should take into consideration the following points:¶

• Clarity and correctness of registrations. Experts are expected to check the clarity of purpose and use of the requested entries. Experts need to make sure that the object of registration is clearly defined in the corresponding specification. Entries that do not meet these objective of clarity and completeness must not be registered.¶

• Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as "Private Use" are intended for testing purposes and closed environments. Code points in other ranges should not be assigned for testing.¶

• Specifications are required for the "Standards Action With Expert Review" range of point assignment. Specifications should exist for "Specification Required" ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.¶

• Experts should take into account the expected usage of fields when approving point assignment. Documents published via Standards Action can also register points outside the Standards Action range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.¶

11.1. Normative References

[I-D.ietf-ace-edhoc-oscore-profile]

Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund, "Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-edhoc-oscore-profile-08, 7 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile-08>.

[I-D.ietf-cose-cbor-encoded-cert]

Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 Certificates)", Work in Progress, Internet-Draft, draft-ietf-cose-cbor-encoded-cert-14, 23 June 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-14>.

[RFC2119]

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

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC5280]

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

[RFC6690]

Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/rfc/rfc6690>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC7120]

Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/rfc/rfc7120>.

[RFC7252]

Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/rfc/rfc7252>.

[RFC8126]

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

[RFC8174]

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

[RFC8288]

Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/rfc/rfc8288>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8613]

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

[RFC8742]

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

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9200]

Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, <https://www.rfc-editor.org/rfc/rfc9200>.

[RFC9360]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", RFC 9360, DOI 10.17487/RFC9360, February 2023, <https://www.rfc-editor.org/rfc/rfc9360>.

[RFC9460]

Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

[RFC9461]

Schwartz, B., "Service Binding Mapping for DNS Servers", RFC 9461, DOI 10.17487/RFC9461, November 2023, <https://www.rfc-editor.org/rfc/rfc9461>.

[RFC9528]

Selander, G., Preuß Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, DOI 10.17487/RFC9528, March 2024, <https://www.rfc-editor.org/rfc/rfc9528>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/rfc/rfc9562>.

[RFC9668]

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

11.2. Informative References

[I-D.serafin-lake-ta-hint]

Serafin, M. and G. Selander, "Trust Anchor Hints in Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in Progress, Internet-Draft, draft-serafin-lake-ta-hint-00, 21 October 2024, <https://datatracker.ietf.org/doc/html/draft-serafin-lake-ta-hint-00>.

[RFC9423]

Bormann, C., "Constrained RESTful Environments (CoRE) Target Attributes Registry", RFC 9423, DOI 10.17487/RFC9423, April 2024, <https://www.rfc-editor.org/rfc/rfc9423>.

[RFC9529]

Selander, G., Preuß Mattsson, J., Serafin, M., Tiloca, M., and M. Vučinić, "Traces of Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9529, DOI 10.17487/RFC9529, March 2024, <https://www.rfc-editor.org/rfc/rfc9529>.

B.1. Version -01 to -02

• Revised order of sections.¶

• Use of parameters aligned with corresponding updates in draft-ietf-ace-edhoc-oscore-profile.¶

• EAD item "Supported EDHOC application profiles":¶

  • It can be used only in a critical way.¶

  • Improved semantics of ead_value.¶

  • Content restrictions to avoid inconsistent information.¶

• Use of the parameter "app_prof" in draft-ietf-ace-edhoc-oscore-profile:¶

  • Improved co-existence with other parameters.¶

  • Content restrictions to avoid inconsistent information.¶

• Error handling:¶

  • EAD item "Supported EDHOC application profiles" occurring multiple times in EDHOC message_1 or message_2.¶

  • EAD item "Supported EDHOC application profiles" in EDHOC message_3 or message_4.¶

  • Invalid ead_value in EAD item "Supported EDHOC application profiles".¶

  • Invalid information in EDHOC error message with new error code.¶

• Fixed encoding of ERR_INFO for the EDHOC error message with the new error code.¶

• EDHOC_Application_Profile object¶

  • Clarified scope.¶

  • Clarified meaning of boolean parameters that are non-prescriptive.¶

  • Forbid the presence of the element "trust_anchors".¶

• Advertisement of Supported EDHOC Application Profiles using SVCB Resource Records.¶

• Updated integer abbreviations for the EDHOC_Information parameters.¶

• Editorial improvements.¶

B.2. Version -00 to -01

• Clarified motivation in the abstract and introduction.¶

• Moved definition of EDHOC_Information parameters to draft-ietf-ace-edhoc-oscore-profile.¶

• Renamed ed-idep-t x as ed-epid-t.¶

• Content-Format abbreviated as "ct" (not "cf").¶

• CBOR abbreviation of "app_prof" changed to 23.¶

• Added preamble on identifying application profiles by Profile ID.¶

• Defined target attributes "ed-ta-*" for specifying supported trust anchors.¶

• Defined new EAD item and error code to advertise supported EDHOC application profiles.¶

• Defined how to handle non admitted parameters.¶

• Renamed well-known EDHOC application profiles.¶

• Updated IANA considerations:¶

  • Suggested range 0-255 for CoAP Content-Format ID.¶

  • Requested registration for target attributes "ed-ta-*".¶

  • Removed requests for registration of removed parameters.¶

• Updated references.¶

• Editorial improvements.¶