Hello Marco, sorry for missing that this thread was unresolved.
On Mon, Dec 16, 2024 at 02:48:46PM +0100, Marco Tiloca wrote: > If I understand correctly, you are proposing the following optimization: > > * In the EDHOC and OSCORE profile, it can be allowed that 'req_cnf', > 'rs_cnf', and 'cnf' specify "COSE_Key" (1) as CWT Confirmation Method. Technically yes; but I'm not so much proposing the optimization, but more pointing out that EDHOC seems to imply this already in [1] bullet 4.1. This seems to also be aligned with RFC9201, where in Figure 1, there is a req_cnf that contains a naked COSE key. > * When doing so, the consumer of 'req_cnf', 'rs_cnf', or 'cnf' must build a > CCS including only the claim 'cnf', which takes the same value specified as > COSE Key in the received confirmation method. > > This building operation effectively consists in prepending the four bytes > 0xa108a101 to the received "naked" COSE Key. Yes. > * The result from the previous step (i.e., the COSE Key minimally "dressed" > as a CCS) is used as authentication credential in EDHOC, transported with a > 'kccs' COSE header parameter when specified by value in ID_CRED_X. Yes, although I kind'a doubt that a credential already expressed in some other place would be transported by value here. > If so, I wonder if saving 4 bytes per credential is worth it, and I'm > interested to hear more opinions. I think this is not just about the overhead but also about consistency with the documents in which the pattern has been used. BR c [1]:https://www.rfc-editor.org/rfc/rfc9528.html#name-authentication-credentials -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
