Hi all,
There has been reluctance to use the context information structure, as reflected in some emails distributed to the COSE mailing list today. I believe this reluctance is unwarranted, and I’d like to explain why. >From a security perspective, there is no difference between including this >context information in the key derivation and authenticating it as part of a >digital signature calculation. Let’s assume the information is included in the >key derivation. The first design aspect is deciding what information to include in the key derivation function. I hope there is no disagreement on the benefits of doing this. There are various fields to consider, and the COSE RFC (along with other sources, including NIST) provides good guidance. Examples include identity information about the sender and receiver, algorithm identifiers, key lengths, etc. The second design aspect is how to encode the information elements. The context information structure from Section 5.2 of RFC 9053 is one approach, using a CBOR structure based on fields included in the COSE payload or known to the communication endpoints. An alternative, as seen in the COSE HPKE draft version -09, reuses information from the COSE protected headers. This approach benefits from explicitly listed information in the protected headers, making debugging easier in case of failure, though it may require some information elements to be redundantly included. When reviewing existing solutions, it is surprising to see the vast variation in the information included in key derivation and how these structures are encoded. One would think it would be straightforward to agree on these aspects, but we sometimes get lost in the details. Ciao Hannes
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
