I am a -1 to changing `kid`, it should remain a string, for compatibility with existing key identifier systems.
Including ones that support https://datatracker.ietf.org/doc/html/rfc7638#section-1 See the original definition: https://datatracker.ietf.org/doc/html/rfc7517#section-4.5 > The "kid" value is a case-sensitive string. Many implementations have built hard dependencies on RFC7515. One of the nicest things about JOSE / COSE is being able to "upgrade" from JOSE to COSE. Having a significant difference between `kid` in JOSE and COSE would be harmful. If we really need an integer version of `kid` I would suggest following the `jti / cti` convention and calling it `ckid`... keeping it optional (as is the convention), and ensuring it is not part of thumbprint computations. Regards, OS On Mon, Mar 21, 2022 at 8:35 AM Göran Selander <goran.selander= [email protected]> wrote: > Hi Laurence, > > > > Thanks for copying in the old thread. As noted, you and others preferred > `kid` as bstr / int rather than `kid2` as int when we discussed it last > time. Would be good to come out with a more solid motivation this time so > we can converge on this :-) > > > > With `kid2` as int, the fields that uses both bstr and int would be of > type `kid` / `kid2` which is fine. > > > > There is an algorithm for translation from CBOR bstr / int to byte strings > on the wire (back and forth) in draft-ietf-core-oscore-edhoc. > > > > Göran > > > > > > *From: *COSE <[email protected]> on behalf of Laurence Lundblade < > [email protected]> > *Date: *Monday, 21 March 2022 at 14:14 > *To: *Göran Selander <[email protected]> > *Cc: *[email protected] <[email protected]> > *Subject: *Re: [COSE] Key identifier of type bstr / int > > Thinking about Mike’s comment today in COSE/Vienna about backwards > compatibility. Looked at my code around this. That definitely seems like an > issue. > > > > What about defining “kid2” as just int? “kid” stays as bstr only. Then > there’s no backwards compatibility break. Adding support for another > integer parameter isn’t difficult. The downside is a little extra code to > look at two different parameters. > > > > You’d probably want to say that only one of the two kids MUST be present. > > > > Another random idea — could you say that it is allowed to translate an > integer kid to a bstr kid by assuming network byte order and stripping > leading zeros? > > > > LL > > > > > > > > > > On Aug 13, 2021, at 3:01 AM, Laurence Lundblade <[email protected]> > wrote: > > > > Understood about the use case. Thx for the background. > > > > On Aug 10, 2021, at 3:13 AM, Göran Selander < > [email protected]> wrote: > > > > Assume that we do want to allow key identifiers to be CBOR ints in certain > settings, what is the best (least intrusive) way to allow this while still > maintain compatibility with 'kid's supporting the type bstr? Another > alternative to what has been listed below is to define 'kid2' to only be of > type int - is that a better option? > > > > I didn’t write actual code to check, but they about the same to me. > > > > ‘kid' as int/bstr seems less confusing to me than ‘kid2’. It tells you it > does exactly the same thing whether it is an int or a bstr. > > > > So my pick is ‘kid’, but ‘kid2’ is OK too. > > > > LL > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
