[Lake] EDHOC Implementation Considerations for parameters

["Sipos, Brian J." <[e-mail]>]

All,

I've been looking through the EDHOC Implementation Considerations draft [1]
and there is a lot of very valuable information in there, especially around
the notion of side processing. (As a secondary question, was there a source
for this term "side processing" or was it created for this document?)

 

One thing in EDHOC that I am trying to reconcile with an integration in a
new environment is how to express/agree/negotiate precondition parameters
(like Method [2]) to being able to actually invoke EDHOC procedures and
expect them to succeed with a should-be-interoperable but external peer.

 

I see in the OSCORE integration document there is a specific listing of
available EDHOC parameters [3] that an endpoint can express to help a peer
choose what to offer in the first EDHOC message that will have a good chance
to succeed. Does it make sense to cover the same needed parameters in a less
integration- or transport-specific way in the Implementation Considerations
doc? Even just having a list of "these are the things that must or can be
expressed before starting an EDHOC procedure to ensure it will complete
successfully ." would, I think, be helpful to implementors.

 

Thanks for your feedback,

Brian S.

 

[1]
https://www.ietf.org/archive/id/draft-tiloca-lake-edhoc-implem-cons-01.html

[2]
https://www.ietf.org/archive/id/draft-ietf-lake-edhoc-23.html#section-3.2

[3]
https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-10.html#section
-6