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

[Benjamin Kaduk <[e-mail]>]

On Fri, Jul 30, 2021 at 12:28:58PM +0000, Göran Selander 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?

I think so.  There's a decent case that just standards action would
suffice, but I like ensuring that the experts also weigh in.

>From the follow-up:

> Another alternative to what has been listed below is to define 'kid2' to
> only be of type int - is that a better option?

That would avoid some of the decoder complexity that Laurence raised, but
leaves the issue of needing logic to handle a message that sets both 'kid'
and 'kid2'.  For a long-term steady-state best outcome I don't see a huge
difference between an expanded 'kid' and deprecating 'kid' entirely in
favor of a 'kid2' that does both.  I'm less sure how to compare that option
against the one-parameter-per-type option (kid==bstr, kid2==int) that is
easier to decode but has the possibility to provide both parameters.

-Ben