Yes, two categories for COSE_KDF_Context, public and private. We can add a field to Enc_structure for private and use headers for public.
The salt from 9053 section 5 is not part of COSE_KDF_Context, but it is part of the KDF context. That probably wasn’t clear from my first message. There’s also an *unprotected* header for it. It is not input to the processing as a header, but rather as a direct input to the KDF function itself. To be more clear about the salt, I think it’s fully outside of COSE_KDF_Context and we don’t have to consider it in that discussion. Further, I don’t think we need to consider it in COSE-HPKE either, because HPKE internals do the job of the salt in 9053 section 5. LL On Mar 13, 2024, at 1:21 PM, Orie Steele <[email protected]> wrote: Seems there are 2 categories of information you are considering. Public information in the protected headers (top level and recipient level). Private information, that might be passed as external aad to the enc structure. I think it's a nice property of enc structure, that the extensibility of the protected headers, can be used for additional context. We might be concerned if that structure gets very large, and given we are talking about encryption it's also important to warn users about putting sensitive information in the protected headers. OS On Wed, Mar 13, 2024, 3:08 PM lgl island-resort.com<http://island-resort.com/> <[email protected]<mailto:[email protected]>> wrote: In getting rid of COSE_KDF_Context, it seems important to be sure we’re not leaving anything useful or important out. Generally, it seems like we have a general mechanism by adding new header parameters that can cover a lot because they end up in the Enc_structure and then as input AAD to Seal(). In the side discussions at the San Francisco IETF (Russ, Hannes,…) I recall consensus that COSE_KDF_Context.SuppPubInfo.other should be set to a fixed app/use-case identifier like "Xxxx Firmware Encryption”. As part of getting rid of COSE_KDF_Context for COSE-HPKE, we should provide an option to do this. Seems like the usual two possibilities:: - New header parameter, perhaps “Usecase Context”? - Add it to Enc_structure (or the recently proposed Rec_structure) RFC 9053 also allows the input of a salt into the KDF. That would not be covered by a new header parameter that gets passed to Seal as AAD. I’m not too worried about this for HPKE, because I think HPKE covers that internally, but it might be retained for a replacement for -29. LL _______________________________________________ COSE mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
