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 <lgl@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.selander@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.selander@ericsson.com>
>> *Cc: *Laurence Lundblade <lgl@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.com@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-bounces@ietf.org> on behalf of Laurence Lundblade <
>> lgl@island-resort.com>
>> *Date: *Monday, 21 March 2022 at 14:14
>> *To: *Göran Selander <goran.selander=40ericsson.com@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 <lgl@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.com@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://www.transmute.industries/>
>
>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>