On Tue, Mar 14, 2023 at 12:30:56PM -0700, Laurence Lundblade wrote: > -04 is a good improvement. Thank you.
It even seems implementable. :-) > The kid parameter is always optional in COSE. It shouldn’t be > mandatory in 3.1.1 and 3.1.2. I think this is a mandatory change for > this draft. Section 5.2 of 9052 even discourages use of kid in and > Encrypt0: > > The COSE_Encrypt0 encrypted structure does not have the ability to > specify recipients of the message. The structure assumes that the > recipient of the object will already know the identity of the key > to be used in order to decrypt the message. If a key needs to be > identified to the recipient, the enveloped structure ought to be > used. I think the COSE_Encrypt0 case here is actually analogous to Direct Key Agreement, because COSE-HPKE smashes two layers together (as HPKE makes that natural to do). And DKA usually uses kid. In my implementation, there is shortcoming[1] that causes things to blow up if one tries to decrypt COSE_Encrypt0 messages without kid using multiple decryption keys (it does kid matching, but can only try to decrypt once, COSE_Encrypt does exhaustive trial decryption after kid matching). > I’d like for “HPKE” to be in the name of the structure since it is > HPKE specific — perhaps “HPKE_sender_info”. Yeah, I think that is a better name. > Section 4.3 is clear now and well-aligned with what I was thinking > it should be. Yeah, I also tought that techically that section is good, but that it could be phrased better (relying more on RFC 9052). [1] At least it does not make the whole system with 8GB RAM to go Chernobyl if one encrypts/decrypts 20GB+ message... -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
