Re: [COSE] Key identifier of type bstr / int

[Mike Prorock <[e-mail]>]

As with Orie, pretty big -1 to adjusting kid from me

Mike Prorock
mesur.io

On Mon, Mar 21, 2022, 09:55 Orie Steele <[e-mail]> wrote:

> 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=
> [e-mail]> 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 <[e-mail]> on behalf of Laurence Lundblade <
>> [e-mail]>
>> *Date: *Monday, 21 March 2022 at 14:14
>> *To: *Göran Selander <goran.selander=[e-mail]>
>> *Cc: *[e-mail] <[e-mail]>
>> *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 <[e-mail]>
>> wrote:
>>
>>
>>
>> Understood about the use case. Thx for the background.
>>
>>
>>
>> On Aug 10, 2021, at 3:13 AM, Göran Selander <
>> goran.selander=[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cose
>>
>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose
>