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

From: Laurence Lundblade <[email-masked]>
Date: Mon, 21 Mar 2022 14:13:50 +0100

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 <[email-masked]> wrote:
> 
> Understood about the use case. Thx for the background.
> 
>> On Aug 10, 2021, at 3:13 AM, Göran Selander <goran.selander=[email-masked] <mailto:goran.selander=[email-masked]>> 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

---

From: Göran Selander <[email-masked]>
Date: Mon, 21 Mar 2022 13:35:25 +0000

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

LL

On Aug 13, 2021, at 3:01 AM, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

On Aug 10, 2021, at 3:13 AM, Göran Selander <goran.selander=[email-masked]<mailto:goran.selander=[email-masked]>> wrote:

LL

---

From: Orie Steele <[email-masked]>
Date: Mon, 21 Mar 2022 08:54:57 -0500

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=
[email-masked]> 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  :-)
>
>
>
> 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 <[email-masked]> on behalf of Laurence Lundblade <
> [email-masked]>
> *Date: *Monday, 21 March 2022 at 14:14
> *To: *Göran Selander <goran.selander=[email-masked]>
> *Cc: [email-masked] <[email-masked]>
> *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.
>
>
>
> 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 10, 2021, at 3:13 AM, Göran Selander <
> goran.selander=[email-masked]> 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?
>
>
>
> ‘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.
>
>
>
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose
>

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

<https://www.transmute.industries>

---

From: Göran Selander <[email-masked]>
Date: Mon, 21 Mar 2022 17:16:04 +0000

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 <[email-masked]>
Date: Monday, 21 March 2022 at 14:55
To: Göran Selander <[email-masked]>
Cc: Laurence Lundblade <[email-masked]>, [email-masked] <[email-masked]>
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

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=[email-masked]<mailto:[email-masked]>> wrote:
Hi Laurence,

Göran

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

LL

LL

_______________________________________________
COSE mailing list
[email-masked]<mailto:[email-masked]>
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>

---

From: Orie Steele <[email-masked]>
Date: Mon, 21 Mar 2022 12:43:08 -0500

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 <[email-masked]>
wrote:

> > 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.
>
>
>
> *From: *Orie Steele <[email-masked]>
> *Date: *Monday, 21 March 2022 at 14:55
> *To: *Göran Selander <[email-masked]>
> *Cc: *Laurence Lundblade <[email-masked]>, [email-masked] <
> [email-masked]>
> 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
>
>
>
>
> <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

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 21 Mar 2022 19:01:39 +0100

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 <[email-masked]> wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Orie,
> 
>  
> 
> To: Göran Selander <[email-masked] <mailto:[email-masked]>>
> Cc: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> Including ones that support https://datatracker.ietf.org/doc/html/rfc7638#section-1 <https://datatracker.ietf.org/doc/html/rfc7638#section-1>
> 
> See the original definition: https://datatracker.ietf.org/doc/html/rfc7517#section-4.5 <https://datatracker.ietf.org/doc/html/rfc7517#section-4.5>
> 
> On Mon, Mar 21, 2022 at 8:35 AM Göran Selander <goran.selander=[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Laurence,
> 
>  
> 
> From: COSE <[email-masked] <mailto:[email-masked]>> on behalf of Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> To: Göran Selander <goran.selander=[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> On Aug 13, 2021, at 3:01 AM, Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cose <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://www.transmute.industries/>

---

From: Orie Steele <[email-masked]>
Date: Mon, 21 Mar 2022 13:04:23 -0500

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 <[email-masked]>
wrote:

> then we break backwards compatibility for COSE as Mike pointed out today.
> So we need a separate parameter called kid2, ckid, intkid or such.
>
> On Mon, Mar 21, 2022 at 12:16 PM Göran Selander <
> [email-masked]> wrote:
>
>> Hi Orie,
>>
>>
>>
>> > 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.
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>> 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?
>>
>>
>>

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

---

From: Göran Selander <[email-masked]>
Date: Mon, 21 Mar 2022 18:10:15 +0000

Here is the history.

The objective is to have 1-byte COSE key identifiers to meet the requirements in the LAKE WG:
https://datatracker.ietf.org/doc/draft-ietf-lake-reqs/

Without going into the details, the overhead requirements of certain radio frames when you add sizes of ephemeral public keys and MACs etc. doesn't leave you many bytes for identifiers.

The thread in COSE started here:
https://mailarchive.ietf.org/arch/msg/cose/q_6kay8Z_4Wr48TFBXZU2oGRqoE/

The conclusion of that thread was there was a preference in the COSE WG for extending the COSE header `kid` to bstr / int.

Today the discussion restarted in the COSE WG, and Laurence picked up on that.

Göran

From: Orie Steele <[email-masked]>
Date: Monday, 21 March 2022 at 19:04
To: Laurence Lundblade <[email-masked]>
Cc: Göran Selander <[email-masked]>, [email-masked] <[email-masked]>
Subject: 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.

OS

On Mon, Mar 21, 2022 at 1:01 PM Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:
Let me try to be more clear.

   kid => bstr

If we make this change:

   kid => int / bstr

   intkid = int

or:

   intkid = int / bstr

LL

On Mar 21, 2022, at 6:43 PM, Orie Steele <[email-masked]<mailto:[email-masked]>> wrote:

OS

On Mon, Mar 21, 2022 at 12:16 PM Göran Selander <[email-masked]<mailto:[email-masked]>> wrote:
Hi Orie,

Thanks
Göran

From: Orie Steele <[email-masked]<mailto:[email-masked]>>
Date: Monday, 21 March 2022 at 14:55
To: Göran Selander <[email-masked]<mailto:[email-masked]>>
Cc: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
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.

Regards,

OS

Göran

LL

LL

--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a7ff2eb208872658&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&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=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=https%3A%2F%2Fwww.transmute.industries%2F>

--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a7ff2eb208872658&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&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=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=https%3A%2F%2Fwww.transmute.industries%2F>

---

From: Orie Steele <[email-masked]>
Date: Mon, 21 Mar 2022 13:14:57 -0500

Again, thank you... much clearer.

I assume that `kid` and `intkid` would both be legal in the same key.

that `kid` would be used for legacy use cases.

that `intkid` would be used for space constrained RF use cases.

that both would remain optional, and neither would impact thumbprints.

Use case makes sense, but it's pretty sad that a new key identifier is
required to meet the use case.

I don't see another solution though.

OS

On Mon, Mar 21, 2022 at 1:10 PM Göran Selander <[email-masked]>
wrote:

> Without going into the details, the overhead requirements of certain radio
> frames when you add sizes of ephemeral public keys and MACs etc. doesn't
> leave you many bytes for identifiers.
>
>
>
> The conclusion of that thread was there was a preference in the COSE WG
> for extending the COSE header `kid` to bstr / int.
>
>
>
> *Date: *Monday, 21 March 2022 at 19:04
> *To: *Laurence Lundblade <[email-masked]>
> *Cc: *Göran Selander <[email-masked]>, [email-masked] <
> [email-masked]>
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a7ff2eb208872658&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=http%3A%2F%2Fwww.transmute.industries%2F>
>
>
>
>
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-c169100f194b3f01&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=https%3A%2F%2Fwww.transmute.industries%2F>
>
>
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a7ff2eb208872658&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=http%3A%2F%2Fwww.transmute.industries%2F>
>
>
>
>
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-c169100f194b3f01&q=1&e=1c2f30fa-c80d-4168-83d6-0fb8158c9c7a&u=https%3A%2F%2Fwww.transmute.industries%2F>
>

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 21 Mar 2022 11:18:47 -0700

> (I don’t remember why an int kid was needed, but do remember I was convinced that it was)

So, if you make it required that you have exactly one of 'kid' or 'intkid',
you need signaling to know which one to use.  If you have that signaling,
it's not a huge stretch to instead use the signaling for "okay, 'kid' can
be int now".  There may be gaps, like group communication scenarios (but
then you have to weaken "exactly one"), but it seems more interesting to
explore those gaps than to just say there is breakage if you switch 'kid'
to int.  There is breakage if you just start sending something new and
expecting people to understand it, too!

To reiterate: if you want to roll out *anything* new, you need to have a
deployment plan.  So let's compare what the deployment plans look like for
int 'kid' and 'intkid', rather than comparing apples to oranges.

(It is probably also worth thinking about "you have at most one of 'kid' or
'intkid' and how things degrade if something would have benefited from
'kid' but actually got an 'intkid' that it doesn't understand.)

-Ben

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 21 Mar 2022 19:32:10 +0100

On 2022-03-21 19:18, Benjamin Kaduk wrote:
<snip>

> be int now". 

+1

Most signature schemes need to be profiled anyway.  In a use case where every byte counts, RSA keys would for example not be accepted.

Anders

---

From: Mike Prorock <[email-masked]>
Date: Mon, 21 Mar 2022 15:10:46 -0400

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

Mike Prorock
mesur.io

---

From: Orie Steele <[email-masked]>
Date: Mon, 21 Mar 2022 14:33:44 -0500

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 <[email-masked]> wrote:

>>> ‘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.
>>>
>>>
>>>

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Mar 2022 18:20:33 -0400

> then we break backwards compatibility for COSE as Mike pointed out

I don't think that this breaks *compatibility*
Old signed objects are still valid.

Things signed with a kid => int are incompatible with old implementations,
but so is "intkid => int", so there is no difference.  If you need to send
stuff to an old implementations (and the COSE ecosystem is very very young),
then can just stick to bstr format kids.

Old implementations can't process new things.  That's life.
Building things so that new features mean something to new implementations,
but are ignored by old implementations is called backwards compatibility.
But you can't have that anyway in this case.

It's one of the features of CBOR, as a self-describing format, that we can
introduce new ways to do things.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Mar 2022 00:00:24 +0100

> introduce new ways to do things.

Indeed.

So this is obviously an extension.  Old implementations can’t use the new data items enabled by that extension.
New implementations don’t have problems with old data items, so we call this backwards compatible, but not forward compatible.
We didn’t identify this as an extension point, so the lack of forward compatibility is likely to be universal — if you use an integer kid, old systems overwhelmingly will not understand you.

Now, there is also API compatibility — can you upgrade the COSE library without upgrading the using application.

I’d like to ask those who are proposing kid => int / bytes: are the two kid name spaces disjoint (so you need an API extension, too), or is an integer kid just a way to express the same kid as was already possible to express using a byte string kid.  Another way to say the latter is that all kids are byte strings and the integer representation is just a compressed way to express such a byte string.  Obviously, the latter way to interpret kids is slightly less efficient, because there are now two ways to express certain kids.  But the change is also local, i.e. you can do it in your library without changing anything else.

If we go for the latter, we will want to make sure that in particular the integers -24..23 map to useful byte strings and v.v.  Note that there is no need to make these byte strings short; e.g., a decimal representation (‘-24’ to ‘-1’ and ‘0' to ’23’ in CBOR DN), or maybe an octal one (’50’ to ’77’ and ’00’ to ’27’) would work well.  We don’t even need to support integers outside -24..23.

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 22 Mar 2022 04:59:43 +0100

It is hard for me to understand that the saving of a single byte it worth this much attention.

Anyway, if there will a change, it requires SW updates, but only for those who actually adopt the enhanced definition.  My guess is that connected systems nowadays support automatic firmware updates making the latter a non-issue.

In the COSE Signature Format (CSF) scheme I ran into the same issue and changed back-and-forth until I finally came up with the obvious: let key Id be a CBOR Object.

In a specific application using CSF, the profile was set to use "bstr".

I'm sure some people prefer "tstr" since it is JOSE compatible.  By revising/extending the COSE kid to Object, everybody get what they want.

Otherwise, I would suggest status quo.

Anders
https://test.webpki.org/csf-lab/home

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 22 Mar 2022 08:52:52 +0100

> On Mar 22, 2022, at 12:00 AM, Carsten Bormann <[email-masked]> wrote:
> 

From an API and implementation point of view, I like that int key IDs are just another way of putting the bytes on the wire.

Seems like we could just say that single byte kid value 0x01 can be encoded as bstr h’01’ or as integer 01. Allow this only for single byte kids in a range. Implementations error out for integers that can’t map to a single byte kid.

This keeps the COSE API, SW stack above and key databases the same, a byte string, no matter what encoding is used to convey.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 22 Mar 2022 09:01:49 +0100

> On Mar 21, 2022, at 11:20 PM, Michael Richardson <[email-masked]> wrote:
> 
> Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:

I guess you are right.

If you give 

    kid => int

to an existing implementation it will say “kid is in the wrong format”

If you give
   
   Intkid => int

to an existing implémentation it will say “there is no kid”

Can’t see it matters that much which.

LL

---

From: Göran Selander <[email-masked]>
Date: Tue, 22 Mar 2022 08:42:15 +0000

> I’d like to ask those who are proposing kid => int / bytes:  are the two kid name spaces disjoint

Yes. An integer kid is considered different from a byte string kid.

Just to be clear on the source. This proposal is based on a previous conclusion on the COSE mailing list considering different solutions:

Solution A.
kid => int / bytes

Solution B.
kid => bytes
kid2 => int / bytes

Solution C.
kid => bytes
kid2 => int

In this previous discussion (see first part of this thread [1]) there was a mild preference for A. We can revisit this now, but it is good if people participating in the discussion are aware of the arguments made previously.

Göran

[1] https://mailarchive.ietf.org/arch/msg/cose/q_6kay8Z_4Wr48TFBXZU2oGRqoE/

From: Carsten Bormann <[email-masked]>
Date: Tuesday, 22 March 2022 at 00:00
To: Michael Richardson <[email-masked]>
Cc: Laurence Lundblade <[email-masked]>, Orie Steele <[email-masked]>, Göran Selander <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [COSE] Key identifier of type bstr / int

Indeed.

Grüße, Carsten

---

From: Orie Steele <[email-masked]>
Date: Tue, 22 Mar 2022 08:58:21 -0500

I prefer A, and have appreciated learning the history of the issue... I
think the other proposals are not worth the cost.

OS

On Tue, Mar 22, 2022 at 3:42 AM Göran Selander <goran.selander=
[email-masked]> wrote:

> Just to be clear on the source. This proposal is based on a previous
> conclusion on the COSE mailing list considering different solutions:
>
>
>
> Solution A.
>
> kid => int / bytes
>
>
>
> Solution B.
>
> kid => bytes
>
> kid2 => int / bytes
>
>
>
> Solution C.
>
> kid => bytes
>
> kid2 => int
>
>
>
> In this previous discussion (see first part of this thread [1]) there was
> a mild preference for A. We can revisit this now, but it is good if people
> participating in the discussion are aware of the arguments made previously.
>
>
>
>
>
> Göran
>
>
>
> [1]
> *From: *Carsten Bormann <[email-masked]>
> *Date: *Tuesday, 22 March 2022 at 00:00
> *To: *Michael Richardson <[email-masked]>
> *Cc: *Laurence Lundblade <[email-masked]>, Orie Steele
> <[email-masked]>, Göran Selander <[email-masked]>,
> [email-masked] <[email-masked]>
> New implementations don’t have problems with old data items, so we call
> this backwards compatible, but not forward compatible.
> We didn’t identify this as an extension point, so the lack of forward
> compatibility is likely to be universal — if you use an integer kid, old
> systems overwhelmingly will not understand you.
>
> I’d like to ask those who are proposing kid => int / bytes: are the two
> kid name spaces disjoint (so you need an API extension, too), or is an
> integer kid just a way to express the same kid as was already possible to
> express using a byte string kid.  Another way to say the latter is that all
> kids are byte strings and the integer representation is just a compressed
> way to express such a byte string.  Obviously, the latter way to interpret
> kids is slightly less efficient, because there are now two ways to express
> certain kids.  But the change is also local, i.e. you can do it in your
> library without changing anything else.
>
> If we go for the latter, we will want to make sure that in particular the
> integers -24..23 map to useful byte strings and v.v.  Note that there is no
> need to make these byte strings short; e.g., a decimal representation
> (‘-24’ to ‘-1’ and ‘0' to ’23’ in CBOR DN), or maybe an octal one (’50’ to
> ’77’ and ’00’ to ’27’) would work well.  We don’t even need to support
> integers outside -24..23.
>
> Grüße, Carsten

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

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 23 Mar 2022 06:53:13 +0100

On 2022-03-22 14:58, Orie Steele wrote:
> I prefer A, and have appreciated learning the history of the issue... I think the other proposals are not worth the cost.

Right, it is backward compatible and doesn't break existing code and applications.  This would be similar to an API method where you add an optional argument.  You obviously have to update associated documents, with something like "introduced in API level 3".  Why couldn't that apply to RFCs as well?

Personally I would (in the name of symmetry), make "kid" arguments comparable to CBOR map keys.  That is, kid => CBOR data item.

Anders

> 
> OS
> 
> On Tue, Mar 22, 2022 at 3:42 AM Göran Selander <goran.selander=[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > I’d like to ask those who are proposing kid => int / bytes: are the two kid name spaces disjoint ____
> 
>     __ __
> 
>     Yes. An integer kid is considered different from a byte string kid. ____
> 
>     __ __
> 
>     __ __
> 
>     Just to be clear on the source. This proposal is based on a previous conclusion on the COSE mailing list considering different solutions:____
> 
>     __ __
> 
>     Solution A.____
> 
>     kid => int / bytes____
> 
>     __ __
> 
>     Solution B.____
> 
>     kid => bytes____
> 
>     kid2 => int / bytes____
> 
>     __ __
> 
>     Solution C.____
> 
>     kid => bytes____
> 
>     kid2 => int____
> 
>     __ __
> 
>     In this previous discussion (see first part of this thread [1]) there was a mild preference for A. We can revisit this now, but it is good if people participating in the discussion are aware of the arguments made previously.____
> 
>     __ __
> 
>     __ __
> 
>     Göran____
> 
>     __ __
> 
>     [1] https://mailarchive.ietf.org/arch/msg/cose/q_6kay8Z_4Wr48TFBXZU2oGRqoE/ <https://mailarchive.ietf.org/arch/msg/cose/q_6kay8Z_4Wr48TFBXZU2oGRqoE/>____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     *From: *Carsten Bormann <[email-masked] <mailto:[email-masked]>>
>     *To: *Michael Richardson <[email-masked] <mailto:[email-masked]>>
>     *Cc: *Laurence Lundblade <[email-masked] <mailto:[email-masked]>>, Orie Steele <[email-masked]>, Göran Selander <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
>     *Subject: *Re: [COSE] Key identifier of type bstr / int____
> 
>     On 21. Mar 2022, at 23:20, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
>     > 
>     >> kid => int / bstr
>     > 
>     Grüße, Carsten____

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Mar 2022 07:00:23 +0100

> Yes. An integer kid is considered different from a byte string kid.

OK. Is this a deliberate decision or did you consider making integers synonyms for certain byte strings?

(My proposal uses them as synonyms for certain two-byte strings.  This actually increases the surface of short identifiers as much as keeping them separate does.)

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 23 Mar 2022 08:33:49 +0100

I’m fine with A, but I’d like this to be the definition of it:

When a kid is an integer it is not a separate kid space, but rather a compact alternate encoding of some one-byte kid values. The one-byte kid values 0x00 through 0x30 may be encoded either as h’00’ through h’30’ or as the integers -24 through 23. That is, a one-byte kid is converted to an integer by subtracting 24 from it, putting on the wire as an integer and turned back into a byte string kid by adding 24.

Integer encoding is only permitted for single-byte kid’s between 0x00 to 0x30. (There is no encoding advantage for other kid values)

The point of the integer kid encoding is to service a particular use case where saving one by in the encoded kid is worth while. The integer kids will encode in one byte where as the byte strings of length one encode in two bytes.

It is advantageous to the COSE SW stacks, COSE APIs and COSE key databases that the integer-encoded kid not be a separate space from the byte-string encoded kids. If it is a separate space then the stacks, APIS and databases much carry a tag along side with the kid to indicate which kid space it is from.

LL

> On Mar 23, 2022, at 7:00 AM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 23 Mar 2022 09:47:50 +0100

Hello Carsten, COSE,

On Tue, Mar 22, 2022 at 12:00:24AM +0100, Carsten Bormann wrote:
> Now, there is also API compatibility — can you upgrade the COSE
> library without upgrading the using application.

I think this is a false gain. It will look like the API surface did not
changed (because the API can still represent every value as bytes as it
did before), but the application would also need to communicate to the
API whether or not the peer would accept an int-valued kid,
reintroducing the distinction.

(I also favor keeping the value spaces distinct because it makes best
use of the existing code points, and because additive typing is
something I consider good CBOR practice).

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 23 Mar 2022 10:26:33 +0100

Hello everyone,

attempting to summarize here:

* Ben and Michael made the argument[1][2] that older software will not
  recognize a kid2 just the same as it won't recognize a kid (and that
  either feature needs to be negotiated in a deployment plan).

  (Convincing Laurence[3] and Orie[4] who argued for a separate entry
  before).

* There is the open question of semantics -- whether these two kinds of
  values inhabit a single semantic value space (i.e., the int are a
  compressed form of some string) or whether they inhabit a typed space
  where an integer is distinct from every byte string. Carsten posed on
  [5], with a concrete suggestion.

  AIU this is still open, with the trade-off being between API impact (a
  single value space can be transparently exposed by the old API), code
  point efficiency and possibly others.

  Discussion is still ongoing.

Hoping I got all the latest points; I trust you complain loudly if you
feel misrepresented.

BR
Christian

[1]: https://mailarchive.ietf.org/arch/msg/cose/Z6J1ZScV_PzlLQ5tNdUMTDjR2IY/
[2]: https://mailarchive.ietf.org/arch/msg/cose/gztr1WhdzXT0LPRR7oLVbZI2qAw/
[3]: https://mailarchive.ietf.org/arch/msg/cose/0Gqhj3I1TqRyW_AprOs26PgC5bY/
[4]: https://mailarchive.ietf.org/arch/msg/cose/ozG-jYrFpcr1HrmGw9SNxAp3kuQ/
[5]: https://mailarchive.ietf.org/arch/msg/cose/1EXuPcjrGWSXNTk4rw2Ffp6Jpnk

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 23 Mar 2022 12:24:28 +0200

On Mon, Mar 21, 2022 at 02:13:50PM +0100, Laurence Lundblade wrote:
> compatibility. Looked at my code around this. That definitely seems
> like an issue. 
 
What does your code do if it encounters a recipient with int kid?

1. Treats the entiere message as malformed?
2. Ignores the recipient?
3. Something else? What?

And it is the implementations that do 1. (or 3. with some oddball
semantics) that worry me the most here. Not so much 2., as such
recipient is probably not correct anyway.

This also connects to the COSE-HPKE work: Where does one stick the
encapsulated ciphertext? It is naturally a bstr. It would seem natural
to stick it to the -1 (ephremeral key) field. Except that field is
defined to be a dictionary. However, this does not seem to stop editors'
copy from sticking a bstr to -1 field.

-Ilari

---

From: Tobias Looker <[email-masked]>
Date: Thu, 24 Mar 2022 00:57:27 +0000

> What does your code do if it encounters a recipient with int kid?

I agree with this concern but I may be miss understanding the underlying proposal here. I get the inclination to favour A as the option, but would it not involve changing the supported data type of a parameter? As an implementer I can see how some would view this as a breaking change specifically those who validate the value type of the parameter in accordance with its IANA registration. I don't think we should be encouraging a pattern where future specifications are able to redefine the value types supported for a particular parameter.

Thanks,

[Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>

Tobias Looker

MATTR
CTO

+64 (0) 27 378 0461
[email-masked]<mailto:[email-masked]>

[Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>

[Mattr on LinkedIn]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0>

[Mattr on Twitter]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0>

[Mattr on Github]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0>

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

________________________________
From: COSE <[email-masked]> on behalf of Ilari Liusvaara <[email-masked]>
Sent: 23 March 2022 23:24
To: [email-masked] <[email-masked]>
Subject: Re: [COSE] Key identifier of type bstr / int

EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.

-Ilari

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 24 Mar 2022 06:48:07 +0100

> I agree with this concern but I may be miss understanding the underlying proposal here. I get the inclination to favour A as the option, but would it not involve changing the supported data type of…

In context outside of standards, non-breaking (backward compatible) changes like this is industry practice.  In this case the question is rather if it is a "break-or-make" or "nice-to-have" feature.

I don't see how you can use something like COSE without having a profile for actual target.

This however, represents a more fundamental break since the keys are unrelated to existing OKP keys and algorithms:
https://datatracker.ietf.org/doc/draft-looker-cose-bls-key-representations/
I wouldn't go there at least since it is incompatible with "pluggable" cryptosystems.

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 24 Mar 2022 09:51:38 +0100

This I-D should IMHO hook into the previous PQK versus OKP discussions.

Since we apparently need additional RFCs for each new crypto system, the only gain with overloading OKP is saving one IANA registration.

In this particular case, I would strongly recommend defining "kty" as "BLS".

Code-wise this is close to a no-issue:
   switch(keyType) {
     case "EC":
        ...

     case "RSA":
        ...

     case "OKP":
     case "BLS":
         ...

However, this is a big simplification because in object oriented platforms like Java, BLS keys would anyway be represented by specific classes in the same way as Ed25519/Ed448 and X25519/X448 are today.  That is, possible code sharing isn't for real, while confusion is.

Related: https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029495.html

thanx,
Anders

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Mar 2022 14:47:20 +0100

Tobias Looker <tobias.looker=[email-masked]> wrote:
    > I agree with this concern but I may be miss understanding the
    > underlying proposal here. I get the inclination to favour A as the
    > option, but would it not involve changing the supported data type of a
    > parameter? As an implementer I can see how some would view this as a
    > breaking change specifically those who validate the value type of the
    > parameter in accordance with its IANA registration. I don't think we
    > should be encouraging a pattern where future specifications are able to
    > redefine the value types supported for a particular parameter.

CBOR specifically makes this kind of thing possible and easy.

Of course, it breaks if you can't process the new type.
You'll reject it.  That's fine. You'll reject anything you don't undrstand.
It's not backwards compatible.

The sender has to know if the receiver can support it.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Orie Steele <[email-masked]>
Date: Thu, 24 Mar 2022 09:12:36 -0500

In this case, I think they are lucky to be actually having curves, and not
some other thing that signals the actual key type.

https://datatracker.ietf.org/doc/html/rfc8037#section-2

I think it's a mistake to not use OKP for an elliptic curve public key
cryptosystem, especially if you will need to register a value for `crv` AND
you won't be using `y`.

I think the MUST for `crv` in there is also a big mistake, since OKP can
now only be used for EC... but we already had EC.

If we are not going to use OKP for new EC keys.... why did we create it?

To recap the problems with kty:

1. RSA isn't a key type, it's a cryptosystem family (1024, 2048, 4096,
etc....)
2. EC requires x and y because of a sad patent that is now expired, we
would have compressed from the start if we could have.
3. OKP works only for EC keys, and implies compression iirc.

Registering a new cryptosystem is getting harder and harder because of
these problems... there is a lot to debate and lots of possible ways that
we could proceed.

We need to write a convention and agree to it.

IMO, the convention moving forward should be:

1. If you are registering an elliptic curve, use OKP.
2. If you are registering a post quantum system, use PQK.... or if we want,
we can split PQK into "lattice", "hash" and "isogeny" variants.... so you
can register your system under those... we SHOULD NOT be registering a new
kty for every new cryptosystem.

Are pairing friendly curves worth their own kty? seperate from OKP?.... I
don't think so, but the considerations from 2 apply to pairing friendly
curves much like they apply to lattice based systems.

Registering kty seems to not be enough, so we will also register some `alg`
and then we will have the issues we outlined on this issue here:

https://github.com/mesur-io/post-quantum-signatures/issues/50

If `alg` remains optional, PQK keys will need to register yet another field
to signal dilithium, falcon, sphincs or xmss parameters...

Every parameter that is required is a chance to make mistakes.

When keys are generated, per NIST 800-57 they should be used for 1 purpose,
and configured for 1 algorithm, and this should not change... making alg
optional was a mistake.

You generate a key and then it's immutable... having key representations
that have algorithms that "pop in and out of existence" due to optionality,
is dangerous.

In the future, when someone figures out how to do "pairing friendly ECDH"
should BLS12381 keys just magically start supporting that?... no alg? why
not?

Imagine if knowing the key representation was spec valid, meant knowing it
was also safe to use... you need alg to know that.

An optional algorithm increases the chances of security misconfiguration,
and invites additional key parameterization that can easily lead to bugs.

TLDR; Let's write a rule for making sense of this moving forward, then
apply the rule to BLS12381 and Post Quantum systems, to determine what we
need to register.

OS

On Thu, Mar 24, 2022 at 3:51 AM Anders Rundgren <
[email-masked]> wrote:

> Since we apparently need additional RFCs for each new crypto system, the
> only gain with overloading OKP is saving one IANA registration.
>
> However, this is a big simplification because in object oriented platforms
> like Java, BLS keys would anyway be represented by specific classes in the
> same way as Ed25519/Ed448 and X25519/X448 are today.  That is, possible
> code sharing isn't for real, while confusion is.
>
> Related:
> https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029495.html
>
> thanx,
> Anders
>

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

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 24 Mar 2022 16:15:43 +0100

On 2022-03-24 15:12, Orie Steele wrote:
<snip>

> If we are not going to use OKP for new EC keys.... why did we create it?

OKP was undoubtedly created with good intents.  However, shutting the door to a more modular and pluggable approach to crypto system support (which currently is on the "menu"), is IMO a VERY BIG decision.

AFAIK, each of the CURRENT kty definitions represent:
- Keys for a more or less specific crypto system
- A unique namespace holding other, and for the associated key type and algorithms suitable parameters.

<snip>

> We need to write a convention and agree to it.

Totally agree.  It is now or never :)

My suggestion is simply freezing the existing kty definitions and create new ones when needed, like for BLS.  Using this convention, a generic PQK would not work.

Since few if any cryptographic platforms use COSE or JOSE as their native format, conversions will usually be needed.  IMO, this kty-specific, code naturally belongs to the same code base (aka provider) that implements the actual algorithms.

Thanx,
Anders

> 2. If you are registering a post quantum system, use PQK.... or if we want, we can split PQK into "lattice", "hash" and "isogeny" variants.... so you can register your system under those... we SHOULD NOT be registering a new kty for every new cryptosystem.
> 
> Are pairing friendly curves worth their own kty? seperate from OKP?.... I don't think so, but the considerations from 2 apply to pairing friendly curves much like they apply to lattice based systems.
> 
> Registering kty seems to not be enough, so we will also register some `alg` and then we will have the issues we outlined on this issue here:
> 
> https://github.com/mesur-io/post-quantum-signatures/issues/50 <https://github.com/mesur-io/post-quantum-signatures/issues/50>
> 
> If `alg` remains optional, PQK keys will need to register yet another field to signal dilithium, falcon, sphincs or xmss parameters...
> 
> When keys are generated, per NIST 800-57 they should be used for 1 purpose, and configured for 1 algorithm, and this should not change... making alg optional was a mistake.
> 
> You generate a key and then it's immutable... having key representations that have algorithms that "pop in and out of existence" due to optionality, is dangerous.
> 
> In the future, when someone figures out how to do "pairing friendly ECDH" should BLS12381 keys just magically start supporting that?... no alg? why not?
> 
> Imagine if knowing the key representation was spec valid, meant knowing it was also safe to use... you need alg to know that.
> 
> An optional algorithm increases the chances of security misconfiguration, and invites additional key parameterization that can easily lead to bugs.
> 
> TLDR; Let's write a rule for making sense of this moving forward, then apply the rule to BLS12381 and Post Quantum systems, to determine what we need to register.
> 
> OS
> 
> 
> On Thu, Mar 24, 2022 at 3:51 AM Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Related: https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029495.html <https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029495.html>
> 
>     thanx,
>     Anders
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Mar 2022 19:06:12 +0100

Michael Richardson <[email-masked]> wrote:
    > Of course, it breaks if you can't process the new type.  You'll reject
    > it.  That's fine. You'll reject anything you don't undrstand.  It's not
    > backwards compatible.

I received private email suggesting that surely I mean, forwards compatible.

Nope, I mean backwards compatible.  That means that a new sender can operate
with an older receiver.  MIME headers are backwards compatible.  The sender
doesn't need to know if my MTA supports DKIM headers, it can just put them
in. My end will ignore stuff it does not understand.  At the cost of
transfering those bytes.

If we change kid: to accept int as well as bstr, then a new sender who uses
*int* will not be understood by an older receiver.

But, since COSE is not a Protocol in of itself, but rather a building block
for some bigger protocol (like RATS EAT, or draft-ietf-anima-constrained-voucher),
if COSE adds int to the list of valid kids, then it would be up to EAT, or
constrained-voucher to say which version of COSE it supports.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Mar 2022 20:47:13 +0100

> On 2022-03-24, at 19:06, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 
> with an older receiver.  

That is actually forward compatibility.

* Backward compatibility = old data, new system.
In protocol design, we generally make sure we have backward compatibility, so we rarely speak about that.
Clearly, a system that does kid = int/bstr can deal with data that still assumes kid = bstr.

* Forward compatibility = new data, old system.
Since the sender in your example is just sending new data and would be relying on the old system to process it, this is a lack of forward compatibility.

These terms are not defined in an international standard that you must pass an exam about before you can post to or read from an IETF mailing list, so expect them to require explanation on each use.

> MIME headers are backwards compatible.  The sender

(That is forward compatibility.  Ignore-unknown is a great principle.  Sometimes it needs “must-understand” [critical] flags to prevent false interoperability, if forward compatibility cannot be assured by just ignoring the unknown.)

> *int* will not be understood by an older receiver.

Exactly, new data, old system, no forward compatibility. 
Assuming that kid is “must understand”, that is.

> constrained-voucher to say

Yes.

> which version of COSE it supports.

No, no, no.  COSE does not have “versions”.
➔ “Which feature-set it requires from COSE”.

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 25 Mar 2022 10:00:44 +0100

> On Mar 23, 2022, at 11:24 AM, Ilari Liusvaara <[email-masked]> wrote:
> 

For option A, t_cose would reject the whole message.

For option B or C, t_cose would accept the message unless intkid was marked as critical, in which case it would correctly reject the message. There would be no way to get the intkid or even know it exists, though a future version of t_cose will be more extensible in that regard.

You can classify end-end systems using COSE kid into 3:

1) mandatory — receiving app can’t function without a kid
2) kid not used
   2a) not used and reject the message if it is present
   2b) not used, don’t care if it is present
3) optional, some messages can have a kid and it will be used, but there is some means other than a kid parameter for finding the key

Note that this list is about kid, not about integer kid. Mandatory means it must have a kid the system can understand.

Assuming t_cose behavior, Option A works fine for systems 1) and 2a), but not 2b) or 3).

Options B and C work for all system.

Since integer kid is only for a small optimization you might be tempted to use the two-byte encoding for compatibility with all COSE libraries if the optimization isn’t absolutely critical. In coming vast spread of COSE use cases, the integer kid will only be used very rarely, so maybe better not to confuse the existing kid parameter.

Now I am leaning towards B or C.

LL