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

From: Mike Jones <[email-masked]>
Date: Fri, 11 Apr 2014 00:49:33 +0000

I created a new simple spec that defines a way to create a thumbprint of an arbitrary key, based upon its JWK representation.  The abstract of the spec is:

This specification defines a means of computing a thumbprint value (a.k.a. digest) of JSON Web Key (JWK) objects analogous to the x5t (X.509 Certificate SHA-1 Thumbprint) value defined for X.509 certificate objects. This specification also registers the new JSON Web Signature (JWS) and JSON Web Encryption (JWE) Header Parameters and the new JSON Web Key (JWK) member name jkt (JWK SHA-256 Thumbprint) for holding these values.

The desire for this came up in an OpenID Connect context, but it's of general applicability, so I decided to submit the spec to the JOSE working group.  Thanks to James Manger, John Bradley, and Nat Sakimura for the discussions that led up to this spec.

The specification is available at:

*        http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00

An HTML formatted version is also available at:

*        https://self-issued.info/docs/draft-jones-jose-jwk-thumbprint-00.html

                                                            -- Mike

P.S.  I also posted this notice at http://self-issued.info/?p=1213 and as @selfissued.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 10 Apr 2014 23:30:38 -0400

Dear lord, can we just say "fingerprint" like the rest of the universe?

On Thu, Apr 10, 2014 at 8:49 PM, Mike Jones <[email-masked]>wrote:

>  I created a new simple spec that defines a way to create a thumbprint of
> an arbitrary key, based upon its JWK representation.  The abstract of the
> spec is:
>
>
>
> This specification defines a means of computing a thumbprint value (a.k.a.
> digest) of JSON Web Key (JWK) objects analogous to the x5t (X.509
> Certificate SHA-1 Thumbprint) value defined for X.509 certificate objects.
> This specification also registers the new JSON Web Signature (JWS) and JSON
> Web Encryption (JWE) Header Parameters and the new JSON Web Key (JWK)
> member name jkt (JWK SHA-256 Thumbprint) for holding these values.
>
>
>
> The desire for this came up in an OpenID Connect context, but it's of
> general applicability, so I decided to submit the spec to the JOSE working
> group.  Thanks to James Manger, John Bradley, and Nat Sakimura for the
> discussions that led up to this spec.
>
>
>
> ·        http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00
>
>
>
> ·
> https://self-issued.info/docs/draft-jones-jose-jwk-thumbprint-00.html
>
>
>
>                                                             -- Mike
>
>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 11 Apr 2014 04:49:50 +0000

You're living in a different part of the world, apparently.  Most of the specs that I use utilize the term "thumbprint", including ones such as http://msdn.microsoft.com/en-us/library/windows/desktop/aa376544(v=vs.85).aspx.

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, April 10, 2014 8:31 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] JSON Web Key (JWK) Thumbprint Specification

On Thu, Apr 10, 2014 at 8:49 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I created a new simple spec that defines a way to create a thumbprint of an arbitrary key, based upon its JWK representation.  The abstract of the spec is:

                                                            -- Mike

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Daniel Holth <[email-masked]>
Date: Mon, 14 Apr 2014 14:27:13 -0400

Here's a compatible Python implementation I did in March of last year.
https://bitbucket.org/dholth/jkf

It only lacks support for symmetric keys.

On Thu, Apr 10, 2014 at 8:49 PM, Mike Jones <[email-masked]> wrote:
> I created a new simple spec that defines a way to create a thumbprint of an
> arbitrary key, based upon its JWK representation.  The abstract of the spec
> is:
>
>
>
> Web Encryption (JWE) Header Parameters and the new JSON Web Key (JWK) member
> name jkt (JWK SHA-256 Thumbprint) for holding these values.
>
>
>
> The desire for this came up in an OpenID Connect context, but it’s of

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 14 Apr 2014 13:06:40 -0700

What are the practical benefits for this over using the kid parameter?

Jim

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Thursday, April 10, 2014 5:50 PM
To: [email-masked]
Subject: [jose] JSON Web Key (JWK) Thumbprint Specification

.         http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00

.

                                                            -- Mike

P.S.  I also posted this notice at http://self-issued.info/?p=1213 and as
@selfissued.

---

From: Daniel Holth <[email-masked]>
Date: Mon, 14 Apr 2014 16:38:59 -0400

For me the finger/thumbprint is something you could sign as part of an
"I trust this key" assertion since it is a property of a specific key
rather than an arbitrary association.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 14 Apr 2014 13:38:51 -0700

I would have problems with that if it did not come with additional restrictions on the key that I might want to additionally state -such as restricting the key to be used with specific algorithms or key usages.

> -----Original Message-----
> From: Daniel Holth [mailto:[email-masked]]
> Sent: Monday, April 14, 2014 1:39 PM
> To: Jim Schaad
> Cc: Mike Jones; jose
> For me the finger/thumbprint is something you could sign as part of an "I trust
> this key" assertion since it is a property of a specific key rather than an
> arbitrary association.
> 
> > I created a new simple spec that defines a way to create a thumbprint
> > of an arbitrary key, based upon its JWK representation.  The abstract
> > of the spec
> > is:
> >
> >
> >
> > This specification also registers the new JSON Web Signature (JWS) and
> > JSON Web Encryption (JWE) Header Parameters and the new JSON Web Key
> > (JWK) member name jkt (JWK SHA-256 Thumbprint) for holding these values.
> >
> >
> >
> > The desire for this came up in an OpenID Connect context, but it s of
> > general applicability, so I decided to submit the spec to the JOSE
> > working group.  Thanks to James Manger, John Bradley, and Nat Sakimura
> > for the discussions that led up to this spec.
> >
> >
> >
> >           http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00
> >
> >
> >

---

From: Daniel Holth <[email-masked]>
Date: Mon, 14 Apr 2014 16:50:31 -0400

The thumbprint includes the algorithm but not the usage restrictions.
A practical certificate would certainly include "trusted for ..."
constraints. Simply not having to store the kid since a substitute can
be computed from the actual key material is advantage enough for me.

---

From: John Bradley <[email-masked]>
Date: Mon, 14 Apr 2014 18:01:54 -0300

kid is just a name for a key.   The thumbprint is a way to refer to a key in a signed message without having to send the entire key.
This is useful in OpenID Connect for calculating a synthetic subject based on the public key of a self signed JWT.

It is also useful in proof of possession scenarios where it may be sufficient to include a hash of the public key needed for the proof in the assertion rather than the whole key each time.

The problem with kid is that in the PoP case you would need a out of band way to transfer the key sot of defeating the benefit of stateless tokens.

So it is a sort of kid but one that is unique to a given key in a collision resistant way.

John B.

On Apr 14, 2014, at 5:06 PM, Jim Schaad <[email-masked]> wrote:

> This specification defines a means of computing a thumbprint value (a.k.a. digest) of JSON Web Key (JWK) objects analogous to the x5t (X.509 Certificate SHA-1 Thumbprint) value defined for X.509 certificate objects. This specification also registers the new JSON Web Signature (JWS) and JSON Web Encryption (JWE) Header Parameters and the new JSON Web Key (JWK) member name jkt(JWK SHA-256 Thumbprint) for holding these values.
>  
> The desire for this came up in an OpenID Connect context, but it’s of general applicability, so I decided to submit the spec to the JOSE working group.  Thanks to James Manger, John Bradley, and Nat Sakimura for the discussions that led up to this spec.
>  
> ·         https://self-issued.info/docs/draft-jones-jose-jwk-thumbprint-00.html
>  
>                                                             -- Mike
>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 14 Apr 2014 14:34:18 -0700

No, it includes the key type not the algorithm.  It says this is an RSA key not that this is an RSA key to be used with the RSA-PSS-with-SHA512 algorithm.

> Sent: Monday, April 14, 2014 1:51 PM
> To: Jim Schaad
> Cc: Mike Jones; jose
> constraints. Simply not having to store the kid since a substitute can be
> computed from the actual key material is advantage enough for me.
> 
> > I would have problems with that if it did not come with additional restrictions
> on the key that I might want to additionally state -such as restricting the key to
> be used with specific algorithms or key usages.
> >
> >
> >> For me the finger/thumbprint is something you could sign as part of
> >> an "I trust this key" assertion since it is a property of a specific
> >> key rather than an arbitrary association.
> >>
> >> > I created a new simple spec that defines a way to create a
> >> > thumbprint of an arbitrary key, based upon its JWK representation.
> >> > The abstract of the spec
> >> > is:
> >> >
> >> >
> >> >
> >> > This specification also registers the new JSON Web Signature (JWS)
> >> > and JSON Web Encryption (JWE) Header Parameters and the new JSON
> >> > Web Key
> >> > The desire for this came up in an OpenID Connect context, but it s
> >> > of general applicability, so I decided to submit the spec to the
> >> > JOSE working group.  Thanks to James Manger, John Bradley, and Nat
> >> > Sakimura for the discussions that led up to this spec.
> >> >
> >> >
> >> >

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 14 Apr 2014 14:37:57 -0700

And to me all this sounds like is that there should be a document which says
- this is one way to compute a kid value and then let the application say
that this will be the way to do it.  Much like how SPKIs are done for X.509
certificates today.

Jim

From: John Bradley [mailto:[email-masked]] 
Sent: Monday, April 14, 2014 2:02 PM
To: Jim Schaad
Cc: Michael Jones; [email-masked]
Subject: Re: [jose] JSON Web Key (JWK) Thumbprint Specification

kid is just a name for a key.   The thumbprint is a way to refer to a key in
a signed message without having to send the entire key.

This is useful in OpenID Connect for calculating a synthetic subject based
on the public key of a self signed JWT.

It is also useful in proof of possession scenarios where it may be
sufficient to include a hash of the public key needed for the proof in the
assertion rather than the whole key each time.

The problem with kid is that in the PoP case you would need a out of band
way to transfer the key sot of defeating the benefit of stateless tokens.

So it is a sort of kid but one that is unique to a given key in a collision
resistant way.

John B.

Jim

name jkt(JWK SHA-256 Thumbprint) for holding these values.

.          <http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00>
http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00

.
<https://self-issued.info/docs/draft-jones-jose-jwk-thumbprint-00.html>
https://self-issued.info/docs/draft-jones-jose-jwk-thumbprint-00.html

                                                            -- Mike

P.S.  I also posted this notice at  <http://self-issued.info/?p=1213>
http://self-issued.info/?p=1213 and as @selfissued.

---

From: Mike Jones <[email-masked]>
Date: Mon, 14 Apr 2014 21:41:37 +0000

If your protocol wants to impose particular algorithm restrictions it can obviously do that.  And the key, as transmitted by your protocol, can include, and in fact, can require an "alg" field.

That's separate from the thumbprint value for the key, which is intentionally computed without any of the optional field values, so that its value is invariant both in their presence and in their absence.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, April 14, 2014 2:34 PM
To: 'Daniel Holth'
Cc: Mike Jones; 'jose'
Subject: RE: [jose] JSON Web Key (JWK) Thumbprint Specification

> on the key that I might want to additionally state -such as 
> restricting the key to be used with specific algorithms or key usages.
> >
> >
> >> an "I trust this key" assertion since it is a property of a 
> >> specific key rather than an arbitrary association.
> >>
> >> On Mon, Apr 14, 2014 at 4:06 PM, Jim Schaad 
> >> <[email-masked]>
> wrote:
> >> > This specification also registers the new JSON Web Signature 
> >> > (JWS) and JSON Web Encryption (JWE) Header Parameters and the new 
> >> > JSON Web Key
> >> > The desire for this came up in an OpenID Connect context, but it 
> >> > s of general applicability, so I decided to submit the spec to 
> >> > the JOSE working group.  Thanks to James Manger, John Bradley, 
> >> > and Nat Sakimura for the discussions that led up to this spec.
> >> >
> >> >
> >> >
> >> > https://self-issued.info/docs/draft-jones-jose-jwk-thumbprint-00.
> >> > ht
> >> > ml
> >> >
> >> >
> >> >
> >> >                                                             -- 
> >> > Mike
> >> >
> >> >
> >> >
> >> > P.S.  I also posted this notice at

---

From: John Bradley <[email-masked]>
Date: Mon, 14 Apr 2014 19:03:56 -0300

The problem with doing that is that we then have to have structured kid values or another field to say what method was used to compute the kid.

It is simpler to have a separate claim for a well known thumbprint method.   Other claims for other methods could also be defined.

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.

John B.

On Apr 14, 2014, at 6:37 PM, Jim Schaad <[email-masked]> wrote:

> And to me all this sounds like is that there should be a document which says – this is one way to compute a kid value and then let the application say that this will be the way to do it.  Much like how SPKIs are done for X.509 certificates today.
>  
> Jim
>  
>

---

From: "Manger, James" <[email-masked]>
Date: Tue, 15 Apr 2014 15:35:19 +1000

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

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

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.

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.

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.

> 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"?

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

--
James Manger