EAD internal structure and the EAD API

[emanjon]

Looking at how EAD is used ace-ake-authz, I am not sure that the

   ead = 1* (
     ead_label : int,
     ead_value : any,
   )

where ead_label identifies a single ead_value is optimal. The structure above enables reuse of ead_label between protocols but give no information about the context that ead_value should be used in like ace-ake-authz. From an random order of data elements it might be hard to figure out what to do with the data. Alternatives would be

   ead = (
     ead_label : int,
     *ead_value : any,
   )

Where ead_label a specific message of ace-ake-authz or just identifies ace-ake-authz (the message number is known anyway). As far as I know there several protocols planning to use EAD. I think we need to look at how these protocols use EAD and if any reuse between different protocols seem likely. If reuse does not seem to be likely, the second structure with the same ead_label being used in all of the ace-ake-authz messages seems to be the most simple solution. Using a single int saves some bytes, and using a single int for a protocol like ace-ake-authz will likely use less of the code points.

Another question is the EAD API. For larger object like CWT, the EDHOC EAD API needs to accept a encoded form. It should not reencode the CWT. This opens up the problem of what happens if somebody inputs wrongly encoded CBOR. This was identified as a problem in the EDHOC-KDF. It is less of a problem here but still not nice. This would point to a byte string as input being the way to go.

   ead = (
     ead_label : int,
     ead_value : bytes,
   )

This would make the API simple, make sure that everything is correcly encoded CBOR, but likely increase the message size (compared to a CBOR sequence). However applications like ace-ake-authz might then be able to do internal optimizations inside the byte string.

(Note that the internal encoding of EAD does not affect anything else in EDHOC, it is more a topic for the protocols wanting to use EAD)

[StefanHri]

How is that now done e.g. in test vector 10 https://github.com/lake-wg/edhoc/blob/62586170c39150cc9f30665b5489a454fc429fc6/test-vectors-11/vectors-json.txt#L829?

[emanjon]

Right now in the test vectors, "183ba1f646000102030405" is an encoding of a CBOR sequence following the structure

   ead = 1* (
     ead_label : int,
     ead_value : any,
   )

The actual content is just made up data to show the formating. The actual data has no meaning. Nobody has registered any ead_label values.

[emanjon]

An alternative is to keep the current high structure but change any to bytes

   ead = 1* (
     ead_label : int,
     ead_value : bytes,
   )

What ead_label is supposed to identify is not described in the EDHOC document. It would be good with some guidance to protocols wanting to use EAD. For example that they should register a single int for the protocol.

[StefanHri]

I think the question is: should the EAD be consumed by the EDHOC implementation always encoded or sometimes encoded and how to differentiate that?

[emanjon]

I think the question is: should the EAD be consumed by the EDHOC implementation always encoded or sometimes encoded and how to differentiate that?

Based on your comments on API and that we likely want to ensure that ead is correct CBOR, the answer is likely that the input to the API should always be non-CBOR int and byte strings. The input byte string does then not need to be CBOR.