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

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

Thanks Laurence, these trade-offs are important to consider. The final message optimization is one of the open issues (#103) on the LAKE github and your comment is good input to that discussion. The background for this is the requirement for the LAKE protocol to perform well in constrained radio settings with small frame sizes where performance may be significantly degraded by exceeding certain limits. For these settings, every byte counts and some bytes just cannot be avoided, like a message authentication code or an ephemeral public key.

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?

Other thoughts?

Göran


From: Laurence Lundblade <[e-mail]>
Date: Monday, 9 August 2021 at 20:11
To: Göran Selander <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [COSE] Key identifier of type bstr / int

A small comment on code size as the author of a commercial-quality COSE implementation designed to have small code size.

There is a bit of a trade-off between code size and bytes on the wire. Reducing the bytes on the wire by one byte in this case will lead to an increase in code size by a lot more than one byte, assuming both int and bstr are supported. If both are not supported, then there is #ifdef complexity and configuration work with general purpose COSE implementations.

Most of the code cost for me in implementing COSE is in the header parameter decoding.

This desire to save 1 CBOR byte here and there at the cost of code / complexity shows up elsewhere. Here’s one from CoSWID

one-or-more<T> = T / [ 2* T ]

This could just be an array.

I don’t know the use cases, but I’m a little skeptical these sorts of things are worth a byte or two on the wire.

LL




On Jul 30, 2021, at 5:28 AM, Göran Selander <goran.selander=[e-mail]<mailto:goran.selander=[e-mail]>> wrote:

Hi,

In LAKE yesterday we had a discussion on compact key identifiers. The main candidate to use, 'kid', is specified as a CBOR bstr, which is typically at least 2 bytes (exception: empty bstr which is 1 byte). We therefore want to allow keys to be identified with CBOR ints which has 48 1-byte values to allow for a larger number of optimally small identifiers.

One solution would be to define a new COSE key common parameter and COSE header parameter, say 'kid2', of type bstr / int. Another solution would be to extend 'kid' to be bstr / int.

In the former case a 'kid2' can be used to reference keys identified with either 'kid2' or 'kid', but 'kid' would not be able to reference keys identified with 'kid2' having an int value. Not clear to me if that is a problem.

While the LAKE WG did not express any preference, one opinion I learnt after the meeting was a preference of extending 'kid' to bstr / int.

What do folks in COSE think?

I'm familiar with the process of registering new COSE parameters, what is the requirement for changing the value type of an existing registration? Standards action with expert review?

Thanks
Göran


_______________________________________________
COSE mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose