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? 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? There is some interesting text in the ML-KEM draft [2] about why those algorithms have chosen to not make use of the header parameters, but my question is about existing algorithms which already define how to use those parameters when present. Thanks for any feedback, Brian S. [1] https://www.rfc-editor.org/rfc/rfc9053.html#section-5.2 [2] https://www.ietf.org/archive/id/draft-ietf-jose-pqc-kem-05.html#section-5.2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
