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 <[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] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
