Thank you, much clearer. My current position is that I am unconvinced that it's needed, or a good idea :) ... any links or summary for why a new key identifier is needed would be helpful.
However, of the names suggested I am mostly a fan of "intkid". OS On Mon, Mar 21, 2022 at 1:01 PM Laurence Lundblade <[email protected]> wrote: > Let me try to be more clear. > > The COSE standard now is: > > kid => bstr > > If we make this change: > > kid => int / bstr > > then we break backwards compatibility for COSE as Mike pointed out today. > So we need a separate parameter called kid2, ckid, intkid or such. > > To not break backwards compatibility we need: > > intkid = int > > or: > > intkid = int / bstr > > (I don’t remember why an int kid was needed, but do remember I was > convinced that it was) > > LL > > > On Mar 21, 2022, at 6:43 PM, Orie Steele <[email protected]> > wrote: > > I think I may have misread your proposal. > > Why do we need `kid2` is this just so that we can have an integer `kid` ? > > Seems not worth it to me, since `kid` is already legal in CBOR, my > proposal of `ckid` makes no sense. > > So I am basically just saying I dislike seeing `kid2` and don't understand > what its value prop is. > > OS > > > > > > On Mon, Mar 21, 2022 at 12:16 PM Göran Selander < > [email protected]> wrote: > >> Hi Orie, >> >> >> >> Thanks for input. I didn't get the proposal though: >> >> >> >> > 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. >> >> >> >> RFC 7517/7519: kid and jti value are case-sensitive strings >> >> >> >> RFC 8152/8392: kid and cti value are CBOR bstr >> >> >> >> Is there any difference between a `ckid` which is CBOR int or a `kid2` >> which is a CBOR int (besides the name)? >> >> >> >> Thanks >> >> Göran >> >> >> >> >> >> *From: *Orie Steele <[email protected]> >> *Date: *Monday, 21 March 2022 at 14:55 >> *To: *Göran Selander <[email protected]> >> *Cc: *Laurence Lundblade <[email protected]>, [email protected] < >> [email protected]> >> *Subject: *Re: [COSE] Key identifier of type bstr / int >> >> 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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a7ff2eb208872658&q=1&e=94b1f6ec-570c-49db-b72f-d15cfe926d93&u=http%3A%2F%2Fwww.transmute.industries%2F> >> >> >> >> >> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-c169100f194b3f01&q=1&e=94b1f6ec-570c-49db-b72f-d15cfe926d93&u=https%3A%2F%2Fwww.transmute.industries%2F> >> > > > -- > *ORIE STEELE* > Chief Technical Officer > www.transmute.industries > > <https://www.transmute.industries/> > > > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
