On Sat, Jul 09, 2022 at 07:39:34PM +0200, Anders Rundgren wrote: > On 2022-07-09 13:50, John Mattsson wrote: > > Hi, > > > > Recent COSE comment from Charlie Jacomme on the LAKE WG Github [1] > > > > "As stated in Section 3.1 of [I-D.ietf-cose-rfc8152bis-struct], > > applications MUST NOT assume that 'kid' values are unique, and several keys > > associated with a 'kid' may need to be checked before the correct one is > > found. Applications might use additional information such as 'kid context' > > or lower layers to determine which key to try first. Applications should > > strive to make ID_CRED_x as unique as possible, since the recipient may > > otherwise have to try several keys." > > > > I understood that a kid would map to multiple keys, but all of those keys > > would be owned by the same party. From what I understand, the attack > > described here only occurs when one kid maps to keys owned by distinct > > parties. > > Which is the correct interpretation? And should the second case actually be > > allowed? > > > > My reply > > > > My interpretation of COSE is that one kid might map to keys owned by > > distinct parties. Seems hard to guarantee anything about kids unless there > > is a single authority that controls all the kids. as soon as there are > > several authorities there might be collisions. That all the keys with a > > certain kid belongs to a single party would require that a single authority > > determines all the kids or that some additional header parameter like > > kid_context is used. I think the whole reason that kid_context was > > introduced was to separate between different authorities determining kids. > > > > Whatever the answer is, it might be good to update > > ietf-cose-rfc8152bis-struct with a sentence to clarify. > > To me the I-D text is utter nonsense; nobody (in their right mind...) would > use the same identifier for multiple keys.
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.) 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.""" 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
