Subject: [jose] JWK Thumbprint in JWS/JWE Header

From: Nathaniel McCallum <[email-masked]>
Date: Tue, 19 Jul 2016 10:48:56 -0400

The JWS and JWE specs defined the "kid" header value that can be used
to identify the key used for signing or encryption. Subsequently, the
JWK thumbprint method was defined.

Has anyone put any thought into registering a header value for JWS and
JWE headers that indicates the thumbprint of the key used for signing
or encryption? This would be very helpful for key indexes especially
when using unprotected headers since the value of "kid" might be
modified.

---

From: Justin Richer <[email-masked]>
Date: Tue, 19 Jul 2016 11:24:17 -0400

This was discussed on the list a while ago, and the thought was that you could easily use the JWK thumbprint *as* the “kid” value instead of defining a new field for this use case. The header values are protected by the signature in the normal (compact) JWS/JWE formats, and ought to be protected in the JSON representations too for exactly the reasons you’re talking about. 

 — Justin

> On Jul 19, 2016, at 10:48 AM, Nathaniel McCallum <[email-masked]> wrote:
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Nathaniel McCallum <[email-masked]>
Date: Tue, 19 Jul 2016 12:09:24 -0400

Has there been any talk about using a prefix to specify the hash algo?

On Tue, 2016-07-19 at 11:24 -0400, Justin Richer wrote:
> This was discussed on the list a while ago, and the thought was that
> you could easily use the JWK thumbprint *as* the “kid” value instead
> of defining a new field for this use case. The header values are
> protected by the signature in the normal (compact) JWS/JWE formats,
> and ought to be protected in the JSON representations too for exactly
> the reasons you’re talking about. 
> 
>  — Justin
> 
> >

---

From: Nathaniel McCallum <[email-masked]>
Date: Thu, 21 Jul 2016 13:00:46 -0400

Specifically, I'm thinking of the problem of validating a thumbprint.

The RFC does not define a hash function. Nor does the output format
contain a hash function name.

So if I hand JWK to an entity, how does that entity validate that the
thumbprint in the kid is actually a valid thumbprint and wasn't
modified? I supose the entity could try all its supported hash
functions; but that seems a little heavy handed.

The existing kid could be used with contents like: <hash>.<thumbprint>

Alternatively, RFC 7517 uses the x5t and x5t#S256 variants. This is
precisely why I wondered about a thumbprint specific attribute.
Something like thp and thp#S256 would make this explicit.

Thoughts?

On Tue, 2016-07-19 at 12:09 -0400, Nathaniel McCallum wrote:
> > > On Jul 19, 2016, at 10:48 AM, Nathaniel McCallum <npmccallum@redh
> > > at
> > > .com> wrote:
> > > 
> > > Has anyone put any thought into registering a header value for
> > > JWS
> > > and

---

From: Brian Campbell <[email-masked]>
Date: Fri, 22 Jul 2016 07:46:44 +0200

There was more or less such a thing in an earlier draft (
https://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#section-4) of
what would become RFC 7638: There was some disagreement about it that I
don't quite remember the details of and it was pulled out. I think what
Justin said did come up as justification for not needing something more
explicit. If a thumbprint is used as a kid, then the parties involved need
to know that and also know the hash alg. I realize that doesn't really
answer the question but is a little background/context.