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

[Nathaniel McCallum <[e-mail]>]

The problem with the "parties involved need to know ... the hash alg"
is that it makes transitions to new hashes difficult. Something
explicit would be helpful. And we already have a mechanism for this
(x5t).

On Fri, 2016-07-22 at 07:46 +0200, Brian Campbell wrote:
> There was more or less such a thing in an earlier draft (https://tool
> s.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. 
> 
> 
> 
> On Thu, Jul 21, 2016 at 7:00 PM, Nathaniel McCallum <npmccallum@redha
> t.com> wrote:
> > 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:
> > > 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
> > > >
> > > > >
> > > > >
> > > > > On Jul 19, 2016, at 10:48 AM, Nathaniel McCallum <npmccallum@
> > redh
> > > > > at
> > > > > .com> wrote:
> > > > >
> > > > > 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.
> > > > >
> > > > > _______________________________________________
> > > > > jose mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/jose
> > > >
> > >
> > > _______________________________________________
> > > jose mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/jose
> > 
> > _______________________________________________
> > jose mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jose
> > 
>