>If LAKE presumes using "kid" as a hint only, LAKE presumes nothing more than COSE. This discussion in not really related to LAKE at all. COSE presumes that "kid" can be used as a hint only.
That your system puts additional requirement on kid are fine. But it is dangerous if you assume that all other systems works like that. COSE has had significant problems with implementations not following the specification, e.g., making wrong assumptions regarding signature algorithms. Having a unique global kids are easy. You just use large 32 byte random strings and maybe some other information. Using 32 byte COSE kid is however not optimal or even realistic in e.g., US Lorawan system with 11 byte frames and long waiting time between you are allowed to send new frames. Then you want to use kids that encode to 1, or 2 bytes. John From: Anders Rundgren <[email protected]> Date: Monday, 11 July 2022 at 10:17 To: Benjamin Kaduk <[email protected]> Cc: John Mattsson <[email protected]>, [email protected] <[email protected]> Subject: Re: [COSE] Clarification on kid collisions needed in ietf-cose-rfc8152bis-struct? On 2022-07-11 6:23, Benjamin Kaduk wrote: > On Sat, Jul 09, 2022 at 07:39:34PM +0200, Anders Rundgren wrote: <snip> >> To me the I-D text is utter nonsense; nobody (in their right mind...) would >> use the same identifier for multiple keys. May I as a seasoned system architect add some comments to this? Note, I'm not suggesting an update of the text, only explain why it is wrong :) TL;DR, > When every byte on the wire counts, you're definitely going to use the same > identifier for multiple keys (e.g., h'00', h'01' as Carsten noted in the > follow-up), and everybody else is also going to want to use those same > short identifiers, too. I am very confident that the intent of COSE is for > "kid" to be a tool that a recipient can use to filter which of the set of > keys they have/trust to attempt to perform cryptographic validation with, > but that the ultimate test is "does the key work?", and "kid" is just an > aid to finding the intended key. (The reason for my confidence is that my > initial assumption was also a "one kid, one key" relationship with the > "kid" uniquely identifying the intended key, and it took Jim and others a > lot of time to convince me that that's not what's going on.) In reality systems using "kid", rely on highly application-specific conventions and communication between the involved parties. If such a convention leads to relying parties having to defer to "trial-and-error" methods to figure out what key to use, my assertion is that the information architecture model is broken which out of scope for COSE. This is independent of the length and characteristics of "kid" since h'01' may very well mean the second key associated with the specific sender/producer, if we are talking about signatures. If LAKE presumes using "kid" as a hint only, I would seriously consider an information architecture design review before progressing. > We see this from the draft's text, e.g., in """This field is intended for > matching against a "kid" parameter in a message in order to filter down the > set of keys that need to be checked. The value of the identifier is not a > unique value and can occur in other key objects, even for different > keys.""" and """Key identifier values are hints about which key to use. > This is not a security-critical field. For this reason, it can be placed in > the unprotected-header-parameters bucket.""" Since "kid" is entirely application-dependent, the text above does thus (IMO) not have an entirely natural place in a general purpose standard. If there are multiple (and identified) senders/producers, each of them may have their own "kid" name-space, making "kid" duplicates a no-issue. In the other end of the spectrum, "kid" may even hold a full-fledged X.509 certificate path (or an URL to to it), permitting third-party issuance and no prearranged keys beyond CA roots. To give yet another example of the kind of variations you may run into, a recent system of mine does not use "kid" but rather the full public key. The reason for that is because it permits the RP to check a huge number of things in received messages including technically validating the signature. Only if all checks pass, a potentially expensive SQL database lookup is performed to verify that the claimed identity and the hash of the public key actually match an entry in the client database. Cheers, Anders > > I'm somewhat amenable to the position that if this sentiment is not coming > through clearly, we would want to add some text to make it come through > clearly, but I'm also not entirely sure what text that would be, and don't > remember seeing any proposals for such text. > > -Ben
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
