Code change:
<del> Combining EDHOC and OSCORE </del> <ins> Using EDHOC for OSCORE with CoAP Transport </ins> draft-ietf-core-oscore-edhoc-latest Abstract <del> This document defines an optimization approach for combining the lightweight authenticated key exchange protocol EDHOC run over CoAP with the first subsequent OSCORE transaction.  This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. </del> <ins> This document defines how the lightweight authenticated key exchange protocol EDHOC is used for establishing an OSCORE Security Context, using CoAP for message transferring.  Furthermore, this document defines an optimization approach for combining EDHOC run over CoAP 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> 1. <del> This document defines an optimization approach to combine the lightweight authenticated key exchange protocol EDHOC I-D.ietf-lake- edhoc, when running over CoAP RFC7252, with the first subsequent OSCORE RFC8613 transaction. </del> <ins> Ephemeral Diffie-Hellman Over COSE (EDHOC) I-D.ietf-lake-edhoc is a lightweight authenticated key exchange protocol, especially intended for use in constrained scenarios.  As defined in Section 7.2 of I- D.ietf-lake-edhoc, EDHOC messages can be transported over the Constrained Application Protocol (CoAP) RFC7252. </ins> <del> This allows for a minimum number of round trips necessary to setup the OSCORE Security Context and complete an OSCORE transaction, for example when an IoT device gets configured in a network for the first time. </del> <ins> This document builds on the EDHOC specification I-D.ietf-lake-edhoc and defines how EDHOC run over CoAP is used for establishing a Security Context for Object Security for Constrained RESTful Environments (OSCORE) RFC8613. In addition, this document defines an optimization approach that combines EDHOC run over CoAP with the first subsequent OSCORE transaction.  This allows for a minimum number of round trips necessary to setup the OSCORE Security Context and complete an OSCORE transaction, for example, when an IoT device gets configured in a network for the first time. </ins> This optimization is desirable, since the number of protocol round trips impacts the minimum number of flights, which in turn can have a

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).