Thanks again for your thoughtful feedback, James. While many of these comments had been addressed in earlier individual and working group drafts, replies are included here (inline) for completeness.
> -----Original Message----- > From: jose [mailto:[email protected]] On Behalf Of Manger, James > Sent: Monday, April 14, 2014 10:35 PM > To: [email protected]; John Bradley > Subject: Re: [jose] JSON Web Key (JWK) Thumbprint Specification > > Comments on JWK thumbprints: > http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00 > > draft-jones-jose-jwk-thumbprint needs to be much clearer about the properties > of a thumbprint and the circumstances where it is appropriate and > inappropriate to use. Superficially a thumbprint looks like both an > unambiguous id and a unique id for a key, but I doubt the latter property can > be relied upon. > > For instance, it would be dangerous to use these thumbprints in a blacklist > of revoked keys. It looks fairly easy for a malicious party to modify the > representation of a key to give a different thumbprint for the same key (eg > change "e":"AQAB" to "e":"AAEAAQ"). Thanks for pointing this out and for the example. This is now discussed in a new Security Considerations paragraph in WG draft -02 (which, in fact, uses your example). > "Only the REQUIRED members of a key's representation are used" > This rule sounds like trouble. > Consider a key that is a point on an elliptic curve. Sometimes x & y are > specified; sometimes the crypto only uses the x coordinate; sometimes y is > "compressed" to a flag. It seems quite feasible that a JWK format might not > REQUIRE "y" in its syntax. > Consider an element that has a default value when absent. It is not REQUIRED > in the syntax (so would be omitted from the thumbprint), but it can still be > required to be understood when it is present. All key types defined in JWA do unambiguously define which members are REQUIRED, and it's reasonable to expect that any new key types would also do so. Addressing your particular example, note that http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-6.2.1 already handles the case you raise, and in particular, 6.2.1.1 says "Specifications registering additional curves must define what parameters are used to represent keys for the curves registered". So it's perfectly legal for some new curves to use only "crv" and "x" to represent keys, in which case, the REQUIRED parameter set would still be well-defined. > It is a bit nasty that you cannot calculate a key’s thumbprint without > type-specific knowledge (about which elements to keep). > Keeping all JWK elements in the thumbprint would be better. As discussed in other threads, this would have the significant downside of meaning that the thumbprint would change depending upon what optional parameters were also included. As for type-specific knowledge being required, that's certainly true of any code that *uses* a key, so it isn't onerous for type-specific knowledge to likewise be required to compute the JWK thumbprint of a key. > The spec defines a canonical JSON encoding without explicitly admitting that > (eg it doesn't use the word "canonical"). > > "Characters .. MUST be represented in the simplest manner possible" > What is the "simplest manner possible"? I guess "a" is simpler than "\u0061"; > less sure about "\n" vs "\u000A"; no idea for "\u000b" vs "\u000B"; escaping > "/" as "\/" is (unfortunately) simpler in some environments; "\uD834\uDD1E" > vs the 4-bytes "<F0 9D 84 93>"? > > "all characters within the Basic Multilingual Plane .. MUST NOT be escaped" > Is this hinting that U+1D11E (musical symbol G clef) that is outside the BMP > should be escaped? Surely it is better to UTF-8 encoded this as 4 bytes. All of this text was removed in response to your note in July 2014, for the reasons that you cited. > There is no mention of how to handle elements whose value is a number. > It is easy to imagine key formats with integer fields (eg a PBKDF iteration > count). Presumably an element "p2c":1e5 would actually have to be serialized > as "p2c":100000. > I guess this doc is going ignore floating point numbers under the (fairly > reasonably) assumption that they may never be needed in JWKs. Text on handling numbers was added in July 2014 in response to your comments. > John Bradley said: > > Having a well understood method that is resistant to bit stealing and other > > sorts of attacks is a good thing, rather than applications rolling there > > own. > > What is "bit stealing"? By bit stealing, John was referring to situations when it's ambiguous whether bits belong to one field or another adjacent one. If, for instance, JWK field values were simply concatenated without including delimiters between them, "bit stealing" could occur between them. > > This is useful in OpenID Connect for calculating a synthetic subject based > > on the public key of a self signed JWT. > > If a key and its thumbprint are both in a message it is asking for trouble as > some code will assume (without checking) that they match. > A "jkt" member in a JWK is a bad idea. This comment is actually about a choice made in OpenID Connect and not about this spec. The one place where it used to be pertinent in the -01 WG spec (the "jkt" field definitions) was removed, per working group input, from the -02 spec. > -- > James Manger Thanks again, -- Mike & Nat _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
