Agree that agreeing on a method to calculate the hash is still useful. As far as the discussion around the serialization of the input to the hash function goes, I get the sense that folks have been taking past each other a bit on this thread.
Yes, any hash input computation with the right properties will work. Yes, the current input computation is more complex than it needs to be for the existing JWK types (EC & RSA). And the pseudo-JSON used to produce a canonical hash input is somewhat disconcerting. But it's also trying to accommodate future JWK key types without placing too many restrictions on what they can look like while still being thumbprintable via this mechanism. Does it get the balance right? Hard to say without knowing the future (maybe we can organize a BoF for seeing the future in Dallas?). IMHO, the fears of interoperability problems are a bit overblown. But I'm also skeptical that future JWK key types will have members whose values are themselves JSON objects, and a lot of the complexity seems to stem from supporting that case. So what's my take on the draft? Meh. It's okay. It's fine. As an aside, if we do decided to drop the "jkt" Member Definitions, there probably needs to be some discussion about where/how the hash algorithm is specified along with some semblance of support for future algorithm agility. On Sun, Jan 25, 2015 at 10:41 AM, John Bradley <[email protected]> wrote: > Yes in the POP specs sending a Thumbprint of the public key might save > space vs including the entire public key in the token, especially for RSA > keys. > That would mostly apply to channel binding & token binding where the > public key is delivered outside the token. > > Leaving it up to those specs to define the element is OK with me. > > Agreeing on the method to calculate the hash is still useful. > > John B. > > > On Jan 25, 2015, at 1:50 PM, Brian Campbell <[email protected]> > wrote: > > I'd be okay with dropping the "jkt" member definitions. It's not clear > that they really add anything in the context of this draft. > > A "jkt" claim for JWT might be useful as a common way for an issuer to say > that a subject/presenter can/should/must present some proof-of-possession > of the key identified by the thumbprint claim. Is something like that in > the OAuth POP work already? It's been a while since I've looked at that > stuff. But I digress as that's all for a different WG. > > > > On Sat, Jan 24, 2015 at 5:20 PM, John Bradley <[email protected]> wrote: > >> I am ok with that. If we need to differentiate between a arbitrary key >> identifier and a key identifier that is cryptographically related to the >> public key, we could register the additional element later. >> >> John B. >> >> Sent from my iPhone >> >> On Jan 24, 2015, at 5:50 PM, Mike Jones <[email protected]> >> wrote: >> >> While this may surprise you, that wouldn’t personally bother me. The use >> cases I know of would either use it as a Key ID or Subject claim value. >> The “jkt” definition was there just to be parallel with “x5t”. What the >> draft is really about is the computation definition. >> >> >> >> What do others in the working group think about Jim’s suggestion? >> >> >> >> -- Mike >> >> >> >> *From:* Jim Schaad [mailto:[email protected] >> <[email protected]>] >> *Sent:* Saturday, January 24, 2015 12:08 PM >> *To:* Mike Jones; [email protected] >> *Subject:* RE: [jose] Working Group last call on >> draft-ietf-jose-jwk-thumbprint >> >> >> >> Implied in my comment is that the parameter jkt would go away. >> >> >> >> *From:* Mike Jones [mailto:[email protected] >> <[email protected]>] >> *Sent:* Saturday, January 24, 2015 11:39 AM >> *To:* Jim Schaad; [email protected] >> *Subject:* RE: [jose] Working Group last call on >> draft-ietf-jose-jwk-thumbprint >> >> >> >> I agree with you that we should probably add text saying that the >> thumbprint value could be used as a Key ID (Hideki Nara made this point >> yesterday as well), and that it is an application decision whether to carry >> the value in a “jkt”, “kid”, or another field. (In one case, OpenID >> Connect uses it as the “sub” (subject) claim of a JWT, for instance.) >> >> >> >> -- Mike >> >> >> >> *From:* jose [mailto:[email protected] <[email protected]>] *On >> Behalf Of *Jim Schaad >> *Sent:* Saturday, January 24, 2015 10:39 AM >> *To:* [email protected] >> *Subject:* Re: [jose] Working Group last call on >> draft-ietf-jose-jwk-thumbprint >> >> >> >> I am wondering why this needs to be tagged as a thumbprint. Is there a >> reason why this draft should not be presented as – here is a way to compute >> a kid value for a key that will produce a unique value. This would be >> similar to how the computations are presented in PKIX for the subject key >> identifier extension. >> >> >> >> Jim >> >> >> >> _______________________________________________ >> 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
