Below > On Jul 10, 2022, at 9:23 PM, Benjamin Kaduk <[email protected]> wrote: > > 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.
Always wondered why you’d do this. Now I know. :-) > 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.) Makes sense. > 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. Didn’t come across for me from the draft. I think it is also quite reasonable for use cases to require that the kid uniquely identify the key. Perhaps the recipient is a constrained device that doesn’t have the CPU power to do multiple crypto operations. Or perhaps some API to some extant database doesn’t facilitate returning multiple records. In these cases they would violate the MUST NOT in the draft, so I’m not such a fan of that text. With X.509-based COSE, we’re going to have identifiers that involves DNs. Not sure if those should go in the kid or not. In EAT, sometimes the key identifier is in the COSE payload to save bytes on the wire. Key look up and key databases seems like something that varies a lot by use case. In EAT (a user of COSE) the key lookup method is a profile issue that varies by use case like the selection of crypto algorithms. I think COSE must support all of these use cases, but it does kind of make it hard to think about kid and hard to know what to implement. LL _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
