# Next steps on -core-oscore-edhoc

[toc]

---

https://datatracker.ietf.org/doc/draft-ietf-core-oscore-edhoc/

Comments marked as "DONE-2" are resolved according to what was discussed at the 2023-03-01 CoRE interim meeting, see https://notes.ietf.org/notes-ietf-interim-2023-core-04-core?both=#Profiling-EDHOC-for-CoAP-and-OSCORE

Comments marked as "TODO-EDHOC" are intended to be addressed in draft-ietf-lake-edhoc, as discussed at the 2023-03-01 CoRE interim meeting, see https://notes.ietf.org/notes-ietf-interim-2023-core-04-core?both=#Profiling-EDHOC-for-CoAP-and-OSCORE

## Editorial (DONE)

* Align with the EDHOC terminology

- "Forward message flow" and "Reverse message flow"
- See https://github.com/core-wg/oscore-edhoc/commit/c70a79895c5d93810c9b219d936540b84215b91a

- s/exchange/session (when it makes sense)
- See https://github.com/core-wg/oscore-edhoc/commit/b6a63f7a05ac8c2fbc4057a82130080477e33a14

## Names of the target attributes (DONE-2)

The target attributes defined in [Section 6](https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-edhoc-06#name-web-linking) are all specific to EDHOC, so their name can start with a common, related prefix, e.g., "edhoc-"

This would of course make the names longer.

**MT**: How about "ed-", "edh-" or "ec-"? The latter is in the same spirit of "ct" for Content-formaT, and it should still not create confusion with "ecc" (elliptic curve cryptography).

**Resolution**: "ed-" should be good enough --> raise at the interim meeting --> Confirmed

**Github Commit**:
https://github.com/core-wg/oscore-edhoc/commit/f71dae4f78c17f943205b639dae26b7492198678

https://github.com/core-wg/oscore-edhoc/commit/4abe6965994d0e78152e6f4b7ef93275bedb17fc

## Christian's comments from WGLC

https://mailarchive.ietf.org/arch/msg/core/Rs9EMsszA-QzRue7QJDIZN280WU/

I have a few comments and questions on the document. They'r in linear sequence; I hope to not reiterate too much on points that have been discussed exhaustively (as I'm not up to date on all threads pertaining to the document).

None are particularly critical (AIU it's the chairs' call whether something blocks a WGLC anyway, I think most outcomes can be addressed post-WGLC), although I'd like to see at least the Section 6 example addressed.

### Section 2 (DONE)

Section 2 might profit from an introductory line along the lines of

| This section (is not normative and?) summarizes what is specified in
| [I-D.ietf-lake-edhoc], in particular its Appendix A.2, and thus
| provides a base-line for the enhancements in the subsequent
| sections.

**MT**: I think it's good to add the proposed text as first sentence of Section 2.

**Resolution**: Add the slightly edited paragraph at the beginning of Section 2.

> This section is not normative and summarizes what is specified in [I-D.ietf-lake-edhoc], in particular its Appendix A.2. Thus, it provides a baseline for the enhancements in the subsequent sections.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/c661474f08e4ee859d1ba280e1949a74b6d88317

### Section 3.1 (DONE)

Figure 4 (full coAP message):

* There might also be CoAP options before the EDHOC option, in particular Observe.

**MT**: We can redraw the figure to have the Observe option included before the OSCORE option; and update the caption of the figure to say "Example of CoAP message for ..."

**Resolution**: Figure redrawn to be as follows.

Note that the outer Observe option in this EDHOC+OSCORE request is exactly for registering an observation, hence it is of exactly 1 byte in size, and it is overall encoded as 0x30. That is, its header is 0x06 (delta:6, length 0) and its value is 0x00 (hence it is omitted).

~~~~~~~~~~~~~~~~~
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observe Option| OSCORE Option ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EDHOC Option | Other Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~~~~~~~~~~~~~~~~~

Rephrased text:

> Figure 4 shows an example of CoAP message containing ...

Rephrased figure caption:

> Figure 4: Example of CoAP message for EDHOC and OSCORE combined, signalled with the EDHOC Option.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/351e5b038670a91860a799d772097ae0f1f7a7a5

### Section 3.1 (DONE)

* Could you add something about "example" in here? Such a message could be sent over any transport, such as CoAP-over-TCP, and then some of that figure doesn't apply.

**MT**: I think it's good to append the suggested text to the paragraph right before Figure 4, and consistently expand the caption of the figure to mention UDP. On the other hand, such a clarification would become generally expected in any document showing an example of CoAP message.

**MT**: The same clarification should be given also in Section 3.4, when providing the assumptions on which we build the example message.

**Resolution**: Do it.

Revised text in Section 3.1:

> Figure 4 shows an example of CoAP message transported over UDP and containing both the EDHOC data and the OSCORE ciphertext, using the newly defined EDHOC option for signalling.

Revised caption of Figure 4:

> Figure 4: Example of CoAP message transported over UDP, combining EDHOC data and OSCORE data as signalled with the EDHOC Option.

Revised text in Section 3.4

> Figure 5 shows an example of EDHOC + OSCORE Request transported over UDP. In particular, the example assumes that:

Revised caption of Figure 5:

> Figure 5: Example of CoAP message transported over UDP, combining EDHOC data and OSCORE data as signalled with the EDHOC Option.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/82e8432b37708e994424c850c4ddee24205d7637

### Section 3.2 (DONE)

3.2 Client processing: This speaks of an "original CoAP message". I know from context what is meant, but the term could be more descriptive. Maybe "Encrypt the first application CoAP request as an original message per Section 8.1"?

(The term reappears in 3.2.1 Supporting Block-wise).

**MT**: In Section 3.2.0, I think it is fine to say "Encrypt the first application CoAP request as an original message to protect, as per Section 8.1 of [RFC8613], using ...".

**MT**: In Section 3.2.1, that should be:

* "If Block-wise [RFC7959] is supported, the client may fragment the first application CoAP request before protecting it as an original message with OSCORE, as defined in Section 4.1.3.4.1 of [RFC8613]. In such a case, the OSCORE processing in step 2 of Section 3.2 is performed on each inner block of the first application CoAP request, and the following also applies."

* "A. If the OSCORE-protected request from step 2 conveys a non-first inner block of the first application CoAP request (i.e., the Block1 Option processed at step 2 ..."

**Resolution**: Do it.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/114cec4a5d3ebe7fc5983f20621a58a0f30551ff

### Section 3.2 (DONE)

3.2 step 3: "The first CBOR byte string is the EDHOC message_3 resulting from step 1." could tempt an implementer to encode the message_3 into a bstr; I take it that the intention is to send CIPHERTEXT_3 in only one layer of byte strings.

I therefore suggest the wording:

| [...] composed of two CBOR items in the following order.
|
| The first CBOR item is the single item of EDHOC_message_3 (which is
| CIPHERTEXT_3, a byte string).

**Related comment from Carsten, summarized below**: https://mailarchive.ietf.org/arch/msg/core/JkFi7e7RXZuClkdT8tP1l6vAgJM/

> "Byte string": the generic data model data item with that name (using major type 2 and enclosing a sequence of bytes into a single data item). --> E.g., h'010203'
>
> "Encoded CBOR data item" to describe the sequence of bytes that results from encoding a CBOR data item. --> E.g., 0x43010203
>
> It is really important not to confuse "CBOR byte string" with "encoded CBOR data item”".

**MT**: It looks good to use the suggested words, although as:

> "The first CBOR data item is EDHOC message_3 (which is CIPHERTEXT_3, i.e., a CBOR byte string)."

**MT**: I am not sure if Carsten's comment was intended just for completeness, or if he is actually suggesting yet a different wording.

**Resolution**: Do it.

In Sections 3.2:

> Build a CBOR sequence [RFC8742] composed of two CBOR data items in the following order.

> The first CBOR data item is the single data item of EDHOC message_3 resulting from step 1. As per Section 5.4.1 of [I-D.ietf-lake-edhoc], such a data item is CIPHERTEXT_3, which is a CBOR byte string.

> The second CBOR data item is a CBOR byte string, with value the OSCORE ciphertext of the OSCORE protected CoAP request resulting from step 2.

In Section 3.3:

> Extract EDHOC message_3 from the payload of the EDHOC + OSCORE request, as the first CBOR data item in the CBOR sequence.

> Extract the OSCORE ciphertext from the payload of the EDHOC + OSCORE request, as the value of the CBOR byte string specified as second CBOR data item in the CBOR sequence.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/1ae47edbbbd57e016843f354d82c60a20ad50df0

### Section 3.2 (DONE-2)

3.2 step 3: I missed that at some point in the evolution of this protocol, prefixing the (non-CBOR) OSCORE message with a CBOR stream.

This seems unnecessary to me, given that the previosu EDHOC_message_3 is well delimited, and the OSCORE message can well be the bytes to the end (a concept for which has been taken up in RFC9277 for CBOR-labeled non-CBOR data), and will typically waste 2-3 bytes (rarely 1 -- for that, the full OSCORE message needs to fit in 24 bytes).

Was there a particular reason for this change?

**MT**: This is not the result of a change. The current design was considered from the start in version -00 of the individual submission. There has been no real discussion about it, but it is certainly convenient from an implementation point of view on the server side, that can possibly rely on library methods for splitting elements of a CBOR sequence.

**MT**: Anyway, the above makes sense and practically saves bytes (often 2 or 3); I think it's a good change. This means that:

* This section should define the payload of the combined request as composed of EDHOC message_3 (as a CBOR data item of type byte string), followed by the payload of the first OSCORE-protected CoAP request (i.e., the OSCORE ciphertext).

* Accordingly rephrase steps 1, 2 and 6 of Section 3.3 "Server Processing".

* Accordingly revise the example shown in Figure 5 of Section 3.4.
* The second part of the CoAP payload is not the encoded CBOR data item 0x4d612f1092f1776f1c1668b3825e, but instead simply the OSCORE ciphertext 0x612f1092f1776f1c1668b3825e.
* The total message size changes from 57 to 56 bytes.

**Resolution**: Do it. --> Raise at the interim meeting --> Confirmed

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/a7a057bea7dd0b1253a1b4c35764f3cd7a65fe9f

### Section 3.2.1 (DONE)

3.2.1 item A is quite a mouth-ful to say that "On Inner Block-wise, 3.2 only applies to the first block", but I see that given how the rest is phrased, it is unavoidable.

Maybe using the term "first application CoAP request" suggested above opens an avenue for making this easier to comprehend.

**MT**: Yes. As discussed above, the text in Section 3.2.1, that should be:

* "If Block-wise [RFC7959] is supported, the client may fragment the first application CoAP request before protecting it as an original message with OSCORE, as defined in Section 4.1.3.4.1 of [RFC8613]. In such a case, the OSCORE processing in step 2 of Section 3.2 is performed on each inner block of the first application CoAP request, and the following also applies."

* "A. If the OSCORE-protected request from step 2 conveys a non-first inner block of the first application CoAP request (i.e., the Block1 Option processed at step 2 ..."

**Resolution**: Do it.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/114cec4a5d3ebe7fc5983f20621a58a0f30551ff

### Section 3.3.0 (DONE-2)

"If the decrypted request includes an EDHOC option but it does not include an OSCORE option, the server MUST stop processing the request and MUST reply with a 4.00 (Bad Request) error response."

My understanding of this sentence is that EDHOC's criticality applies after decryption again, and a server must not silently ignore an inner EDHOC option without a matching OSCORE option.

While this is in the right scope for a message it processes as an end-to-end message, it is out of scope if we're in a oscore-proxies situation (which of course we don't have normatively yet, but I don't want this to bite us later -- it could bite if, for example, the inner OSCORE connection with the origin server used some OSCORE-version-2 with a dedicated option that our proxy doesn't need to know).

I suggest the following wording instead:

| When the decrypted request is checked for any critical options (as
| it is during regular CoAP processing), the presence of an EDHOC
| option MUST be regarded as an unprocessed critical option, unless it
| is processed by some further mechanism.

(The current phrasing implies that an inner OSCORE option could be processed, which is currently still forbidden; this wording avoids that while leaving the door open).

**MT**: This took a long time to digest. I think the proposed text is good to use.

Indeed, the current phrasing was motivated by -oscore-capable-proxies, but the multiple OSCORE protection is still officially forbidden. Also, there may be future evolutions such that:

* C and S use OSCOREv2 end-to-end, based on an updated OSCORE option and possible new OSCOREv2-related options.
* C and P use OSCOREv1 as defined in oscore-capable-proxies

In a chain of proxies using nested EDHOC+OSCORE requests and nested OSCORE protection, we do want a similar consistency check to be performed on the decrypted request, but it is not going to necessarily be based on seeing the EDHOC option paired solely and specifically with the OSCORE option as we know it today. Hence, it is good to keep the formulation general here in -core-oscore-edhoc.

**Resolution**: Do it --> raise at the interim meeting --> confirmed

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/23787afc0352e48a7d1a3c7c2678df5f87341064

### Section 3.4 (DONE)

"The EDHOC option is registered with CoAP option number 21.": This line could take a note that the RFC editor should remove this line (as at time of publication, this will be a registered fact and not an assumption).

**MT**: Yes, we can add the following text right after the first bullet list.

> Note to RFC Editor: Please delete the last bullet point in the previous list, since, at the time of publication, the CoAP option number will be in fact registered.

**Resolution**: Do it.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/88f88b99a5e26c0cc7c4ac0fe1476a599b503364

### Section 4.1 (DONE)

4.1. Additional Processing of EDHOC Messages: So far, this document offers an additional mechanism; now suddenly we get universal normative requirements. When do these apply? My assumption is that

| When using EDHOC to establish an OSCORE context, client and server
| MUST perform additional steps during EDHOC, extending Section 5 of
| EDHOC:

(They feel much more like a "needs to" to me, because they all stem from requirements in the cited documents, but this sounds like a "MUST" that someone insisted on at some point, which I won't fight).

**MT**: Indeed; we can go for this slightly edited version of Christian's text:

> When using EDHOC to establish an OSCORE Security Context, the client and server MUST perform the following additional steps during an EDHOC execution, thus extending Section 5 of [I-D.ietf-lake-edhoc].

**Resolution**: Do it.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/efb4103475f566b76f88e63f1eaf4bf21bb19ded

### Section 4.1.1 (DONE)

4.1.1: This reads needlessly imperative to me -- what does the looping process give that a simple

| The initiator MUST choose a C_I that is neither used in any current
| EDHOC exchange as this party's identifier, nor the Recipient ID in
| a current OSCORE context whose ID Context is zero-length. The chosen
| C_I SHOULD not be the Recipient ID of any current OSCORE context.

does not give?

Same goes for section 4.1.2, where the "neither" group gains the C_I as an extra clause.

(The concept of atomicity is not really needed when phrasing it as a closed expression rather than an imperative program).

By the way, there is a subtle error that the above text would fix compared to the current text: "If ID* is already used as EDHOC Connection Identifier C_I," is only looking at our C_I, but it'd need to also look at our C_R for the host can concurrently be in an EDHOC exchange where roles are reversed.

**MT**: Yes, that's much better. After some minor editing, and considering a comment from John at https://mailarchive.ietf.org/arch/msg/core/n6Kmomt6znH8y52C1-v3ufz7yPI/ , we have the following new text.

* The content of Section 4.1.1 becomes:

> The Initiator selects an EDHOC Connection Identifier C_I as follows.
>
> The Initiator MUST choose a C_I that is neither used in any current EDHOC session as this peer's EDHOC Connection Identifier, nor the Recipient ID in a current OSCORE Security Context where the ID Context is not present.
>
> The chosen C_I SHOULD NOT be the Recipient ID of any current OSCORE Security Context.

* The content of Section 4.1.2 becomes:

> The Responder selects an EDHOC Connection Identifier C_R as follows.
>
> The Responder MUST choose a C_R that is neither used in any current EDHOC session as this peer's EDHOC Connection Identifier, nor is equal to the EDHOC Connection Identifier C_I specified in the EDHOC message_1 of the present EDHOC session (i.e., after its decoding as per Section 3.3 of [I-D.ietf-lake-edhoc]), nor is the Recipient ID in a current OSCORE Security Context where the ID Context is not present.
>
> The chosen C_R SHOULD NOT be the Recipient ID of any current OSCORE Security Context.

**Resolution**: Do it.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/7562931fa912523ea83bb00cfd6c14b74423acb2

### Section 6 (DONE-2)

Section 6: I would not expect to have much need of that content, but trust that thought went into potential use cases.

A property that I'd be missing if I wanted to plan a complete EDHOC exchange ahead is whether or not the forward or the reverse message flow is supported.

**MT**: This is easy to address. We can define two further target attributes "ed-fflow" and "ed-rflow" with no value. Their presence would signal the support of the server for the respective message flow.

**MT**: There is another thing we're missing, i.e., signalling whether the CoAP server can act as Initiator, or Responder, or both. This can be signalled with two further target attributes with no value, namely "ed-i" and "ed-r".

**Resolution**: Do it. --> raise at the interim meeting --> confirmed, but just have "ed-r" and "ed-i", well defining what that means. Since they are signalled in the link to a resource at a server, they also signal the EDHOC execution flows that that server supports.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/7d394c1a96e1a110aadf72f2b19473947a01f54d

---

(If I used things that way I'd also want to know, for the cred-t=cwt case, which AS's tokens the server would accept, but that's probably for the ACE EDHOC profile).

**MT**: I don't see a relation between CWTs used as authentication credentials specifically, and the Access Tokens for access rights issued by the AS. If the point is about knowing which AS to contact, that's no different than in other transport profiles of ACE, and it's a discovery problem to address, e.g., with the AS Creation Hints error response or with link fetching from a Resource Directory.

**Resolution**: Take separately to Christian; how is this related to cred-t=cwt in the first place?

### Section 6 (TODO-EDHOC)

EDHOC treats application profiles like something that is defined by an application (be it as in some-piece-of-software or as in some-SDO-protocol), where the set of acceptable methods etc. follows from what that application says. Wouldn't it make more sense to guide those who define application protocols to how to make the application-protocol-as-a-whole discoverable (maybe by declaring rt="core.edhoc my-sdo.edhocprofile", or using a dedicated attribute) rather than detailing out every single property that profile has?

I wouldn't expect a device to just go around willy-nilly attempting to use any profile where the shoe fits. I'd expect it to know what it wants to do (which profile it wants to use), and then search precisely for a resource that'll do that profile (and expect the peer to heed what's specified in there).

**MT**: I think that the two signalling approaches are not mutually exclusive.

The approach proposed in the comment is useful if a "canonical" application profile has been defined in terms of its features, and its name has been registered. I think a registry about EDHOC application profiles is better defined in the EDHOC specification and inherited here.

If an EDHOC resource adheres to such an official application profile with a given name, then it is useful to signal that via web-linking.

* I don't think it should be done with the rt= target attribute, which should still have value "core.edhoc", also consistently with the [EDHOC specification](https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-19#section-9.10).

* As also suggested, we can instead define a new target attribute "ed-prof", with value the name of the application profile associated with the EDHOC resource.
* Since multiple EDHOC application profiles might have been independently defined and that they can be only partially overlapping in terms of features, this target attribute can occur multiple times in a link, as long as the co-existence of such application profiles on the same EDHOC resource is conflict-free. The constraint on non-conflicting application profiles on the same EDHOC resource is also better defined in the EDHOC specification and inherited here.

* If the union of the signalled EDHOC application profiles covers everything that the EDHOC resource supports in terms of EDHOC features, then there is indeed no reason to add further target attributes indicating the individual features.
* I suspect that this might not apply to all the considered target attributes. I'm thinking especially of the signalled, supported EAD items, which can be defined stand-alone at any time, without necessarily referring to an EDHOC application profile.

**Resolution**: Overall good to do --> raise at the interim meeting. Also, where to define the IANA registry? In this document or in the EDHOC specification? The latter is better, since the EDHOC specification is also likely to define and register a first, well-known EDHOC application profile.

**Outcome from the CoRE interim meeting**: Better to define the new registry in the EDHOC draft. If that happens, a new target attribute "ed-prof" can be registered at any time.

**Github Commit**: None

### Section 6 (DONE-2)

Figure 6 (The Web Link) gives an example with multiple EDHOC resources, without giving any plausible reason for why different profiles would be in place. (Note that a single EDHOC resource should very well be capable of serving even two different application profiles).

This kind of example has a tendency to be copied over into people's setups without much thought, so the thought needs to go in now.

I suggest taking one of two routes:

* Explain why there would be two distinct EDHOC resources, or
* preferred: just describe the /.well-known/edhoc resource

**MT**: On the part of the comment

> Note that a single EDHOC resource should very well be capable of serving even two different application profiles

Sure, as long as the union of the profiles associated with the EDHOC resource is conflict-free.

A very concrete reason to have multiple resources with different application profiles is that those cannot be "merged" as conflicting. For example, if the server supports EDHOC message_4 and the EDHOC+OSCORE combined request:

* One EDHOC resource can be associated with an application profile that mandates the use of EDHOC message_4, with which the possible use of the EDHOC+OSCORE combined request is not compatible.

* Another EDHOC resource can be associated with an application profile where it is fine for a client to use the EDHOC+OSCORE combined request, which implies that the use of EDHOC message_4 is not mandated.

That said, we should ensure to not give the impression that only one application profile can be associated with an EDHOC resource.

**MT**: What we have today is:

> REQ: GET /.well-known/core
>
> RES: 2.05 Content
> </sensors/temp>;osc,
> </sensors/light>;if="sensor",
> </edhoc/resA>;rt="core.edhoc";csuite="0";csuite="2";method="0";
> cred-t="c509";cred-t="ccs";idcred-t="4";comb-req,
> </edhoc/resB>;rt="core.edhoc";csuite="0";csuite="2";method="0";
> method="3";cred-t="c509";cred-t="x509";idcred-t="34"

**MT**: Regardless the discussion above, I would also prefer to describe the /.well-known/edhoc resource as Christian suggests. This is exactly what we had until [version -02](https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-edhoc-02#name-web-linking), i.e.:

REQ: GET /.well-known/core

RES: 2.05 Content
    </sensors/temp>;osc,
    </sensors/light>;if="sensor",
    </.well-known/edhoc>;rt="core.edhoc";csuite="0";csuite="2";
    method="0";cred_t="c509";cred_t="ccs";idcred_t="4";comb_req;ed_prof="default"

This was presented at the [CoRE interim meeting on 2021-10-27](https://datatracker.ietf.org/doc/minutes-interim-2021-core-13-202110271600/), where Esko suggested to avoid ./well-known/core as it is a well known resource, and Christian agreed.

> ED: better to not use /.well-known/edhoc in the example; that would suppose to be a well-known resource so a client knows how it works.
> RH: yes, of course the server can have more resources than that only
> (CA on Jabber: +1 on that)

At the time, I was not fully convinced of the change and I'd be happy to revert it. What I think is well known is not the EDHOC application profile associated with the EDHOC resource (as Esko suggested), but only the URI path of that resource.

Opening for a well known EDHOC application profile is in fact a separate point that comes later in the final comment from Christian.

**Resolution**: Sounds good --> raise at the interim meeting --> confirmed

**Github Commit**:

https://github.com/core-wg/oscore-edhoc/commit/6794c7878306530b3daa88f388f0173c73c3f0f8

https://github.com/core-wg/oscore-edhoc/commit/20d849b3593c86fea1297b615b1c7966342603c8

### Section 6 (DONE)

Figure 6 The Web Link: None of the values in here need quotation marks around them.

**MT**: The rule behind this is not fully clear to me.

The comment from Christian is consistent with the examples given for the [CoRE Resource Directory](https://datatracker.ietf.org/doc/html/rfc9176), where quotation marks are used only for the value of some target attributes, i.e.:

* anchor= and base=
* ct= and title=, only when taking multiple values separated by a space
* if= , rt= and et=, only when taking multiple values separated by a comma

However, some other documents with similar examples use quotation marks instead. See, for instance:

* Link-format, in https://www.rfc-editor.org/rfc/rfc6690#section-5
* OSCORE, in https://www.rfc-editor.org/rfc/rfc8613#section-9

**Resolution**: Will fix. After checking with Christian, it is never wrong to have double quotes, but it is often not necessary. For everything that's not weird (e.g., the "anchor" attribute), ABNF says that there needs to be quotes when there's any non-URI character (e.g., ',', ';', ' '). If there's a comma or semicolon, it's practically required to add quotes.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/406e0056424976890006d506114d22c42d3d58aa

### Appendix A (DONE)

Appendix A: Sorry, didn't check this one.

Frankly, I think this is a bit excessive, and would be more suitable for an LWIG document, or the detailed documentation of an EDHOC library.

**MT**: No strong opinion; we can remove it. To be fair, this sorts of considerations seemed to be wanted by Jim when this work started, see https://mailarchive.ietf.org/arch/msg/core/mxtyDp69EbR5kVIrTBXl_WWVCG4/

> I think there needs to be some discussion about the fact that the MTU needs to be taken into account based on the two message sizes as once you have gone to a blockwise situation then there is no win for combining the two messages.

**MT**: In the spirit of Christian's suggestion, this content can be part of the LAKE draft on implementation considerations.

**Resolution**: Give a general, high-level statement around "the performance advantage of using the combined request can be lost when used in combination with Block-Wise transfers and specific values of used parameters and block sizes". The Appendix content can be moved to the LAKE document about EDHOC implementation considerations.

Add the following at the end of Section 3.2.1 "Supporting Block-wise".

> The performance advantage of using the EDHOC + OSCORE request can be lost, when used in combination with Block-wise transfers that rely on specific parameter values and block sizes.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/ae2aae2894d23c3eb03810f554bb98c7b374119b

### General (TODO-EDHOC)

General: I'm not sure whether it would make sense to define a general application profile for "Let's talk OSCORE over CoAP", that allows everything that works for EDHOC-OSCORE, and is what /.well-known/edhoc would default to.

**MT**: I'm not sure to grasp all the implications of this.

As I understand also from a related comment above, it seems that this is about:

* First of all, defining a well-known EDHOC application profile, with an associated name. Its name would also be usable as value of a dedicated target attribute "ed-prof", for signaling application profiles in a link to an EDHOC resource.
* This opens for an IANA registry where the names of EDHOC application profiles would have to be registered, as pointing to the specifications where they are defined. As per a previous comment, this registry is better created by the EDHOC specification, which would also be better take care of defining the well-known profile (although, this can admittedly come separately later on).

* Second, defining that any EDHOC resource (not only /.well-known/edhoc) is by default associated with that well-known EDHOC application profile, unless otherwise indicated by means of at least one "ed-prof" target attribute signaling a different EDHOC application profile.
* Regardless, further single-feature target attributes can be specified in the link, as long as no conflict is created with the EDHOC features of the signalled/implied EDHOC application profiles.

Also, what does "everything that works for EDHOC-OSCORE" actually include and how is it supposed to keep-up with possible updates to EDHOC, CoAP and OSCORE? At least as a starting point, this should be aligned with the EDHOC compliance requirements in https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-19#name-compliance-requirements . Defaulting to the well-known EDHOC profile if nothing else is somehow signalled would better be defined in the EDHOC specification.

That said, it feels much safer and easier to not define any profile whatsoever to be the "default profile", while it feels good to have a well-known profile as a good one to refer to (irrespective of being used or not).

---

Users don't need to do an application profiles when using DTLS "web-PKI-style", so why should they here? Or is this a distinction mark, because we *don't* expect "web-PKI-style" to be the implied default in EDHOC?

**MT**: I don't really understand this part of the comment, but it seems a motivation for having a well-known EDHOC application profile for CoAP and OSCORE to default to in the first place.

---

**Resolution**: It is good to define and register a well-known application profile (to be thought through what it includes). At the same time, it is not good to intrinsically relate it to any EDHOC resource at all, or to make it the default application profile for any EDHOC resource (including /.well-known/edhoc).

The Appendix F of the EDHOC draft can be replaced to reflect an actual well-known application profile to be registered, instead of a simple example. This justifies about better having the registry defined in the EDHOC draft instead, since the well-known profile will also be registered by EDHOC.

Still need to understand what exactly to have in this well-known profile.

--> raise at the interim meeting

**Outcome from the CoRE interim meeting**: Better to do in EDHOC.

**Github Commit**: None

## John's comments from WGLC

https://mailarchive.ietf.org/arch/msg/core/n6Kmomt6znH8y52C1-v3ufz7yPI/

Follow-up comment at:
https://mailarchive.ietf.org/arch/msg/core/8Cxad5Byb1qK07B00qQksPEJeiI/

I have reviewed draft-ietf-core-oscore-edhoc-06. I think it is ready with issues.

### Title (DONE-2)

* "Profiling EDHOC for CoAP and OSCORE"
Not sure this is a suitable name. It does not really profile EDHOC.

**MT**: What about "Using EDHOC with CoAP and OSCORE" ? Regardless, this will require a number of rephrasing throughout the document to avoid that EDHOC is being profiled.

**Resolution**: --> raise at the interim meeting --> Confirmed

**Github Commit**:

https://github.com/core-wg/oscore-edhoc/commit/755f38dfa1410b5f33c12a215e9a61f238e31067

https://github.com/core-wg/oscore-edhoc/commit/584ef436a86203b750ea5bfbd80cb559fa5f263b

### Section 1 (DONE)

* Proposed rephrasing

OLD:
"first subsequent OSCORE transaction" (several occurences)

NEW:
"first OSCORE transaction"

it is not subsequent anymore

**MT**: Ok

**Resolution**: Adopt the suggestion (4 occurrences).

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/5fbadf389c6248c99f847f8bc043fbee1d17e9f0

### Section 1.1 (DONE)

- "CoAP [RFC7252], CBOR [RFC8949], CBOR sequences [RFC8742], OSCORE [RFC8613] and EDHOC [I-D.ietf-lake-edhoc]." IETF uses the Oxford comma. (Probably several occurences).

**MT**: Ok

**Resolution**: Adopt the suggestion throughout the document

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/d74424c2ccfda91823004d5890ffc950ac044fa4

### Section 2 (DONE)

- "may be set to application/cid-edhoc+cbor-seq." (several occurences)
Any reason this is not a normative MAY, also what is the reason for not have SHOULD or SHALL? I don’t have a strong opinion.

**MT**: We are avoiding normative language altogether since it is an "Overview" section and we don't want to restate (or suggest deviations from) what the EDHOC document says.

We especially avoid using SHOULD/SHALL since, in its section 3.1, the EDHOC document says:

> Media types that may be used for EDHOC are defined in Section 9.8.

**Resolution**: Rephrase to say "can be set to" (3 occurrences in Section 2)

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/de5b6e34a0f6f771af370d23c95eed94daaa9f9f

### Section 3 (DONE)

- Proposed rephrasing

OLD:
"not transported precisely in the request payload."

NEW:
"not transported in the request payload."
But probably better to just say "as specified in Section 3.2, C_R is transported in the OSCORE Option."

**MT**: Yes, and I think it's even better to merge the two suggestions.

**Resolution**: Rephrase as: "as specified in Section 3.2, C_R is transported in the OSCORE Option rather than in the request payload."

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/296340a9f961941659b51760c69503d1aa515000

### Section 3.2 (DONE)

- "using the new OSCORE Security Context established after receiving EDHOC message_2."

I think this should be "after creating EDHOC message_3" The context depends on message_3.

**MT**: Yes; before generating and installing the OSCORE Security Context, you actually need to have successfully created EDHOC message_3, especially instead of an EDHOC error message.

**Resolution**: Proposed rephrasing to the whole step 2 of the client processing:

> OLD:
> Encrypt the original CoAP request as per Section 8.1 of [RFC8613], using the new OSCORE Security Context established after receiving EDHOC message_2.
>
> NEW:
> Establish the new OSCORE Security Context and use it to encrypt the original CoAP request as per Section 8.1 of [RFC8613].

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/42a5e6b2914bf03ec188313841358b1dc2b7da72

### Section 3.3 (DONE)

- "Check that the EDHOC + OSCORE request includes the OSCORE option and that the request payload is a CBOR sequence composed of two CBOR byte strings."

Should check for the EDHOC option as well

**MT**: That happens upfront, i.e., the sequence of steps refer to a message including the EDHOC option. Before the sequence of steps starts, the text says:

> In order to process a request containing the EDHOC option, i.e., an EDHOC + OSCORE request, the server MUST perform the following steps.

**Resolution**: No actions to take.

### Section 3.3 (DONE-2)

- The document is not clear on if you can send back an EDHOC error over OSCORE or not. It should be.

**MT**: This also relates to https://github.com/core-wg/oscore-edhoc/issues/8 . We should explicitly say what can happen at the server after processing EDHOC message_3.

**MT:**: When discussing with John we agreed that, after having successfully processed EDHOC message_3, the server may not want to talk to the identified client. This results in the server discontinuing EDHOC and sending an unprotected EDHOC error message. That is, the server does not derive OSCORE keying material, even if it would be able to. This is a deviation from TLS, that instead would return such an error message protected with the just derived keying material.

**MT:**: Related comment from Christian at https://mailarchive.ietf.org/arch/msg/core/Lf2u3nay0-omxkCLJgNmwE6dqt8/

> No objection to being explicit, just please make sure not to use normative language when describing factual impossibilities. (If EDHOC errs, no OSCORE context gets created -- but a MUST NOT would be yet another statement oscore-proxies would need to revise to enable nested operation).

**MT:**: Follow-up from John at https://mailarchive.ietf.org/arch/msg/core/2ojDc_4KZAaJiiaTZfXHcAqJVFw/

> I don’t think this is a factual impossibility. This is exactly what TLS 1.3 does and my understanding was that this could be done with EDHOC as well. There are two different types of things that can go wrong in EDHOC. One parsing errors to you cannot derive keys and then there are authentication errors (X.509 identity not authorized, X.509 cert expired, X.509 issuer not trusted, certificate revoked, database oflline, OCSP server offline, etc.).
>
> My view was that you could derive OSCORE keys in EDHOC even if authentication fails but I don’t have a strong opinion.
> What is possible in EDHOC and in draft-ietf-core-oscore-edhoc are different things. EDHOC could allow this and draft-ietf-core-oscore-edhoc could forbid it. But whatever the answer is, it needs to be clear. If EDHOC would forbid this, draft-ietf-core-oscore-edhoc does not need to state the same thing. Currently I don’t think it is clear in either document.

**MT:**: Related comment from Christian at https://mailarchive.ietf.org/arch/msg/core/ieJh_JyeupvXbn8kwWf_lGzwy_8/

> Ok, I see where this comes from now.
>
> Then maybe "[on error], OSCORE key material MUST NOT be derived from the EDHOC exchange, let alone be used to protect the respone"?

**MT**: The above sounds good.

**Resolution**: in Section 3.3 "Server processing", revise the second from last paragraph as follows:

> If step 4 (EDHOC processing) fails, the server discontinues the protocol as per Section 5.4.3 of [I-D.ietf-lake-edhoc] and responds with an EDHOC error message with error code 1, formatted as defined in Section 6.2 of [I-D.ietf-lake-edhoc]. **The server MUST NOT establish a new OSCORE Security Context from the present EDHOC session with the client, hence the CoAP response conveying the EDHOC error message is not protected with OSCORE. Furthermore,** the CoAP response conveying the EDHOC error message MUST have Content-Format set to application/edhoc+cbor-seq defined in Section 9.9 of [I-D.ietf-lake-edhoc].

**OLD RESOLUTION**: in Section 3.3 "Server processing", append a new paragraph within step 4:

> After a successful processing of EDHOC message_3, the server might not want to communicate using OSCORE with the now identified client. In such a case, this step fails and the server does not establish a new OSCORE Security Context with the client. It follows that the EDHOC error message sent by the server as defined below is not going to be protected with OSCORE.

--> Raise at the interim meeting --> confirmed

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/eca3586d09285072006e3acbbd82891343b770d6

### Section 7 (DONE)

- As discussed in LAKE you can get 128-bit authenticatation security by combinging two 64 bit tags. Has this been discussed in CORE? If the mechanism gives this property for either peer is should be mentioned.

**MT**: There was no specific discussion in CoRE on this point, but we can add a paragraph to the security considerations of this document, building on the following paragraph from Section 8.1 of the EDHOC document:

> As the EDHOC protocol is discontinued when verification fails, the security against online attacks is given by the sum of the strength of the verified signatures and MACs (including MAC in AEAD). As an example, if EDHOC is used with method 3, cipher suite 2, and message_4, the Responder is authenticated with 128-bit security against online attacks (the sum of the 64-bit MACs in message_2 and message_4). The same principle applies for MACs in an application protocol keyed by EDHOC as long as EDHOC is rerun when verification of the first MACs in the application protocol fails. As an example, if EDHOC with method 3 and cipher suite 2 is used as in Figure 2 of [I-D.ietf-core-oscore-edhoc], 128-bit mutual authentication against online attacks can be achieved after completion of the first OSCORE request and response.

**Resolution**: Add the following paragraph to Section 7, after the current second paragraph.

> When using the optimized workflow in Figure 2, a minimum of 128-bit security against online brute force attacks is achieved after the client receives and successfully verifies the first OSCORE-protected response (see Section 8.1 of [I-D.ietf-lake-edhoc]). As an example, if EDHOC is used with method 3 (see Section 3.2 of [I-D.ietf-lake-edhoc]) and cipher suite 2 (see Section 3.6 of [I-D.ietf-lake-edhoc]), then the following holds.
>
> * The Initiator is authenticated with 128-bit security against online attacks. This is the sum of the 64-bit MACs in EDHOC message_3 and of the MAC in the AEAD of the first OSCORE-protected CoAP request, as rebuilt at step 7 of Section 3.3.
>
> * The Responder is authenticated with 128-bit security against online attacks. This is the sum of the 64-bit MACs in EDHOC message_2 and of the MAC in the AEAD of the first OSCORE-protected CoAP response.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/5ea7dfb9fb7893bce7771005c3d1fcbcb138be61

### Section 3.3 (DONE-2)

- Is is clear what happens if the EDHOC + OSCORE Request is retransmitted?

**MT**: We are not saying anything more than what is already defined in Section 5.1 of the EDHOC document, i.e.:

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

Consistently, a retransmission of the EDHOC + OSCORE Request results in a failure at the server when performing step 4 of Section 3.3, in case the server has already successfully completed that EDHOC session. Later on in the same section, we inherit error handling to what is defined in the EDHOC document, including for this particular case.

**Resolution**: Based on the above, no further text should be added --> raise at the interim meeting --> confirmed

**Github Commit**: None

### Section 4.1.1 and 4.1.2 (DONE)

- "where the ID Context has zero-length."

This seems wrong. There is nothing special with the zero-length ID Context.
This should be "where the ID Context is not present"

**MT**: Correct, good catch. Based also on a related comment from Christian at https://mailarchive.ietf.org/arch/msg/core/Rs9EMsszA-QzRue7QJDIZN280WU/ , the text of those two sections become as follows.

* The content of Section 4.1.1 becomes:

> The Initiator selects an EDHOC Connection Identifier C_I as follows.
>
> The Initiator MUST choose a C_I that is neither used in any current EDHOC session as this peer's EDHOC Connection Identifier, nor the Recipient ID in a current OSCORE Security Context where the ID Context is not present.
>
> The chosen C_I SHOULD NOT be the Recipient ID of any current OSCORE Security Context.

* The content of Section 4.1.2 becomes:

> The Responder selects an EDHOC Connection Identifier C_R as follows.
>
> The Responder MUST choose a C_R that is neither used in any current EDHOC session as this peer's EDHOC Connection Identifier, nor is equal to the EDHOC Connection Identifier C_I specified in the EDHOC message_1 of the present EDHOC session (i.e., after its decoding as per Section 3.3 of [I-D.ietf-lake-edhoc]), nor is the Recipient ID in a current OSCORE Security Context where the ID Context is not present.
>
> The chosen C_R SHOULD NOT be the Recipient ID of any current OSCORE Security Context.

**Resolution**: Do it.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/7562931fa912523ea83bb00cfd6c14b74423acb2

### Section 6 (DONE-2)

- 'ead1', 'ead2', 'ead3' and 'ead4'

This makes no sense to me. Either you support EAD or not. Also knowing that the other party support EAD is useless. You need to know what kind of EAD. I stongly think this should use values from the EDHOC External Authorization Data Registry.

**MT**: This is exactly our intention; the text is not clear enough. Proposed improvements:

* Rephrase the first sentence of the bullet point on 'ead1', 'ead2', 'ead3' and 'ead4'

OLD:
'ead1', 'ead2', 'ead3' and 'ead4', specifying, if present, that the server supports the use of External Authorization Data EAD_1, EAD_2, EAD_3 and EAD_4, respectively (see Section 3.8 of [I-D.ietf-lake-edhoc]).

NEW:
'ead1', 'ead2', 'ead3' and 'ead4', specifying, if present, that the server supports specific External Authorization Data (EAD) items to use in the EDHOC message fields EAD_1, EAD_2, EAD_3 and EAD_4, respectively (see Section 3.8 of [I-D.ietf-lake-edhoc]).

* Extend the second, inner bullet point with an example. That is:

> For example, the following set of target attributes
>
> ead1=5;ead2=10;ead3=5;ead3=42
>
> denotes that the server supports the use of: the EAD item with ead_label 5 in EAD_1 and EAD_3; the EAD item with ead_label 10 in EAD_2; and the EAD item with ead_label 42 in EAD_3.

Note that the text already says that the values for these target attributes are indeed taken from the "EDHOC External Authorization Data" registry.

**Resolution**: Looks good to add --> Raise at the interim meeting --> confirmed --> changed to more simply be about a single target attribute "ed-ead" indicating a supported EAD label (irrespective of the EDHOC messages where it is specifically used).

**Github Commit**:

https://github.com/core-wg/oscore-edhoc/commit/bbdeb94414270892ac6f12109eece0c8571c8ebe

https://github.com/core-wg/oscore-edhoc/commit/510a8aaefedb1a1f2920dc0f60fe94e46cdbb5ab

https://github.com/core-wg/oscore-edhoc/commit/310ffdd2e4c6643b79dafc85eb22940d223fbf72

https://github.com/core-wg/oscore-edhoc/commit/e4b12589ad1ccab72c6d2d9d4308abccf2ad2d1f

https://github.com/core-wg/oscore-edhoc/commit/fdc76da3c69520f07412ea7e5904d499d2d479d4

### Section 6 (DONE-2)

One more comment:

* 'cred-t', specifying a type of authentication credential supported by the server. This parameter MUST specify a single value, and possible values are: "x509", for X.509 certificate [RFC5280]; "c509", for C509 certificate [I-D.ietf-cose-cbor-encoded-cert]; "cwt" for CWT [RFC8392]; "ccs" for CWT Claims Set (CCS) [RFC8392]. This parameter MAY occur multiple times, with each occurrence specifying a different authentication credential type.

I think this should be made into an IANA registry under "Ephemeral Diffie-Hellman Over COSE (EDHOC)". The registry could be created by the EDHOC document or draft-ietf-core-oscore-edhoc.

**MT**: Looks good; which document? This one or the EDHOC specification in LAKE? It feels like the LAKE draft is more appropriate

**Resolution**: Do it, either here or in the EDHOC specification --> Raise at the interim meeting

Just like for 'method' and 'csuite', it is good to use integer values.

> IANA is requested to create a new "EDHOC Authentication Credential Types" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group.
>
> The columns of this registry are:
>
> * Value: This field contains the value used to identify the type of authentication credential. These values MUST be unique. The value can be an unsigned 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 type of authentication credential.
>
> * Reference: This field contains a pointer to the public specification for this entry.
>
> The registry is initially populated as follows.
>
> ```
> +-------+-----------------------+-----------------------------------+
> | Value | Description | Reference |
> +-------+-----------------------+-----------------------------------+
> | 0 | CBOR Web Token (CWT) | [RFC8392] |
> | | containing a COSE_Key | |
> | | in a 'cnf' claim | |
> +-------+-----------------------+-----------------------------------+
> | 1 | CWT Claims Set (CCS) | [RFC8392] |
> | | containing a COSE_Key | |
> | | in a 'cnf' claim | |
> +-------+-----------------------+-----------------------------------+
> | 2 | X.509 certificate | [RFC5280] |
> +-------+-----------------------+-----------------------------------+
> | 3 | C509 certificate | [I-D.ietf-cose-cbor-encoded-cert] |
> +-------+-----------------------+-----------------------------------+
> ```

**Outcome from the CoRE interim meeting**: Better to do in EDHOC. --> After discussing with the EDHOC authors, we eventually decided to define the registry in this document, in order to affect draft-ietf-lake-edhoc as least as possible in its current, advanced stage.

**Github Commit**: https://github.com/core-wg/oscore-edhoc/commit/aa13c4b29575fefcc2d2845095cbed892b06f2ee