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

I see basically 2 issues.

1. can `kid` and `intkid` both be present in a key.

If they can't then there is no upgrade path for existing keys to touch the
new RF stuff... and new keys with ONLY intkid would need to be generated.

If they can, then just generate a new intkid for each existing kid and be
done with it.

2. can we change the definition for `kid` to support both int and
bstring via making it have an or type.

If this were legal, you can't assign both an int and a bstring to the same
existing key, so you would be forced to generate new keys, for the int use
case... this does not seem that bad to me.

If this is not legal, you obviously need to register a new key identifier
that supports ints, if you need to support ints.

This raises the obvious question of will ANY of the new RF systems expect
to work with existing keys... if the answer is no, and the new RF stuff
will only use "new keys", you can generate the new keys and ensure:

- they have kid and it's an int.
- they have intkid and it's an int.

As an aside keys should have ids that are assigned when they are
generated... so for me, the "lets use an existing key, but give it a new
id" is an anti pattern... just generate a new key, and make sure it has all
the fields you think it needs to be successful.

I still think allowing any form of int kid is a mistake, and the header
size requirement is the thing that should change, not the `kid` type... the
compatibility and simplicity are worth the size cost imo.

OS

On Mon, Mar 21, 2022 at 2:10 PM Mike Prorock <mprorock@mesur.io> wrote:

> As with Orie, pretty big -1 to adjusting kid from me
>
> Mike Prorock
> mesur.io
>
> On Mon, Mar 21, 2022, 09:55 Orie Steele <orie@transmute.industries> 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=
>> 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>
>> _______________________________________________
>> 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>