Thanks Laurence, thanks Ben! Summarising the feedback so far, there seems to be a mild preference for extending 'kid' as int/bstr documented in a standards track RFC and with expert review. (More comments are welcome.)
Next question: Is there a preference for making this a stand-alone draft or can we include the extension in draft-ietf-lake-edhoc? Do we consider this an update of RFC-to-be 9052 (draft-ietf-cose-rfc8152bis-struct)? Thanks Göran From: COSE <[email protected]> on behalf of Laurence Lundblade <[email protected]> Date: Friday, 13 August 2021 at 03:02 To: Göran Selander <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [COSE] Key identifier of type bstr / int Understood about the use case. Thx for the background. On Aug 10, 2021, at 3:13 AM, Göran Selander <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/cose
