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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
