Hi
On 09/08/16 13:39, Nathaniel McCallum wrote:
That was precisely my thought.
Oh, yes, I see it was suggested in your original message below.
Sorry, glad you suggested it earlier first.
Thanks, Sergey
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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
