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.
Since this (obviously) is not apparent, I immediately updated my "COSE
challenger" docs to indeed require uniqueness:
https://cyberphone.github.io/javaapi/org/webpki/cbor/doc-files/signatures.html#parameters
Anders
Cheers,
John
[1] https://github.com/lake-wg/edhoc/issues/317
<https://github.com/lake-wg/edhoc/issues/317>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
