> On Mar 15, 2023, at 8:41 AM, <[email protected]> > <[email protected]> wrote: > > 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. > > > Key identification is something that COSE leaves up to the layers above as > far as I can see. It should probably have been mentioned as one of the things > a COSE profile should specify in section 10 of RFC 9052. I have found this a > bit odd, particularly compared to CMS, but I can see the value in leaving it > open. > > [Hannes] I can make the kid parameter optional. > > IMHO the advice in RFC 9052 regarding the kid is a bit strange. I don’t > understand why there is no value in using some parameter, like the kid, to > give the recipient a idea what they it should be using to decrypt the > message. Of course, if it is available from the context then that’s fine but > that this may not always be the case. Of course, having this discussion about > RFC 9052 is not so useful and we have to look forward. If a profile needs the > kid (or some other parameter) then they have to use it.
It’s primary for smaller message size. UEID as the key identifier in EAT and Instance ID in PSA Attestation are examples with no kid. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
