Code change:
2. <del> EDHOC is a 3-message key exchange protocol.  Section 7.2 of I-D.ietf- lake-edhoc specifies how to transport EDHOC over CoAP: the EDHOC data (referred to as "EDHOC messages") are transported in the payload of CoAP requests and responses. </del> <ins> The EDHOC protocol allows two peers to agree on a cryptographic secret, in a mutually-authenticated way and by using Diffie-Hellman ephemeral keys to achieve perfect forward secrecy.  The two peers are denoted as Initiator and Responder, as the one sending or receiving the initial EDHOC message_1, respectively. After successful processing of EDHOC message_3, both peers agree on a cryptographic secret that can be used to derive further security material, and especially to establish an OSCORE Security Context RFC8613.  The Responder can also send an optional EDHOC message_4 to achieve key confirmation, e.g. in deployments where no protected application message is sent from the Responder to the Initiator. Section 7.2 of I-D.ietf-lake-edhoc specifies how to transport EDHOC over CoAP.  That is, the EDHOC data (referred to as "EDHOC messages") are transported in the payload of CoAP requests and responses.  The default message flow consists in the CoAP Client acting as Initiator and the CoAP Server acting as Responder.  Alternatively, the two roles can be reversed.  In the rest of this document, EDHOC messages are considered to be transported over CoAP. fig-non-combined shows a Client and Server running EDHOC as Initiator and Responder, respectively.  That is, the Client sends a POST request with payload EDHOC message_1 to a reserved resource at the CoAP Server, by default at Uri-Path "/.well-known/edhoc".  This triggers the EDHOC exchange at the Server, which replies with a 2.04 (Changed) Response with payload EDHOC message_2.  Finally, the Client sends a CoAP POST request to the same resource used for EDHOC message_1, with payload EDHOC message_3.  The Content-Format of these CoAP messages may be set to "application/edhoc". After this exchange takes place, and after successful verifications as specified in the EDHOC protocol, the Client and Server can derive an OSCORE Security Context, as defined in oscore-ctx of this document.  After that, they can use OSCORE to protect their communications. </ins> <del> This draft deals with the case of the Initiator acting as CoAP Client and the Responder acting as CoAP Server; instead, the case of the Initiator acting as CoAP Server cannot be optimized by using this approach. </del> <ins> As shown in fig-non-combined, this purely-sequential way of first running EDHOC and then using OSCORE takes three round trips to complete. </ins> <del> That is, the CoAP Client sends a POST request containing EDHOC message_1 to a reserved resource at the CoAP Server.  This triggers the EDHOC exchange on the CoAP Server, which replies with a 2.04 (Changed) Response containing EDHOC message_2.  Finally, the CoAP Client sends EDHOC message_3, as a CoAP POST request to the same resource used for EDHOC message_1.  The Content-Format of these CoAP messages may be set to "application/edhoc". </del> <ins> edhoc-in-oscore defines an optimization for combining EDHOC with the first subsequent OSCORE transaction.  This reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. </ins> <del> After this exchange takes place, and after successful verifications specified in the EDHOC protocol, the Client and Server derive the OSCORE Security Context, as specified in Section 7.2.1 of I-D.ietf- lake-edhoc.  Then, they are ready to use OSCORE. </del> <ins> 3. </ins> <del> This sequential way of running EDHOC and then OSCORE is specified in fig-non-combined.  As shown in the figure, this mechanism takes 3 round trips to complete. </del> <ins> When using EDHOC over CoAP for establishing an OSCORE Security Context, EDHOC messages are exchanged as defined in Section 7.2 of I- D.ietf-lake-edhoc, with the following addition. </ins> <del> The number of roundtrips can be minimized as follows.  Already after receiving EDHOC message_2 and before sending EDHOC message_3, the CoAP Client has all the information needed to derive the OSCORE Security Context. </del> <ins> EDHOC error messages sent as CoAP responses MUST be error responses, i.e. they MUST specify a CoAP error response code.  In particular, it is RECOMMENDED that such error responses have response code either 4.00 (Bad Request) in case of client error (e.g. due to a malformed EDHOC message), or 5.00 (Internal Server Error) in case of server error (e.g. due to failure in deriving EDHOC key material). </ins> <del> This means that the Client can potentially send at the same time both EDHOC message_3 and the subsequent OSCORE Request.  On a semantic level, this approach practically requires to send two separate REST requests at the same time. </del> <ins> 4. </ins> <del> The high level message flow of running EDHOC and OSCORE combined is shown in fig-combined. </del> <ins> After successful processing of EDHOC message_3 (see Section 5.5 of I- D.ietf-lake-edhoc), the Client and Server derive Security Context parameters for OSCORE (see Section 3.2 of RFC8613) as follows. The Master Secret and Master Salt are derived by using the EDHOC- Exporter interface defined in Section 4.1 of I-D.ietf-lake-edhoc. The EDHOC Exporter Labels to use are "OSCORE Master Secret" and "OSCORE Master Salt", for deriving the OSCORE Master Secret and the OSCORE Master Salt, respectively. By default, key_length is the key length (in bytes) of the application AEAD Algorithm of the selected cipher suite for the EDHOC session.  Also by default, salt_length has value 8.  The Initiator and Responder MAY agree out-of-band on a longer key_length than the default and on a different salt_length. The AEAD Algorithm is the application AEAD algorithm of the selected cipher suite for the EDHOC session. The HKDF Algorithm is the HKDF algorithm of the selected cipher suite for the EDHOC session. In case the Client is the Initiator and the Server is the Responder, the Client's OSCORE Sender ID and the Server's OSCORE Sender ID are the byte string EDHOC connection identifier C_R and C_I for the EDHOC session, respectively.  The reverse applies in case the Client is the Responder and the Server is the Initiator. Numeric connection identifiers are converted to (naturally byte- string shaped) Sender IDs by using their CBOR encoded form.  For example, a C_R of 10 corresponds to a (typically server) Sender ID of hexadecimal '0a', -12 to hexadecimal '2b', whereas a byte- string valued C_R of h'ff' corresponds to a Sender ID of hexadecimal 'ff'. Before deriving an OSCORE Security Context, the two peers MUST ensure that the EDHOC connection identifiers are different. that is, the two peers MUST NOT derive an OSCORE Security Context from an EDHOC session, if C_R is equal to C_I for that session. If the Responder runs EDHOC with the intention of deriving an OSCORE Security Context, the Responder MUST NOT include in EDHOC message_2 a connection identifier C_R equivalent (under conversion to a Sender ID) to the connection identifier C_I received in EDHOC message_1.  If the Initiator runs EDHOC with the intention of deriving an OSCORE Security Context, the initiator MUST discontinue the protocol and reply with an EDHOC error message when receiving an EDHOC message_2 that includes a connection identifier C_R equal to C_I. The Client and Server use the parameters above to establish an OSCORE Security Context, as per Section 3.2.1 of RFC8613. From then on, the Client and Server MUST be able to retrieve the OSCORE protocol state using its chosen connection identifier, and optionally other information such as the 5-tuple, i.e., the tuple (source IP address, source port, destination IP address, destination port, transport protocol). </ins> <del> Defining the specific details of how to transport the data and of their processing order is the goal of this specification, as defined in edhoc-in-oscore. </del> <ins> 5. </ins> <del> 3. </del> <ins> This section defines an optimization for combining the EDHOC exchange with the first subsequent OSCORE transaction, thus minimizing the number of round trips between the two peers. This approach can be used only if the default EDHOC message flow is used, i.e., when the Client acts as Initiator and the Server acts as Responder, while it cannot be used in the case with reversed roles. When running the purely-sequential flow of overview, the Client has all the information to derive the OSCORE Security Context already after receiving EDHOC message_2 and before sending EDHOC message_3. Hence, the Client can potentially send both EDHOC message_3 and the subsequent OSCORE Request at the same time.  On a semantic level, this requires sending two REST requests at once, as in fig-combined. To this end, the specific approach defined in this section consists of sending EDHOC message_3 inside an OSCORE protected CoAP message. The resulting EDHOC + OSCORE request is in practice the OSCORE Request from fig-non-combined, as still sent to a protected resource and with the correct CoAP method and options, but with the addition that it also transports EDHOC message_3. As EDHOC message_3 may be too large to be included in a CoAP Option, e.g., if containing a large public key certificate chain, it has to be transported in the CoAP payload of the EDHOC + OSCORE request. The rest of this section specifies how to transport the data in the EDHOC + OSCORE request and their processing order.  In particular, the use of this approach is explicitly signalled by including an EDHOC Option (see edhoc-option) in the EDHOC + OSCORE request.  The processing of the EDHOC + OSCORE request is specified in client- processing for the Client side and in server-processing for the Server side. </ins> <del> This section defines the EDHOC Option, used in a CoAP request to signal that the request combines EDHOC message_3 and OSCORE protected data. </del> <ins> 5.1. This section defines the EDHOC Option.  The option is used in a CoAP request, to signal that the request payload conveys both an EDHOC message_3 and OSCORE protected data, combined together. </ins> The EDHOC Option has the properties summarized in fig-edhoc-option, which extends Table 4 of RFC7252.  The option is Critical, Safe-to-

Related discussion:
text: Clean-up after URL As the content-from-edhoc branch seems to be the most up-to-date one (in which the parts changed are introduced in the first place), this builds on , and only the latest commit is actually relevant.
Compared to the original bstridentifier mapping, this is a different int-to-bstr mapping, but one that's most likely efficient to implement. I have not made any statement on the efficiencies, but some guidance we could give is that from a coding density point of view, numeric Cx should only be used with -24..23; for all other values, doing it in a bstr is just as good and saves a byte in OSCORE. (In fact we may want to make that normative, so that only the single-byte case needs to be implemented where this needs explicit implementation).