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 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
