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<mailto: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<mailto: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<mailto: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<mailto:orie@transmute.industries>> Date: Monday, 21 March 2022 at 14:55 To: Göran Selander <goran.selan...@ericsson.com<mailto:goran.selan...@ericsson.com>> Cc: Laurence Lundblade <l...@island-resort.com<mailto:l...@island-resort.com>>, cose@ietf.org<mailto:cose@ietf.org> <cose@ietf.org<mailto: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<mailto: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<mailto:cose-boun...@ietf.org>> on behalf of Laurence Lundblade <l...@island-resort.com<mailto:l...@island-resort.com>> Date: Monday, 21 March 2022 at 14:14 To: Göran Selander <goran.selander=40ericsson....@dmarc.ietf.org<mailto:40ericsson....@dmarc.ietf.org>> Cc: cose@ietf.org<mailto:cose@ietf.org> <cose@ietf.org<mailto: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<mailto: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<mailto: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<mailto: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://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<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://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<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://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<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>
_______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
