Subject: Re: [jose] JSON Web Key (JWK) Thumbprint Specification

From: Mike Jones <[email-masked]>
Date: Fri, 20 Feb 2015 00:46:06 +0000

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-masked]] On Behalf Of Manger, James
> Sent: Monday, April 14, 2014 10:35 PM
> To: [email-masked]; 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

---

From: "Manger, James" <[email-masked]>
Date: Fri, 20 Feb 2015 14:04:35 +1100

> 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).

Mike & Nat,
The extra Security Consideration paragraph is okay, but it should explicitly mention that JWK thumbprints are not suitable (or MUST NOT be used) in blacklists.
I would also drop the phrase about being lax in validating. I don’t think we can blame an implementation (by calling it lax) if it doesn't notice and reject "e":"AAEAAQ". I’m sure we can't call it lax if it doesn’t notice and reject "n":"<3 * n>", even though such a key would still "work" a third of the time.

--current text

   A JWK Thumbprint will only uniquely identify a particular key if a
   single unambiguous JWK representation for that key is defined and
   used when computing the JWK Thumbprint.  (Such representations are
   defined for all the key types defined in JSON Web Algorithms (JWA)
   [JWA].)  For example, if an RSA key were to use "e":"AAEAAQ"
   (representing [0, 1, 0, 1]) rather than the specified correct
   representation of "e":"AQAB" (representing [1, 0, 1]), a different
   thumbprint value would be produced for what could be effectively the
   same key, at least for implementations that are lax in validating the
   JWK values that they accept.  Thus, JWK Thumbprint values can only be
   relied upon to be unique for a given key if the implementation also
   validates that the correct representation of the key is used.

--alternative suggestion

   JWK Thumbprints are not suitable for use in blacklists to identify
   unwanted JWKs. An attacker may be able to use an unusual JWK
   representation for a key that will result in a different thumbprint.
   For example, if an RSA key were to use "e":"AAEAAQ"
   (representing [0, 1, 0, 1]) rather than the specified correct
   representation of "e":"AQAB" (representing [1, 0, 1]), a different
   thumbprint value would be produced for effectively the same key.

--
James Manger

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 20 Feb 2015 12:20:27 -0800

> From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
> Sent: Thursday, February 19, 2015 4:46 PM
> To: Manger, James; [email-masked]
> 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.
> 
> > 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).
> 
> > 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).
> 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").
> >
> > 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>"?
> >
> > 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.
> 
> > 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.
> 
> > > 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.
> 
> > 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.
> 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-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Thu, 26 Feb 2015 17:17:13 +0000

James, the -03 draft adds explicit text about thumbprints not being an effective means of blacklisting keys.  Thanks again for your valuable reviews.

				-- Mike & Nat

-----Original Message-----
From: Manger, James [mailto:[email-masked]] 
Sent: Thursday, February 19, 2015 7:05 PM
To: Mike Jones; [email-masked]
Subject: RE: [jose] JSON Web Key (JWK) Thumbprint Specification

Mike & Nat,

--current text

--alternative suggestion

--
James Manger