On Sun, Jul 02, 2023 at 06:10:59PM +0000, lgl island-resort.com wrote: > Here’s the improved description of IDs used that I promised with a new > summary at the end > > COSE_Key > A single algorithm identifier from the same space used by > COSE_Sign1…COSE_Recipient plus a curve identifier for EC some keys. > While the alg here is optional, it is a fact that it is a singe alg > ID that is unified with all the above.
It is only unified with the innermost one. > Summary > - COSE aggregates into a single identifier for each major structure > like COSE_Encrypt or COSE_Recipient However, it composes those. > - Sometimes COSE aggregates the EC curve ID and sometimes the curve ID > comes from the key I think the aggeration is only for one special snowflake (ES256K). > - While COSE and JOSE don’t use complete ciphersuites they never > disaggregates the way HPKE does The result of composition can pretty much be disaggregation to similar level than in HPKE: Suppose you have a x448 key, and want to do ECDH-ES with it at nominal strength. Single-recipient setting: 1) The key specifies type 1 / subtype 5. 2) The only alg is -26. 3) Bulk cipher can be 3 or 24. This seems like similar three-way split as in HPKE. Multi-recipient setting: 1) The key specifies type 1 / subtype 5. 2) The only alg is -26. 3) Key wrap has to be -5 (however, 3 and 24 could be interpretted as allowed[1]). 4) Bulk cipher is 3 (or 24 if that could be used for key wrap This is four-way split, similar as in HPKE performing key wrap. [1] There is mechanism called iv-generation. It is only documented in conjunction with "Direct Key with KDF"[2], but I see no technical reason it would not work with "Direct ECDH". It would unlock using AES-GCM/Chacha20-Poly1305 for key wrap (of course, no existing implementation supports that). [2] As aside, that can be used to construct a situation that actually uses "Enc_Recipient". -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
