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

[Göran Selander <[e-mail]>]

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 <[e-mail]>
Date: Monday, 21 March 2022 at 14:55
To: Göran Selander <[e-mail]>
Cc: Laurence Lundblade <[e-mail]>, [e-mail] <[e-mail]>
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=[e-mail]<mailto:[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]<mailto:[e-mail]>> on behalf of Laurence Lundblade <[e-mail]<mailto:[e-mail]>>
Date: Monday, 21 March 2022 at 14:14
To: Göran Selander <goran.selander=[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[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]<mailto: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]<mailto:[e-mail]>
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>