On Thu, May 21, 2026 at 04:03:02PM +0000, Sipos, Brian J. wrote: > All, > > I have run into a couple of questions related to the KDF context [1] used by > some existing registered COSE algorithms. The overall goal I have is to > constrain KDF use to simplify COSE integration into my application. > > The first question is about recommendations on the use of supplemental > public info: the base specification in [1] doesn't give any specific > guidance about recommended minimum amount of context binding. But from some > implementations it appears that using COSE_KDF_Context.SuppPubInfo.other > with at least some kind of application-specific constant string is > recommended. It seems like leaving even that out is allowed by maybe. > discouraged? Is there also a common suggestion to include additional "other" > context data for key uniqueness, or is it really to use-case-specific to > have general recommendations?
What I would include: - Application identifier - Application-specific mode or subkey name (from fixed set). Both can be ASCII strings. What I would not include is anything that depends on the recipient, as that causes interoperability headaches. That is, all the recipients in the message should have the same SuppPubInfo.other (where applicable). Even any ML-KEM recipients. And I would not use SuppPrivInfo at all. > The second question is about an application prohibiting KDF-related header > parameters: I would like to keep my use variations as simple and few as > possible so would prefer to prohibit the use of PartyU and PartyV header > parameters (-21 to -26). On the sender side this is quite easy to enforce > with existing COSE libraries, but for a recipient is a normative restriction > on specific header parameters reasonable or even enforceable with existing > libraries? Or is this a situation of the status quo being to mandate the use > (by a recipient) of existing header parameters when present? The code I wrote never emitted PartyU nor PartyV headers, but did accept those if explicitly present. That is, parameters -21 to -26 would set the corresponding value in receiver context structure, instead of using the nil default value. Oh, and what that code did with algorithms. It divided algorithms along two axes: - Keying * AE and AEAD algorithms. * Direct Key Agreement algorithms. * Asymmetric algorithms. Only AE and AEAD algorithms are allowed to have recipients, the rest are not. In addition to deriving keys, Direct Key Agreement algorithms are also used to derive IVs (IV-GENERATION) if needed. - Header protection level: * Not supported. * Supported. * Supported / Bulk cipher Only bulk ciphers are allowed at layer 0. Protected headers require algorithm to support protection. The code did not support ECDH-SS, and did not even consider what it would take to support it. And another thing that code did was to allow adding Direct Key Agreement recipients to multi-recipient message. That wrapped the key using the bulk cipher with implicit IV. So if bulk cipher was set to -24, it wrapped the key with -24 using IV-GENERATION for the IV. Then it had two separate single-recipient interfaces. One was for direct and asymmetric encryption. The other was for Direct Key Agreement. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
