Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-ietf-lake-app-profiles-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Marco Tiloca , Rikard Höglund | ||
| Last updated | 2024-12-10 | ||
| Replaces | draft-tiloca-lake-app-profiles | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Associated WG milestone |
|
||
| On agenda | lake at IETF-126 | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-lake-app-profiles-00
LAKE Working Group M. Tiloca
Internet-Draft R. Höglund
Intended status: Standards Track RISE AB
Expires: 13 June 2025 10 December 2024
Coordinating the Use of Application Profiles for Ephemeral Diffie-
Hellman Over COSE (EDHOC)
draft-ietf-lake-app-profiles-00
Abstract
The lightweight authenticated key exchange protocol Ephemeral Diffie-
Hellman Over COSE (EDHOC) requires certain parameters to be agreed
out-of-band, in order to ensure its successful completion. To this
end, application profiles specify the intended use of EDHOC to allow
for the relevant processing and verifications to be made. This
document defines a number of means to coordinate the use and
discovery of EDHOC application profiles. Also, it defines a
canonical, CBOR-based representation that can be used to describe,
distribute, and store EDHOC application profiles. Finally, this
document defines a set of well-known EDHOC application profiles.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Lightweight
Authenticated Key Exchange Working Group mailing list
(lake@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/lake/.
Source for this draft and an issue tracker can be found at
https://github.com/lake-wg/app-profiles.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Tiloca & Höglund Expires 13 June 2025 [Page 1]
Internet-Draft EDHOC Application Profiles December 2024
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 June 2025.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Identifying EDHOC Application Profiles by Profile ID . . . . 5
2.1. Web Linking . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. EDHOC_Information Object . . . . . . . . . . . . . . . . 7
2.2.1. Use in the EDHOC and OSCORE Profile of the ACE
Framework . . . . . . . . . . . . . . . . . . . . . . 8
3. Additional Parameters for Web Linking . . . . . . . . . . . . 9
4. Additional Parameters of the EDHOC_Information Object . . . . 10
5. Representation of an EDHOC Application Profile . . . . . . . 12
6. Well-known EDHOC Application Profiles . . . . . . . . . . . . 14
6.1. Well-Known Application Profile WK-MINIMAL_CS_2 . . . . . 14
6.2. Well-Known Application Profile WK-MINIMAL_CS_0 . . . . . 15
6.3. Well-Known Application Profile WK-BASIC_CS_2_X509 . . . . 15
6.4. Well-Known Application Profile WK-BASIC_CS_0_X509 . . . . 15
6.5. Well-Known Application Profile WK-BASIC_CS_2_C509 . . . . 15
6.6. Well-Known Application Profile WK-BASIC_CS_0_C509 . . . . 16
6.7. Well-Known Application Profile WK-INTERMEDIATE_CS_2 . . . 16
6.8. Well-Known Application Profile WK-INTERMEDIATE_CS_0 . . . 16
6.9. Well-Known Application Profile WK-ADVANCED . . . . . . . 16
7. EDHOC Well-known Application Profiles . . . . . . . . . . . . 17
8. EDHOC Endpoint Identity Types . . . . . . . . . . . . . . . . 18
9. EDHOC Transports . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
Tiloca & Höglund Expires 13 June 2025 [Page 2]
Internet-Draft EDHOC Application Profiles December 2024
11.1. Media Type Registrations . . . . . . . . . . . . . . . . 20
11.2. CoAP Content-Formats Registry . . . . . . . . . . . . . 21
11.3. Target Attributes Registry . . . . . . . . . . . . . . . 21
11.4. EDHOC Information Registry . . . . . . . . . . . . . . . 22
11.5. EDHOC Application Profiles Registry . . . . . . . . . . 24
11.6. EDHOC Endpoint Identity Types Registry . . . . . . . . . 25
11.7. EDHOC Transport Registry . . . . . . . . . . . . . . . . 26
11.8. Expert Review Instructions . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. CDDL Model . . . . . . . . . . . . . . . . . . . . . 30
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] is a lightweight
authenticated key exchange protocol, especially intended for use in
constrained scenarios.
In order to successfully run EDHOC, the two peers acting as Initiator
and Responder have to agree on certain parameters. Some of those are
in-band and communicated through the protocol execution, during which
a few of them may even be negotiated. However, other parameters have
to be known out-of-band, before running the EDHOC protocol.
As discussed in Section 3.9 of [RFC9528], applications can use EDHOC
application profiles, which specify the intended usage of EDHOC to
allow for the relevant processing and verifications to be made. In
particular, an EDHOC application profile may include both in-band and
out-of-band parameters.
This document defines a number of means to coordinate the use and
discovery of EDHOC application profiles, that is:
* The new IANA registry "EDHOC Application Profiles" defined in
Section 11.5, where to register integer identifiers of EDHOC
application profiles to use as corresponding Profile IDs.
* The new parameter "ed-prof" defined in Section 2.1. This
parameter is employed to specify an EDHOC application profile
identified by its Profile ID, and can be used as target attribute
in a web link [RFC8288] to an EDHOC resource, or as filter
criteria in a discovery request to discover EDHOC resources.
Tiloca & Höglund Expires 13 June 2025 [Page 3]
Internet-Draft EDHOC Application Profiles December 2024
For instance, the target attribute can be used in a link-format
document [RFC6690] describing EDHOC resources at a server, when
EDHOC is transferred over CoAP [RFC7252] (see Appendix A.2 of
[RFC9528] as well as [I-D.ietf-core-oscore-edhoc]).
* The new parameter "app_prof" defined in Section 2.2 for the
EDHOC_Information object specified in
[I-D.ietf-ace-edhoc-oscore-profile]. This parameter is employed
to specify a set of EDHOC application profiles, each identified by
its Profile ID.
For instance, the parameter can be used in the EDHOC and OSCORE
profile [I-D.ietf-ace-edhoc-oscore-profile] of the ACE framework
for authentication and authorization in constrained environments
(ACE) [RFC9200], in order to indicate the EDHOC application
profiles supported by an ACE resource server.
* Additional parameters that provide information about an EDHOC
application profile. A subset of these parameters are to be used
as target attributes in a web link to an EDHOC resource, or as
filter criteria in a discovery request to discover EDHOC resources
(see Section 3). Another subset of these parameters are to be
used as elements of the EDHOC_Information object (see Section 4).
In order to ensure the applicability of such parameters beyond
transport- or setup-specific scenarios, this document also defines a
canonical, CBOR-based representation that can be used to describe,
distribute, and store EDHOC application profiles as CBOR data items
(see Section 5). The defined representation is transport- and setup-
independent, and avoids the need to reinvent an encoding for the
available options to run the EDHOC protocol or the selection logic to
apply on those.
The CBOR-based representation of an EDHOC application profile can be,
for example: retrieved as a result of a discovery process; or
retrieved/provided during the retrieval/provisioning of an EDHOC
peer's public authentication credential; or obtained during the
execution of a device on-boarding/registration workflow.
Finally, this document defines a set of well-known EDHOC application
profiles (see Section 6). These application profiles are meant to
reflect what is most common and expected to be supported by EDHOC
peers, while they are not to be intended as "default" application
profiles or as a deviation from what is mandatory to support for
EDHOC peers (see Section 8 of [RFC9528]).
Tiloca & Höglund Expires 13 June 2025 [Page 4]
Internet-Draft EDHOC Application Profiles December 2024
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 [I-D.ietf-core-oscore-edhoc].
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 2 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 2
of Appendix A. Finally, please delete this note.
2. Identifying EDHOC Application Profiles by Profile ID
This section defines two means to identify EDHOC application profiles
by their Profile IDs, i.e., the parameter "ed-prof" for web linking
(see Section 2.1) and the parameter "app_prof" of the
EDHOC_Information object (see Section 2.2).
Tiloca & Höglund Expires 13 June 2025 [Page 5]
Internet-Draft EDHOC Application Profiles December 2024
2.1. Web Linking
Section 6 of [I-D.ietf-core-oscore-edhoc] 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 11.5 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 [I-D.ietf-core-oscore-edhoc] and Section 3 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 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'.
Tiloca & Höglund Expires 13 June 2025 [Page 6]
Internet-Draft EDHOC Application Profiles December 2024
The example in Figure 1 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
Figure 1: The Web Link.
2.2. 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.
+==========+=======+========+===================+===================+
| Name | CBOR | CBOR | Registry | Description |
| | label | type | | |
+==========+=======+========+===================+===================+
| app_prof | 18 | int | EDHOC Application | Set of supported |
| | | or | Profiles Registry | EDHOC Application |
| | | array | | Profiles |
+----------+-------+--------+-------------------+-------------------+
Table 1: EDHOC_Information Parameter "app_prof"
Tiloca & Höglund Expires 13 June 2025 [Page 7]
Internet-Draft EDHOC Application Profiles December 2024
* 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 18. The integer values are taken from the
'Profile ID' column of the "EDHOC Application Profiles" registry
defined in Section 11.5 of this document.
2.2.1. Use in the EDHOC and OSCORE Profile of the ACE Framework
Section 3 of [I-D.ietf-ace-edhoc-oscore-profile] defines how the
EDHOC_Information object can be used within the workflow of the EDHOC
and OSCORE transport profile of the ACE framework for authentication
and authorization in constrained environments (ACE) [RFC9200].
In particular, the AS-to-C Access Token Response includes the
parameter "edhoc_info", with value an EDHOC_Information object. This
allows the ACE authorization server (AS) to provide the ACE client
(C) with information about how to run the EDHOC protocol with the ACE
resource server (RS) for which the access token is issued.
Similarly, the access token includes the corresponding claim
"edhoc_info", with value an EDHOC_Information object. This allows
the AS to provide the ACE RS with information about how to run the
EDHOC protocol with the ACE client, according to the issued access
token.
In turn, the EDHOC_Information object can include the parameter
"app_prof" defined in this document. This parameter indicates a set
of EDHOC application profiles associated with the EDHOC resource to
use at the RS, which is either implied or specified by the parameter
"uri_path" within the same EDHOC_Information object.
If the EDHOC_Information object specified as value of "edhoc_info"
includes the "app_prof" parameter, then the following applies.
* The object MUST NOT include other parameters that provide
information pertaining to an EDHOC application profile, with the
exception of the parameter "eads" that MAY be included.
C and RS MUST ignore other parameters present in the
EDHOC_Information object, with the exception of the parameter
"eads".
Tiloca & Höglund Expires 13 June 2025 [Page 8]
Internet-Draft EDHOC Application Profiles December 2024
At the time of writing this document, such parameters are:
"methods", "cipher_suites", "message_4", "comb_req", "osc_ms_len",
"osc_salt_len", "osc_version", "cred_types", "id_cred_types",
"initiator", and "responder" (which are all defined in Section 3.4
of [I-D.ietf-ace-edhoc-oscore-profile]), as well as those defined
in Section 4 of this document.
* If the EDHOC_Information object specified in the parameter
"edhoc_info" of the AS-to-C Access Token Response includes the
parameter "eads", the object provides the following information.
When using the target EDHOC resource as per any EDHOC application
profile indicated by the parameter "app_prof", the ACE RS for
which the access token is issued supports the EAD items that are
specified in the definition of that EDHOC application profile, as
well as the EAD items indicated by the parameter "eads".
* If the EDHOC_Information object specified in the claim
"edhoc_info" of the access token includes the parameter "eads",
the object provides the following information.
When using the target EDHOC resource as per any EDHOC application
profile indicated by the parameter "app_prof", the ACE client to
which the access token is issued supports the EAD items that are
specified in the definition of that EDHOC application profile, as
well as the EAD items indicated by the parameter "eads".
3. Additional Parameters for Web Linking
Building on what is defined and prescribed in Section 6 of
[I-D.ietf-core-oscore-edhoc], this section defines additional
parameters for web linking [RFC8288], which can be used to obtain
relevant pieces of information from the EDHOC application profile
associated with an EDHOC resource.
These parameters can be optionally specified as target attributes
with the same name in a link with resource type "core.edhoc" (see
Section 10.10 of [RFC9528]) targeting an EDHOC resource, or as filter
criteria in a discovery request from a client.
When specifying any of the parameters defined below in a link to an
EDHOC resource, the target attribute rt="core.edhoc" MUST be
included.
* 'ed-max-msgsize', specifying the admitted maximum size of EDHOC
messages in bytes. This parameter MUST specify a single unsigned
integer value.
Tiloca & Höglund Expires 13 June 2025 [Page 9]
Internet-Draft EDHOC Application Profiles December 2024
* 'ed-coap-cf', specifying that CoAP messages have to include the
CoAP Content-Format Option with value 64 (application/edhoc+cbor-
seq) or 65 (application/cid-edhoc+cbor-seq) as appropriate, when
the message payload includes exclusively an EDHOC message possibly
prepended by an EDHOC connection identifier (see Sections 3.4.1
and A.2 of [RFC9528]). A value MUST NOT be given to this
parameter and any present value MUST be ignored by the recipient.
* 'ed-idep-t', specifying a type of endpoint identity for EDHOC
supported by the server. This parameter MUST specify a single
value, which is taken from the 'CBOR Label' column of the "EDHOC
Endpoint Identity Types" Registry defined in Section 8 of this
document. This parameter MAY occur multiple times, with each
occurrence specifying a type of endpoint identity for EDHOC.
* 'ed-tp', specifying a means for transporting EDHOC messages
supported by the server. This parameter MUST specify a single
value, which is taken from the 'Transport ID' column of the "EDHOC
Transports" Registry defined in Section 9 of this document. This
parameter MAY occur multiple times, with each occurrence
specifying a means for transporting EDHOC messages.
4. Additional Parameters of the EDHOC_Information Object
This section defines additional parameters of the EDHOC_Information
object defined in Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile].
These parameters are summarized in Table 2 and described further
below.
Editor's note: these parameters can better be defined directly in
Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile].
Tiloca & Höglund Expires 13 June 2025 [Page 10]
Internet-Draft EDHOC Application Profiles December 2024
+=============+=======+=======+============+=======================+
| Name | CBOR | CBOR | Registry | Description |
| | label | type | | |
+=============+=======+=======+============+=======================+
| max_msgsize | 14 | uint | | Maximum size of EDHOC |
| | | | | messages in bytes |
+-------------+-------+-------+------------+-----------------------+
| coap_cf | 15 | True | | Requested use of the |
| | | of | | CoAP Content-Format |
| | | False | | Option in CoAP |
| | | | | messages whose |
| | | | | payload includes |
| | | | | exclusively an EDHOC |
| | | | | message, possibly |
| | | | | prepended by an EDHOC |
| | | | | connection identifier |
+-------------+-------+-------+------------+-----------------------+
| id_ep_types | 16 | int | EDHOC | Set of supported |
| | | or | Endpoint | types of endpoint |
| | | array | Identity | identities for EDHOC |
| | | | Types | |
| | | | Registry | |
+-------------+-------+-------+------------+-----------------------+
| transports | 17 | int | EDHOC | Set of supported |
| | | or | Transports | means for |
| | | array | Registry | transporting EDHOC |
| | | | | messages |
+-------------+-------+-------+------------+-----------------------+
Table 2: EDHOC_Information Parameters
* max_msgsize: This parameter specifies the admitted maximum size of
EDHOC messages in bytes. In JSON, the "max_msgsize" value is an
unsigned integer. In CBOR, "max_msgsize" is an unsigned integer
and has label 14.
* coap_cf: This parameter specifies whether it is required that CoAP
messages include the CoAP Content-Format Option with value 64
(application/edhoc+cbor-seq) or 65 (application/cid-edhoc+cbor-
seq) as appropriate, when the message payload includes exclusively
an EDHOC message possibly prepended by an EDHOC connection
identifier (see Sections 3.4.1 and A.2 of [RFC9528]). In JSON,
the "coap_cf" value is a boolean. In CBOR, "coap_cf" is the
simple value true (0xf5) or false (0xf4), and has label 15.
* id_ep_types: This parameter specifies a set of supported types of
endpoint identities for EDHOC. If the set is composed of a single
type of endpoint identity, this is encoded as an integer.
Tiloca & Höglund Expires 13 June 2025 [Page 11]
Internet-Draft EDHOC Application Profiles December 2024
Otherwise, the set is encoded as an array, where each array
element encodes one type of endpoint identity as an integer. In
JSON, the "id_ep_types" value is an integer or an array of
integers. In CBOR, "id_ep_types" is an integer or an array of
integers, and has label 16. The integer values are taken from the
'CBOR Label' column of the "EDHOC Endpoint Identity Types"
registry defined in Section 11.6 of this document.
* transports: This parameter specifies a set of supported means for
transporting EDHOC messages. If the set is composed of a single
means for transporting EDHOC messages, this is encoded as an
integer. Otherwise, the set is encoded as an array, where each
array element encodes one means for transporting EDHOC messages as
an integer. In JSON, the "transports" value is an integer or an
array of integers. In CBOR, "transports" is an integer or an
array of integers, and has label 17. The integer values are taken
from the 'Transport ID' column of the "EDHOC Transports" Registry
defined in Section 9 of this document.
5. Representation of an EDHOC Application Profile
This section defines the EDHOC_Application_Profile object, which can
be used as a canonical representation of EDHOC application profiles
for their description, distribution, and storage.
An EDHOC_Application_Profile object is encoded as a CBOR map
[RFC8949]. Each element of the CBOR map is an element of the CBOR-
encoded EDHOC_Information object defined in Section 3.4 of
[I-D.ietf-ace-edhoc-oscore-profile], and thus uses the corresponding
CBOR abbreviations from the 'CBOR label' column of the "EDHOC
Information" registry defined in [I-D.ietf-ace-edhoc-oscore-profile].
The CBOR map encoding an EDHOC_Application_Profile object MUST
include the element "app_prof" defined in this document. The value
of the element "app_prof" is the unique identifier of the EDHOC
application profile described by the EDHOC_Application_Profile
object, taken from the 'Profile ID' column of the "EDHOC Application
Profiles" registry defined in this document, and encoded as a CBOR
integer.
The CBOR map MUST include the following elements defined for the
EDHOC_Information object: "methods" and "cred_types".
The CBOR map MUST NOT include the following elements defined for the
EDHOC_Information object: "session_id", "uri_path", "initiator", and
"responder".
Tiloca & Höglund Expires 13 June 2025 [Page 12]
Internet-Draft EDHOC Application Profiles December 2024
The CBOR map MAY include other elements defined for the
EDHOC_Information object. These also comprise the new parameters
defined in Section 4 of this document.
Furthermore, consistent with Sections 8 and A.1 of [RFC9528] and with
Section 5.4 of [RFC8613], the following applies:
* If the element "cipher_suites" is not present in the CBOR map,
this indicates that the EDHOC application profile uses the EDHOC
cipher suites 2 and 3.
* If the element "id_cred_types" is not present in the CBOR map,
this indicates that the EDHOC application profile uses "kid" as
type of authentication credential identifiers for EDHOC.
* If the element "osc_ms_len" is not present in the CBOR map, this
indicates that, when using EDHOC to key OSCORE [RFC8613], the size
of the OSCORE Master Secret in bytes is equal to the size of the
key length for the application AEAD Algorithm of the selected
cipher suite for the EDHOC session.
* If the element "osc_salt_len" is not present in the CBOR map, this
indicates that, when using EDHOC to key OSCORE, the size of the
OSCORE Master Salt in bytes is 8.
* If the element "osc_version" is not present in the CBOR map, this
indicates that, when using EDHOC to key OSCORE, the OSCORE Version
Number has value 1.
* The absence of any other elements in the CBOR map MUST NOT result
in assuming any value.
If an element is present in the CBOR map and the information that it
specifies is intrinsically a set of one or more co-existing
alternatives, then all the specified alternatives apply for the EDHOC
application profile in question.
For example, the element "cipher_suites" with value the CBOR array
[0, 2] means that, in order to adhere to the EDHOC application
profile in question, an EDHOC peer has to implement both the EDHOC
cipher suites 0 and 2, because either of them can be used by another
EDHOC peer also adhering to the same EDHOC application profile.
The CDDL grammar describing the EDHOC_Application_Profile object is:
Tiloca & Höglund Expires 13 June 2025 [Page 13]
Internet-Draft EDHOC Application Profiles December 2024
EDHOC_Application_Profile = {
1 => int / array, ; methods
9 => int / array, ; cred_types
18 => int, ; app_prof
* int / tstr => any
}
6. Well-known EDHOC Application Profiles
This section defines a set of well-known EDHOC application profiles
that are meant to reflect what is most common and expected to be
supported by EDHOC peers.
The well-known application profiles are _not_ to be intended as
"default" profiles to use, in case no other indication is provided to
EDHOC peers.
In particular, an EDHOC peer MUST NOT assume that, unless otherwise
indicated, any of such profiles is used when running EDHOC through a
well-known EDHOC resource, such as the resource at /.well-known/edhoc
when EDHOC messages are transported as payload of CoAP messages (see
Appendix A.2 of [RFC9528]).
Building on the above, the well-known application profiles are _not_
intended to deviate from what is mandatory to support for EDHOC
peers, which is defined by the compliance requirements in Section 8
of [RFC9528].
The rest of this section defines the well-known application profiles,
each of which is represented by means of an EDHOC_Application_Profile
object (see Section 5) using the CBOR extended diagnostic notation.
An entry for each well-known application profile is also registered
at the "EDHOC Application Profiles" registry defined in Section 11.5
of this document.
6.1. Well-Known Application Profile WK-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-WK-MINIMAL-CS-2'
}
This application profile is aligned with the example trace of EDHOC
compiled in Section 3 of [RFC9529].
Tiloca & Höglund Expires 13 June 2025 [Page 14]
Internet-Draft EDHOC Application Profiles December 2024
6.2. Well-Known Application Profile WK-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-WK-MINIMAL-CS-0'
}
6.3. Well-Known Application Profile WK-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-WK-BASIC-CS-2-X509'
}
This application profile is aligned with the example trace of EDHOC
compiled in Section 3 of [RFC9529].
6.4. Well-Known Application Profile WK-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-WK-BASIC-CS-0-X509'
}
This application profile is aligned with the example trace of EDHOC
compiled in Section 2 of [RFC9529].
6.5. Well-Known Application Profile WK-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-WK-BASIC-CS-2-C509'
}
Tiloca & Höglund Expires 13 June 2025 [Page 15]
Internet-Draft EDHOC Application Profiles December 2024
6.6. Well-Known Application Profile WK-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-WK-BASIC-CS-0-C509'
}
6.7. Well-Known Application Profile WK-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-WK-INTERMEDIATE-CS-2'
}
This application profile is aligned with the example trace of EDHOC
compiled in Section 3 of [RFC9529].
6.8. Well-Known Application Profile WK-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-WK-INTERMEDIATE-CS-0'
}
This application profile is aligned with the example trace of EDHOC
compiled in Section 2 of [RFC9529].
6.9. Well-Known Application Profile WK-ADVANCED
Tiloca & Höglund Expires 13 June 2025 [Page 16]
Internet-Draft EDHOC Application Profiles December 2024
{
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-WK-ADVANCED'
}
This application profile is aligned with the example traces of EDHOC
compiled in Sections 2 and 3 of [RFC9529].
7. EDHOC Well-known Application Profiles
This document defines the following identifiers of well-known EDHOC
application profiles.
+=========+======================+=====================+============+
| Profile | Name | Description | Reference |
| ID | | | |
+=========+======================+=====================+============+
| 0 | WK-MINIMAL-CS-2 | Method 3; Cipher | [RFC-XXXX] |
| | | Suite 2; CCS; kid | |
+---------+----------------------+---------------------+------------+
| 1 | WK-MINIMAL-CS-0 | Method 3; Cipher | [RFC-XXXX] |
| | | Suite 0; CCS; kid | |
+---------+----------------------+---------------------+------------+
| 2 | WK-BASIC-CS-2-X509 | Methods (0, 3); | [RFC-XXXX] |
| | | Cipher Suite 2; | |
| | | (CCS, X.509 | |
| | | certificates); | |
| | | (kid, x5t) | |
+---------+----------------------+---------------------+------------+
| 3 | WK-BASIC-CS-0-X509 | Methods (0, 3); | [RFC-XXXX] |
| | | Cipher Suite 0; | |
| | | (CCS, X.509 | |
| | | certificates); | |
| | | (kid, x5t) | |
+---------+----------------------+---------------------+------------+
| 4 | WK-BASIC-CS-2-C509 | Methods (0, 3); | [RFC-XXXX] |
| | | Cipher Suite 2; | |
Tiloca & Höglund Expires 13 June 2025 [Page 17]
Internet-Draft EDHOC Application Profiles December 2024
| | | (CCS, C509 | |
| | | certificates); | |
| | | (kid, c5t) | |
+---------+----------------------+---------------------+------------+
| 5 | WK-BASIC-CS_0-C509 | Methods (0, 3); | [RFC-XXXX] |
| | | Cipher Suite 0; | |
| | | (CCS, C509 | |
| | | certificates); | |
| | | (kid, c5t) | |
+---------+----------------------+---------------------+------------+
| 6 | WK-INTERMEDIATE-CS-2 | Methods (0, 3); | [RFC-XXXX] |
| | | Cipher Suite 2; | |
| | | (CCS, X.509/C509 | |
| | | certificates); | |
| | | (kid, kccs, x5t, | |
| | | x5chain, c5t, | |
| | | c5c) | |
+---------+----------------------+---------------------+------------+
| 7 | WK-INTERMEDIATE-CS-0 | Methods (0, 3); | [RFC-XXXX] |
| | | Cipher Suite 0; | |
| | | (CCS, X.509/C509 | |
| | | certificates); | |
| | | (kid, kccs, x5t, | |
| | | x5chain, c5t, | |
| | | c5c) | |
+---------+----------------------+---------------------+------------+
| 8 | WK-ADVANCED | Methods (0, 1, 2, | [RFC-XXXX] |
| | | 3); Cipher Suites | |
| | | (0, 1, 2, 3); | |
| | | (CCS, CWT, X.509/ | |
| | | C509 | |
| | | certificates); | |
| | | (kid, kccs, kcwt, | |
| | | x5t, x5chain, | |
| | | c5t, c5c) | |
+---------+----------------------+---------------------+------------+
Table 3: EDHOC Well-known Application Profiles
8. EDHOC Endpoint Identity Types
This document defines the following identifier of type of endpoint
identity for EDHOC.
Tiloca & Höglund Expires 13 June 2025 [Page 18]
Internet-Draft EDHOC Application Profiles December 2024
+========+============+====================+=====================+
| Name | CBOR label | Description | Reference |
+========+============+====================+=====================+
| EUI-64 | 0 | An EUI-64 identity | [RFC-XXXX][RFC4291] |
+--------+------------+--------------------+---------------------+
Table 4: EDHOC Endpoint Identity Types
9. EDHOC Transports
This document defines the following identifiers of means for
transporting EDHOC messages.
+===========+============+===================+====================+
| Transport | Name | Description | Reference |
| ID | | | |
+===========+============+===================+====================+
| 0 | CoAP over | EDHOC messages | [RFC7252], |
| | UDP | are transported | Appendix A.2 of |
| | | as payload of | [RFC9528] |
| | | CoAP messages, in | |
| | | turn transported | |
| | | over UDP | |
+-----------+------------+-------------------+--------------------+
| 1 | CoAP over | EDHOC messages | [RFC7252][RFC8323] |
| | TCP | are transported | |
| | | as payload of | |
| | | CoAP messages, in | |
| | | turn transported | |
| | | over TCP | |
+-----------+------------+-------------------+--------------------+
| 2 | CoAP over | EDHOC messages | [RFC7252][RFC8323] |
| | WebSockets | are transported | |
| | | as payload of | |
| | | CoAP messages, in | |
| | | turn transported | |
| | | over WebSockets | |
+-----------+------------+-------------------+--------------------+
Table 5: EDHOC Transports
10. Security Considerations
TBD
Tiloca & Höglund Expires 13 June 2025 [Page 19]
Internet-Draft EDHOC Application Profiles December 2024
11. IANA Considerations
This document has the following actions for IANA.
Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
with the RFC number of this specification and delete this paragraph.
11.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 10 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
Tiloca & Höglund Expires 13 June 2025 [Page 20]
Internet-Draft EDHOC Application Profiles December 2024
Author/Change controller: IETF
Provisional registration: No
11.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
Reference: [RFC-XXXX]
11.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-cf
* 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-idep-t
Tiloca & Höglund Expires 13 June 2025 [Page 21]
Internet-Draft EDHOC Application Profiles December 2024
* 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]
11.4. EDHOC Information Registry
IANA is asked to register the following entries in the "EDHOC
Information" registry defined in [I-D.ietf-ace-edhoc-oscore-profile].
* Name: max_msgsize
* CBOR label: 14
* CBOR type: uint
* Registry:
* Description: The admitted maximum size of EDHOC messages in bytes
* Specification: [RFC-XXXX][RFC9528]
* Name: coap_cf
Tiloca & Höglund Expires 13 June 2025 [Page 22]
Internet-Draft EDHOC Application Profiles December 2024
* CBOR label: 15
* CBOR type: True or False
* Registry:
* 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
* Specification: [RFC-XXXX][RFC9528]
* Name: id_ep_types
* CBOR label: 16
* CBOR type: int or array
* Registry: EDHOC Endpoint Identity Types
* Description: Set of supported types of endpoint identities for
EDHOC
* Specification: [RFC-XXXX]
* Name: transports
* CBOR label: 17
* CBOR type: int or array
* Registry: EDHOC Transports Registry
* Description: Set of supported means for transporting EDHOC
messages
* Specification: [RFC-XXXX]
* Name: app_prof
* CBOR label: 18
Tiloca & Höglund Expires 13 June 2025 [Page 23]
Internet-Draft EDHOC Application Profiles December 2024
* CBOR type: int or array
* Registry: EDHOC Application Profiles Registry
* Description: Set of supported EDHOC Application Profiles
* Specification: [RFC-XXXX][RFC9528]
11.5. 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 11.8.
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.
Tiloca & Höglund Expires 13 June 2025 [Page 24]
Internet-Draft EDHOC Application Profiles December 2024
This registry has been initially populated with the values in
Table 3.
11.6. EDHOC Endpoint Identity Types Registry
IANA is requested to create a new "EDHOC Endpoint Identity Types"
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 11.8.
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:
* Name: This field contains the name of the EDHOC endpoint identity
type.
* CBOR Label: The value to be used to identify this EDHOC endpoint
identity type. 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".
* Description: This field contains a short description of the EDHOC
endpoint identity type.
* Reference: This field contains a pointer to the public
specification for the EDHOC endpoint identity type.
This registry has been initially populated with the values in
Table 4.
Tiloca & Höglund Expires 13 June 2025 [Page 25]
Internet-Draft EDHOC Application Profiles December 2024
11.7. EDHOC Transport Registry
IANA is requested to create a new "EDHOC Transport" 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 11.8.
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:
* Transport ID: The value to be used to identify this means for
transporting EDHOC messages. 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 means for transporting
EDHOC messages.
* Description: This field contains a short description of the means
used for transporting EDHOC messages.
* Reference: This field contains a pointer to the public
specification for the means used for transporting EDHOC messages.
This registry has been initially populated with the values in
Table 5.
Tiloca & Höglund Expires 13 June 2025 [Page 26]
Internet-Draft EDHOC Application Profiles December 2024
11.8. Expert Review Instructions
"Standards Action with Expert Review" and "Specification Required"
are two of the registration policies defined for the IANA registries
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 (i.e.,
an EDHOC application profile, an EDHOC endpoint identity type, or
a means for transporting EDHOC messages) 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.
12. References
12.1. Normative References
Tiloca & Höglund Expires 13 June 2025 [Page 27]
Internet-Draft EDHOC Application Profiles December 2024
[COSE.Header.Parameters]
IANA, "COSE Header Parameters",
<https://www.iana.org/assignments/cose/cose.xhtml#header-
parameters>.
[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-06, 21 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ace-
edhoc-oscore-profile-06>.
[I-D.ietf-core-oscore-edhoc]
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-11, 9 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-edhoc-11>.
[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>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/rfc/rfc4291>.
[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>.
Tiloca & Höglund Expires 13 June 2025 [Page 28]
Internet-Draft EDHOC Application Profiles December 2024
[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>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/rfc/rfc8323>.
[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>.
Tiloca & Höglund Expires 13 June 2025 [Page 29]
Internet-Draft EDHOC Application Profiles December 2024
[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>.
[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>.
[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>.
12.2. Informative References
[RFC9529] Selander, G., Preuß Mattsson, J., Serafin, M., Tiloca, M.,
and M. Vučinić, "Traces of Ephemeral Diffie-Hellman Over
COSE (EDHOC)", RFC 9529, DOI 10.17487/RFC9529, March 2024,
<https://www.rfc-editor.org/rfc/rfc9529>.
Appendix A. CDDL Model
This section is to be removed before publishing as an RFC.
Tiloca & Höglund Expires 13 June 2025 [Page 30]
Internet-Draft EDHOC Application Profiles December 2024
; EDHOC Information
methods = 1
cipher_suites = 2
cred_types = 9
id_cred_types = 10
app_prof = 18
; EDHOC Application Profiles
APP-PROF-WK-MINIMAL-CS-2 = 0
APP-PROF-WK-MINIMAL-CS-0 = 1
APP-PROF-WK-BASIC-CS-2-X509 = 2
APP-PROF-WK-BASIC-CS-0-X509 = 3
APP-PROF-WK-BASIC-CS-2-C509 = 4
APP-PROF-WK-BASIC-CS-0-C509 = 5
APP-PROF-WK-INTERMEDIATE-CS-2 = 6
APP-PROF-WK-INTERMEDIATE-CS-0 = 7
APP-PROF-WK-ADVANCED = 8
; COSE Header Parameters
c5t = 22
c5c = 25
; EDHOC Authentication Credential Types
c509_cert = 3
Figure 2: CDDL model
Acknowledgments
The authors sincerely thank Christian Amsüss, Göran Selander, and
Brian Sipos for their feedback and comments.
This work was supported by the Sweden's Innovation Agency VINNOVA
within the EUREKA CELTIC-NEXT project CYPRESS.
Authors' Addresses
Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-16440 Stockholm Kista
Sweden
Email: marco.tiloca@ri.se
Tiloca & Höglund Expires 13 June 2025 [Page 31]
Internet-Draft EDHOC Application Profiles December 2024
Rikard Höglund
RISE AB
Isafjordsgatan 22
SE-16440 Stockholm Kista
Sweden
Email: rikard.hoglund@ri.se
Tiloca & Höglund Expires 13 June 2025 [Page 32]