Again, thank you... much clearer. I assume that `kid` and `intkid` would both be legal in the same key.
that `kid` would be used for legacy use cases. that `intkid` would be used for space constrained RF use cases. that both would remain optional, and neither would impact thumbprints. Use case makes sense, but it's pretty sad that a new key identifier is required to meet the use case. I don't see another solution though. OS On Mon, Mar 21, 2022 at 1:10 PM Göran Selander <goran.selan...@ericsson.com> wrote: > Here is the history. > > > > The objective is to have 1-byte COSE key identifiers to meet the > requirements in the LAKE WG: > > https://datatracker.ietf.org/doc/draft-ietf-lake-reqs/ > > > > Without going into the details, the overhead requirements of certain radio > frames when you add sizes of ephemeral public keys and MACs etc. doesn't > leave you many bytes for identifiers. > > > > The thread in COSE started here: > > https://mailarchive.ietf.org/arch/msg/cose/q_6kay8Z_4Wr48TFBXZU2oGRqoE/ > > > > The conclusion of that thread was there was a preference in the COSE WG > for extending the COSE header `kid` to bstr / int. > > > > Today the discussion restarted in the COSE WG, and Laurence picked up on > that. > > > > Göran > > > > > > *From: *Orie Steele <orie@transmute.industries> > *Date: *Monday, 21 March 2022 at 19:04 > *To: *Laurence Lundblade <l...@island-resort.com> > *Cc: *Göran Selander <goran.selan...@ericsson.com>, cose@ietf.org < > cose@ietf.org> > *Subject: *Re: [COSE] Key identifier of type bstr / int > > 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 <l...@island-resort.com> > 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 <orie@transmute.industries> > 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 < > goran.selan...@ericsson.com> 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 <orie@transmute.industries> > *Date: *Monday, 21 March 2022 at 14:55 > *To: *Göran Selander <goran.selan...@ericsson.com> > *Cc: *Laurence Lundblade <l...@island-resort.com>, cose@ietf.org < > cose@ietf.org> > *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= > 40ericsson....@dmarc.ietf.org> 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 <cose-boun...@ietf.org> on behalf of Laurence Lundblade < > l...@island-resort.com> > *Date: *Monday, 21 March 2022 at 14:14 > *To: *Göran Selander <goran.selander=40ericsson....@dmarc.ietf.org> > *Cc: *cose@ietf.org <cose@ietf.org> > *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 <l...@island-resort.com> > wrote: > > > > Understood about the use case. Thx for the background. > > > > On Aug 10, 2021, at 3:13 AM, Göran Selander < > goran.selander=40ericsson....@dmarc.ietf.org> 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 > COSE@ietf.org > 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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a7ff2eb208872658&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=http%3A%2F%2Fwww.transmute.industries%2F> > > > > > <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-c169100f194b3f01&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=https%3A%2F%2Fwww.transmute.industries%2F> > > > > > > > -- > > *ORIE STEELE* > > Chief Technical Officer > > www.transmute.industries > <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a7ff2eb208872658&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=http%3A%2F%2Fwww.transmute.industries%2F> > > > > > <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-c169100f194b3f01&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=https%3A%2F%2Fwww.transmute.industries%2F> > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
