That was precisely my thought. On Thu, 2016-08-04 at 11:10 +0100, Sergey Beryozkin wrote: > Hi > > Would it make sense to introduce a header similar to "x5t" which > represents a X509 certificate thumbprint ? Example, "jwkt". > So instead of 'overloading' a kid property one would just set 'jwkt' > > Cheers, Sergey > > > On 22/07/16 06:46, Brian Campbell wrote: > > > > There was more or less such a thing in an earlier draft > > (https://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#sect > > ion-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 > > <[email protected] <mailto:[email protected]>> 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 <npmccal > > lum@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] <mailto:[email protected]> > > > > > https://www.ietf.org/mailman/listinfo/jose > > > > > > > > > > _______________________________________________ > > > jose mailing list > > > [email protected] <mailto:[email protected]> > > > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > > jose mailing list > > [email protected] <mailto:[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
