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://www.transmute.industries>