On Jul 20, 2024, at 11:42 PM, Ilari Liusvaara <[email protected]> wrote:
On Sun, Jul 21, 2024 at 10:16:20AM +0900, Ken Takayama wrote: Understand. We have to consider what the COSE library implementers are facing. I've attached a chart describing the decryption procedure, including the current key distribution methods in COSE 9053 and cose-hpke, and the approach proposed by Hannes. (Please fix it if I'm wrong.) The actual implementations have to "correctly" set the Context Information Structure but its explanation in RFC 9053 is ambiguous, especially the AlgorithmID. I find AlgorithmID mostly clear: When deriving keys, it is alg of the layer the key is used on. - So if it is combined KDF+KW, it is alg of this layer. - Otherwise, it is alg of next layer. To be more clear, it’s algorithm ID of the next _COSE_ layer, right? In the case of two-layer cose where you have a COSE_Encrypt and a COSE_Recpient, the “next algorithm ID" secured by the COSE_Recipient layer is the one performed in the COSE_Encrypt layer. (The COSE_Recipient can do all sorts of things with lots of algorithms internally and all those IDs need to be secured, but that is not what we’re talking about here; in particularly when a COSE_Recipient does KEM + KW or such, it’s not the algorithm ID of the KW). Things get bit hairy when deriving IVs. Clearly AlgorithmID=34 (0x18 0x22) when deriving IVs, but what exactly triggers IV derivation[1]? And then things get really hairy with PartyUInfo and PartyVInfo. Those are by far the most difficult part of the CIS. There’s no scenario where HPKE needs PartyU and PartyV, right? (the only reference in RFC 8610 to NIST SP 800-56A is about making sure input keys are of the right form) LL
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
