Draft: draft-ietf-lake-edhoc

Commentary: Addressing 
 Not yet addressing random padding and general IANA considerations . 
 Now addressed essentially all comments from intdir . No change is made on random padding since that feature was requested by the WG . The IANA section is quite changed so expect to see more comments on that . 
 The main uncommented part of this PR is the new content in the IANA section . Plan to merge soon . 
 I found this to be a relatively long , detailed , and intricate draft which assumed knowledge of multiple other documents concerning CBOR , COSE , CWT , and CDDL . The document specifies Ephemeral    Over COSE ( EDHOC ) , a lightweight authenticated key exchange protocol including forward secrecy , identity protection , and cipher suite negotiation . I do not see any particular INT Area concerns with this document . Based on my review , if I were on the IESG I would ballot this document as NO OBJECTION The following are issues that SHOULD be corrected before publication : Section 3.8 , Page 21 : In the last paragraph of the section , " must not " -"MUST NOT " Section 3.8.1 : I would recommend against the use of random padding and in favor of deterministic padding ( perhaps dependent on the padding length , e.g. , pad with bytes whose value is the padding length modulo 256 ) . Random padding provides a convenient covert channel and will use up some pseudorandom number generator entropy . As long as it is going to get strongly encrypted , there seems to be no advantage to using random padding material . Sections 5.2.1/5.2.2 , Pages 30/31 : I found it quite confusing , on first reading , how the explanation of SUITESI is split between these two sections and the way " preference " is used in two different ways : as the preference the Initiator has for different cipher suites but also as the suite the Responder prefers among those supported by the Initiator . And the text in 5.2.2 may be inconsistent because it says the Initiator MUST select its most preferred cipher suite based " on what it can assume to be supported by the Responder " but later says this SHOULD change for certain error messages from a Responder . ( There is also an extraneous close curly brace ( " } " ) in the last line on page 30 . ) The text for SUITESI in Section 5.2.1 is nice and clear and almost complete . The text on constructing SUITESI in Section 5.2.2 seems to me to be long , complicated , and confusing . I suggest changing the text for SUITESI in Section 5.2.1 to something like " - array of cipher suites which the Initiator supports constructed as specified in Section 5.2.2 " . The change the text in Section 5.2.2 for the SUITESI bullet item to something like : Construct SUITESI as an array of cipher suites which the Initiator supports in order of preference with the first in network byte order being the most preferred and ending with the one selected by I for this session . If the cipher suite most preferred by I is selected then SUITESI contains only that cipher suite and is encoded as an int . All cipher suites , if any , preferred by the Initiator over the selected one MUST be included . ( See also Section 6.3 . ) The selected suite is based on what the Initiator can assume to be supported by the Responder ; however , if the Initiator previously received from the Responder an error message with error code 2 containing SUITESR ( see Section 6.3 ) indicating cipher suites supported by the Responder , then the Initiator SHOULD select its most preferred supported cipher suite among those ( bearing in mind that error messages are not authenticated and may be forged ) . The Initiator MUST NOT change its order of preference for cipher suites and MUST NOT omit a cipher suite preferred to the selected one because of previous error messages received from the Responder . " Figures 11 and 12 , Page 42 : It looks like these figures have gigantic captions of 9 or 10 lines . Is that what you intended ? I think that Figure captions need to be like Section names , usually one line although occasionally two lines is OK . While I do not think it is required for this document , sometimes relatively long RFCs with many figures have a Table of Figures after the Table of Contents ( see RFC 6325 for an example ) ; that would n't work with a 9 - line caption . I suggest changing these to short captions ( maybe " Cipher Suite Negotiation Example 1 " and " Cipher Suite Negotiation Example 2 " although that is n't very specific or creative ) . Then move the current caption text to a paragraph referencing the Figure . Section 8.8 , Page 51 : " a random seed must " -"a random seed MUST " Section 8.8 , Page 53 : There should be a definition or a reference for " Trusted Execution Environment " Section 9 : GENERAL IANA CONSIDERATIONS PROBLEMS If additional values can be specified in future documents , which is true for these registries you are creating , there must be a " Reference " column saying where that value was assigned and its meaning specified . In almost all cases there should be a Reserved value that can be used as some sort of escape if a future extension needs to be defined . I notice that all of these requests to create registries and assign code points are written as if they have already been done but a spot check of several seems to indicate that these have not yet been done by IANA . It is true that an Internet Draft should generally be written so that it reads correctly when published as an RFC . However , I think the IANA Considerations are somewhat of an exception . Because code points are frequently assigned in advance of the publication or approval of a protocol , to avoid confusion between those that have and have not yet been done , the usual wording is to say that IANA is " requested " to do something unless it has actually already been done . So I would re - word all of these as requests ( except for any that have actually been done ) . I would also add text between the 9 . and 9.1 . headers , something like " This Section gives IANA Considerations and , unless otherwise noted , conforms with [ RFC8126 ] . " Then you can pull out all the [ RFC8126 ] references in the Section . Section 9.1 , Page 54 : It is unreasonable to expect IANA to know what a " uint " is or what its range is . It is best to be as explicit and exact as practical in the IANA Considerations so a complete table is better than just a list of a few values . I suggest replacing this Section with something like IANA is requested to create a new registry under the new registry group " Ephemeral    Over COSE ( DHOC ) " as follows : Registry Name : EHOC Exporter Label Assignment Policy : Expert Review Reference : [ this document ] Label Description Reference ------ ---------------------------- --------- 0 Derived OSCORE Master Secret [ this document ] 1 Derived OSCORE Master Salt [ this document ] 2- unassigned Reserved [ this document ] Sections 9.2 , 9.3 , 9.4 , 9.5 , and 9.6 : All of these should be changed in a way analogous to that indicated above . Section 9.11 , Page 60 : In first sentence OLD " Expert Review " NEW " Expert Review " or " Specification Required " Section 9.11 , Page 60 : OLD Specifications are recommended . When specifications are not provided , NEW Even for " Expert Review " specifications are recommended . When specifications are not provided for a request where Expert Review is the assignment policy , Appendix B : I assume " ceil " is the ceiling function but this is not specified anywhere . Suggest adding to the end of the first sentence in which it is used " where ceil(x ) is the smallest integer not less than x " . The following are minor wording issues with the document : Section 1.1 , Page 4 : OLD This specification emphasizes the possibility to reference rather than to transport credentials in order to reduce message overhead , but the latter is also supported . NEW This specification emphasizes the possibility of referencing rather than transporting credentials in order to reduce message overhead , but the latter is also supported . Section 1.3 : Claims to talk about the remainder of the document but says nothing about Appendices B through  ( I do not think it needs to mention K. ( Actually , when I have a " changes " appendix like K I usually label it as " Appendix Z " to make it clear it is not part of the sequence of any other appendices . ) ) Section 3.5.3 , Pages 16/17 , in the two bulleted items : " for the Initiator to retrieve " -"the Initiator retrieving " " for the Responder to retrieve " -"the  retrieving " Section 1.2 , Page 5 , this is just a bit too verbose for my taste : OLD Compared to the DTLS 1.3 handshake [  ] with ECDHE and connection ID , the EDHOC message size when transferred in CoAP can be less than 1/6 when RPK authentication is used , see [ I - D.ietf - lwig - security - protocol - comparison ] . NEW When RPK authentication is used , the EDHOC message size transferred in CoAP can be less than 1/6 that of a DTLS 1.3 handshake [  ] with ECDHE and connection ID [ I - D.ietf - lwig - security - protocol - comparison ] . Section 3.9 , Page 23 : " incompliance " -"noncompliance " ( 2 occurrences ) Section 5.1 , Pages 29/30 : I found the last two sentences of the last paragraph of Section 5.1 a bit confusing and wordy . Suggest the following : OLD This assumes that message duplication due to re - transmissions is handled by the transport protocol , see Section 3.4 . The case when the transport does not support message deduplication is addressed in     deduplication MUST be done by the transport protocol ( see Section 3.4 ) or as described in     , Page 43 : In the next to last sentence " supporting one or both of these is no essential difference " does not read well . Suggest replacing it with " supporting one or both of these is not significantly different " . Section 8.2 , Page 48 : In the last sentence : OLD it is recommended to use a freshly generated authentication key as identity in each initial TOFU exchange . NEW using a freshly generated authentication key as identity in each initial TOFU exchange is RECOMMENDED . Section 8.3 , Pages 48/49 : OLD it is RECOMMENDED to use the same hash algorithm as in the cipher suite but with as much truncation as possible , i.e. , when the EDHOC hash algorithm is SHA-256 it is RECOMMENDED to use  in x5 t and c5 t. NEW using the same hash algorithm as in the cipher suite , but with as much truncation as possible , is RECOMMENDED . That is , when the EDHOC hash algorithm is SHA-256 , using  in x5 t and c5 t is RECOMMENDED . Section 8.8 , Page 54 : OLD It is RECOMMENDED to discontinue the protocol if the received EDHOC message is not deterministic CBOR . NEW Discontinuing the protocol if the received EDHOC message is not deterministic CBOR is RECOMMENDED . Section 9.6 : The table in this section should probably have a figure number and caption since other tables in this document do . Section 9.11 , Page 60 : " approving point assignment " -"approving code point assignment " Appendix C , Page 75 : " implementors to get used to " -"implementors get used to " Thanks ,     3rd +1 - 508 - 333 - 2270 ( cell ) 2386 Panoramic Circle , Apopka , FL USA 
 I totally agree , but I think this differs from depending on academic area and style guide . Especially biology paper often have absurdly long captions . But given that all the other figures follow " Figure captions need to be like Section names " , I think that the captions on figure 9 and 10 should be aligned with the rest of the document . 
 Making a separate issue of the remaining comment from Stephen 's non - nits ( ) 9.4 : As the method field is how we handle breaking changes , do we really want that registry to be specification required ? The alternative might be standards action , if we prefer the IESG to be involved in such changes . This has been discussed . One option is to require standards action for low method numbers . Anyone else has an opinion ? To be clear - I 'm fine with it as - is , but just wanted to check . As it 's been raised on the list , people there can express their opinions as they wish so I do n't see a need to specifically survey opinions further . I would personally prefer that ... 
 This was one of the inputs taken into account in the overhaul of IANA section , see PR . Can we close this issue when we merged that PR ? 
 No comments received , so we close this .
Paragraph (version A):
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
lightweight authenticated key exchange protocol providing good
security properties including forward secrecy, identity protection,
and cipher suite negotiation.  Authentication can be based on raw
public keys (RPK) or public key certificates and requires the
application to provide input on how to verify that endpoints are
trusted.  This specification emphasizes the possibility to reference
rather than to transport credentials in order to reduce message
overhead, but the latter is also supported.  EDHOC does not currently
support pre-shared key (PSK) authentication as authentication with
static Diffie-Hellman public keys by reference produces equally small
message sizes but with much simpler key distribution and identity
protection.
Paragraph (version B):
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
lightweight authenticated key exchange protocol providing good
security properties including forward secrecy, identity protection,
and cipher suite negotiation.  Authentication can be based on raw
public keys (RPK) or public key certificates and requires the
application to provide input on how to verify that endpoints are
trusted.  This specification emphasizes the possibility of
referencing rather than to transport credentials in order to reduce
message overhead, but the latter is also supported.  EDHOC does not
currently support pre-shared key (PSK) authentication as
authentication with static Diffie-Hellman public keys by reference
produces equally small message sizes but with much simpler key
distribution and identity protection.
Paragraph (version A):
Compared to the DTLS 1.3 handshake RFC9147 with ECDHE and connection
ID, the EDHOC message size when transferred in CoAP can be less than
1/7 when RPK authentication is used, see I-D.ietf-lwig-security-
protocol-comparison. fig-sizes shows examples of EDHOC message sizes
based on the assumptions in Section 2 of I-D.ietf-lwig-security-
protocol-comparison, comparing different kinds of authentication keys
and COSE header parameters for identification: static Diffie-Hellman
keys or signature keys, either in CBOR Web Token (CWT) / CWT Claims
Set (CCS) RFC8392 identified by a key identifier using 'kid' RFC9052,
or in X.509 certificates identified by a hash value using 'x5t' I-
D.ietf-cose-x509.
Paragraph (version B):
Examples of EDHOC message sizes are shown in fig-sizes, using
different kinds of authentication keys and COSE header parameters for
identification: static Diffie-Hellman keys or signature keys, either
in CBOR Web Token (CWT) / CWT Claims Set (CCS) RFC8392 identified by
a key identifier using 'kid' RFC9052, or in X.509 certificates
identified by a hash value using 'x5t' I-D.ietf-cose-x509.  As a
comparison, in the case of RPK authentication, the EDHOC message size
when transferred in CoAP can be less than 1/7 of the DTLS 1.3
handshake RFC9147 with ECDHE and connection ID, see Section 2 of I-
D.ietf-lwig-security-protocol-comparison.
Paragraph (version A):
ID_CRED_R is intended to facilitate for the Initiator to retrieve
the authentication credential CRED_R and the authentication key of
R.
Paragraph (version A):
ID_CRED_I is intended to facilitate for the Responder to retrieve
the authentication credential CRED_I and the authentication key of
I.
Paragraph (version B):
ID_CRED_R is intended to facilitate for the Initiator retrieving
the authentication credential CRED_R and the authentication key of
R.
Paragraph (version B):
ID_CRED_I is intended to facilitate for the Responder retrieving
the authentication credential CRED_I and the authentication key of
I.
Paragraph (version A):
Different instances of the same message MUST NOT be processed in one
session.  Note that processing will fail if the same message appears
a second time for EDHOC processing in the same session because the
state of the protocol has moved on and now expects something else.
This assumes that message duplication due to re-transmissions is
handled by the transport protocol, see transport.  The case when the
transport does not support message deduplication is addressed in
duplication.
Paragraph (version B):
Different instances of the same message MUST NOT be processed in one
session.  Note that processing will fail if the same message appears
a second time for EDHOC processing in the same session because the
state of the protocol has moved on and now expects something else.
Message deduplication MUST be done by the transport protocol (see
transport) or, if not supported by the transport, as described in
duplication.
Paragraph (version A):
SUITES_I - array of cipher suites which the Initiator supports in
order of preference, the first cipher suite in network byte order
is the most preferred by I, the last is the one selected by I for
this session.  If the most preferred cipher suite is selected then
SUITES_I contains only that cipher suite and is encoded as an int.
The processing steps are detailed below and in wrong-selected.
Paragraph (version B):
SUITES_I - array of cipher suites which the Initiator supports
constructed as specified in init-proc-msg1.
Paragraph (version A):
The Initiator MUST select its most preferred cipher suite,
conditioned on what it can assume to be supported by the
Responder.
Paragraph (version A):
The selected cipher suite (i.e., the last cipher suite in
SUITES_I) MAY be different between sessions, e.g., based on
previous error messages (see next bullet), but all cipher
suites which are more preferred by I than the selected cipher
suite MUST be included in SUITES_I.
Paragraph (version A):
If the Initiator previously received from the Responder an
error message with error code 2 containing SUITES_R (see wrong-
selected) which indicates cipher suites supported by the
Responder, then the Initiator SHOULD select its most preferred
supported cipher suite among those (bearing in mind that error
messages are not authenticated and may be forged).
Paragraph (version A):
The Initiator MUST NOT change the supported cipher suites and
the order of preference in SUITES_I based on previous error
messages.
Paragraph (version B):
The processing steps are detailed below and in wrong-selected.
Paragraph (version B):
The selected suite is based on what the Initiator can assume to
be supported by the Responder; if the Initiator previously
received from the Responder an error message with error code 2
containing SUITES_R (see wrong-selected) indicating cipher
suites supported by the Responder, then the Initiator SHOULD
select its most preferred supported cipher suite among those
(bearing in mind that error messages are not authenticated and
may be forged).
Paragraph (version B):
The Initiator MUST NOT change its order of preference for
cipher suites, and MUST NOT omit a cipher suite preferred to
the selected one because of previous error messages received
from the Responder.
Paragraph (version A):
Assume that the Initiator supports the five cipher suites 5, 6, 7, 8,
and 9 in decreasing order of preference.  Figures fig-error1 and fig-
error2 show examples of how the Initiator can format SUITES_I and how
SUITES_R is used by Responders to give the Initiator information
about the cipher suites that the Responder supports.
Paragraph (version A):
In the first example (fig-error1), the Responder supports cipher
suite 6 but not the initially selected cipher suite 5.
Paragraph (version A):
Note that the content of the fields of message_1 may be different
when sent the second time, in particular the ephemeral key MUST be
different.
Paragraph (version B):
Assume that the Initiator supports the five cipher suites 5, 6, 7, 8,
and 9 in decreasing order of preference.  Figures fig-error1 and fig-
error2 show two examples of how the Initiator can format SUITES_I and
how SUITES_R is used by Responders to give the Initiator information
about the cipher suites that the Responder supports.
Paragraph (version B):
In Example 1 (fig-error1), the Responder supports cipher suite 6 but
not the initially selected cipher suite 5.  The Responder rejects the
first message_1 with an error indicating support for suite 6 in
SUITES_R.  The Initiator also supports suite 6, and therefore selects
suite 6 in the second message_1.  The Initiator prepends in SUITES_I
the selected suite 6 with the more preferred suites, in this case
suite 5, to mitigate a potential attack on the cipher suite
negotiation.
Paragraph (version B):
In Example 2 (fig-error2), the Responder supports cipher suites 8 and
9 but not the more preferred (by the Initiator) cipher suites 5, 6 or
first make a guess that the Responder supports suite 6 but not suite
first message_1 with an error indicating support for suites 8 and 9
in SUITES_R (in any order).  The Initiator also supports suites 8 and
9, and prefers suite 8, so therefore selects suite 8 in the second
message_1.  The Initiator prepends in SUITES_I the selected suite 8
with the more preferred suites in order of preference, in this case
suites 5, 6 and 7, to mitigate a potential attack on the cipher suite
negotiation.
Paragraph (version B):
Note 1.  If the Responder had supported suite 5, it would have
included it in SUITES_R of the response, and it would in that case
have become the selected and only suite in the second message_1.
Paragraph (version B):
Note 2.  The content of the fields of message_1 may be different when
sent the second time, in particular the ephemeral key MUST be
different.
Paragraph (version A):
Implementations MUST support cipher suite 2 and 3.  Cipher suites 2
(AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-
256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-
16-64-128, SHA-256) only differ in the size of the MAC length, so
supporting one or both of these is no essential difference.
Implementations only need to implement the algorithms needed for
their supported methods.
Paragraph (version B):
Implementations MUST support cipher suite 2 and 3.  Cipher suites 2
(AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-
256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-
16-64-128, SHA-256) only differ in the size of the MAC length, so
supporting one or both of these is not significantly different.
Implementations only need to implement the algorithms needed for
their supported methods.
Paragraph (version A):
leak any long-term identifiers, it is recommended to use a freshly
generated authentication key as identity in each initial TOFU
exchange.
Paragraph (version B):
leak any long-term identifiers, using a freshly generated
authentication key as identity in each initial TOFU exchange is
RECOMMENDED.
Paragraph (version A):
The output size of the EDHOC hash algorithm MUST be at least
256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256
truncated to 64-bits) SHALL NOT be supported for use in EDHOC except
for certificate identification with x5t and c5t.  For security
considerations of SHA-1, see RFC6194.  As EDHOC integrity protects
the whole authentication credentials, the choice of hash algorithm in
x5t and c5t does not affect security and it is RECOMMENDED to use the
same hash algorithm as in the cipher suite but with as much
truncation as possible, i.e., when the EDHOC hash algorithm is
SHA-256 it is RECOMMENDED to use SHA-256/64 in x5t and c5t.  The
EDHOC MAC length MUST be at least 8 bytes and the tag length of the
EDHOC AEAD algorithm MUST be at least 64-bits.  Note that secp256k1
is only defined for use with ECDSA and not for ECDH.  Note that some
COSE algorithms are marked as not recommended in the COSE IANA
registry.
Paragraph (version B):
The output size of the EDHOC hash algorithm MUST be at least
256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256
truncated to 64-bits) SHALL NOT be supported for use in EDHOC except
for certificate identification with x5t and c5t.  For security
considerations of SHA-1, see RFC6194.  As EDHOC integrity protects
the whole authentication credentials, the choice of hash algorithm in
x5t and c5t does not affect security, and using the same hash
algorithm as in the cipher suite, but with as much truncation as
possible, is RECOMMENDED.  That is, when the EDHOC hash algorithm is
SHA-256, using SHA-256/64 in x5t and c5t is RECOMMENDED.  The EDHOC
MAC length MUST be at least 8 bytes and the tag length of the EDHOC
AEAD algorithm MUST be at least 64-bits.  Note that secp256k1 is only
defined for use with ECDSA and not for ECDH.  Note that some COSE
algorithms are marked as not recommended in the COSE IANA registry.
Paragraph (version A):
If supported by the device, it is RECOMMENDED that at least the long-
term private keys are stored in a Trusted Execution Environment (TEE)
and that sensitive operations using these keys are performed inside
the TEE.  To achieve even higher security it is RECOMMENDED that
additional operations such as ephemeral key generation, all
computations of shared secrets, and storage of the PRK keys can be
done inside the TEE.  The use of a TEE aims at preventing code within
that environment to be tampered with, and preventing data used by
such code to be read or tampered with by code outside that
environment.
Paragraph (version B):
If supported by the device, it is RECOMMENDED that at least the long-
term private keys are stored in a Trusted Execution Environment (TEE,
see for example I-D.ietf-teep-architecture) and that sensitive
operations using these keys are performed inside the TEE.  To achieve
even higher security it is RECOMMENDED that additional operations
such as ephemeral key generation, all computations of shared secrets,
and storage of the PRK keys can be done inside the TEE.  The use of a
TEE aims at preventing code within that environment to be tampered
with, and preventing data used by such code to be read or tampered
with by code outside that environment.
Paragraph (version A):
When parsing a received EDHOC message, implementations MUST
discontinue the protocol if the message does not comply with the CDDL
for that message.  It is RECOMMENDED to discontinue the protocol if
the received EDHOC message is not deterministic CBOR.
Paragraph (version A):
IANA has created a new registry entitled "EDHOC Method Type" under
the new registry group "Ephemeral Diffie-Hellman Over COSE (EDHOC)".
The registration procedure is "Specification Required" RFC8126.  The
columns of the registry are Value, Initiator Authentication Key, and
Responder Authentication Key, where Value is an integer and the other
columns are text strings describing the authentication keys.  The
initial contents of the registry are shown in fig-method-types.
Paragraph (version A):
IANA has created a new registry entitled "EDHOC Error Codes" under
the new registry group "Ephemeral Diffie-Hellman Over COSE (EDHOC)".
The registration procedure is "Expert Review" RFC8126.  The columns
of the registry are ERR_CODE, ERR_INFO Type and Description, where
ERR_CODE is an integer, ERR_INFO is a CDDL defined type, and
Description is a text string.  The initial contents of the registry
are shown in fig-error-codes.
Paragraph (version A):
IANA has registered the following entries in the "COSE Header
Parameters" registry under the registry group "CBOR Object Signing
and Encryption (COSE)".  The value of the 'kcwt' header parameter is
a COSE Web Token (CWT) RFC8392, and the value of the 'kccs' header
parameter is a CWT Claims Set (CCS), see term.  The CWT/CCS must
contain a COSE_Key in a 'cnf' claim RFC8747.  The Value Registry for
this item is empty and omitted from the table below.
Paragraph (version A):
IANA has added the well-known URI "edhoc" to the "Well-Known URIs"
registry.
Paragraph (version B):
When parsing a received EDHOC message, implementations MUST
discontinue the protocol if the message does not comply with the CDDL
for that message.  Discontinuing the protocol if the received EDHOC
message is not deterministic CBOR is RECOMMENDED.
Paragraph (version B):
This Section gives IANA Considerations and, unless otherwise noted,
conforms with RFC8126.
Paragraph (version B):
The columns of the registry are Value, Initiator Authentication Key,
and Responder Authentication Key, and Reference, where Value is an
integer and the key columns are text strings describing the
authentication keys.
Paragraph (version B):
The initial contents of the registry are shown in fig-method-types.
Method 23 is Reserved.
Paragraph (version B):
The columns of the registry are ERR_CODE, ERR_INFO Type, Description,
and Reference, where ERR_CODE is an integer, ERR_INFO is a CDDL
defined type, and Description is a text string.  The initial contents
of the registry are shown in fig-error-codes.  Error code 23 is
Reserved.
Paragraph (version B):
The columns of the registry are Name, Label, Description, and
Reference, where Label is a non-negative integer and the other
columns are text strings.  The initial contents of the registry is
shown in fig-ead-labels.  EAD label 23 is Reserved.
Paragraph (version B):
IANA is requested to register the following entries in the "COSE
Header Parameters" registry under the registry group "CBOR Object
Signing and Encryption (COSE)" (see fig-header-params): The value of
the 'kcwt' header parameter is a COSE Web Token (CWT) RFC8392, and
the value of the 'kccs' header parameter is a CWT Claims Set (CCS),
see term.  The CWT/CCS must contain a COSE_Key in a 'cnf' claim
RFC8747.  The Value Registry for this item is empty and omitted from
the table below.
Paragraph (version B):
IANA is requested to add the well-known URI "edhoc" to the "Well-
Known URIs" registry.
Paragraph (version A):
IANA has added the media types "application/edhoc+cbor-seq" and
"application/cid-edhoc+cbor-seq" to the "Media Types" registry.
Paragraph (version B):
IANA is requested to add the media types "application/edhoc+cbor-seq"
and "application/cid-edhoc+cbor-seq" to the "Media Types" registry.
Paragraph (version A):
IANA has added the resource type "core.edhoc" to the "Resource Type
(rt=) Link Target Attribute Values" registry under the registry group
"Constrained RESTful Environments (CoRE) Parameters".
Paragraph (version B):
IANA is requested to add the resource type "core.edhoc" to the
"Resource Type (rt=) Link Target Attribute Values" registry under the
registry group "Constrained RESTful Environments (CoRE) Parameters".
Paragraph (version A):
The IANA Registries established in this document are defined as
"Expert Review".  This section gives some general guidelines for what
the experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude.
Paragraph (version B):
The IANA Registries established in this document are defined as
"Expert Review", "Specification Required" or "Standards Action with
Expert Review".  This section gives some general guidelines for what
the experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude.
Paragraph (version A):
Experts should take into account the expected usage of fields when
approving point assignment.  The length of the encoded value
should be weighed against how many code points of that length are
left, the size of device it will be used on, and the number of
code points left that encode to that size.
Paragraph (version B):
Experts should take into account the expected usage of fields when
approving code point assignment.  The length of the encoded value
should be weighed against how many code points of that length are
left, the size of device it will be used on, and the number of
code points left that encode to that size.