> -----Original Message----- > From: jose [mailto:[email protected]] On Behalf Of Mike Jones > Sent: Thursday, February 19, 2015 4:46 PM > To: Manger, James; [email protected] > Subject: Re: [jose] JSON Web Key (JWK) Thumbprint Specification > > 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.
My expectation is that if a EC curve is registered that only requires a "x" value, this will be a new "kty" so that there is no ambiguity about what the set of required fields are. Jim > > > 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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
