My understanding is that this draft wants to hash the equivalent of a SPKI value rather than a certificate. Perhaps that needs to be stated more explicitly?
Also there are some cases, mentioned briefly earlier in this thread about JWT and jkt style claim, where both the sender and the reviver will compute the hash values independently. That may well be out of scope for this draft but it will very likely make use of this draft. On Mon, Jan 26, 2015 at 12:55 PM, Jim Schaad <[email protected]> wrote: > > > > > *From:* jose [mailto:[email protected]] *On Behalf Of *Brian Campbell > *Sent:* Monday, January 26, 2015 7:31 AM > *To:* John Bradley > *Cc:* Michael Jones; Jim Schaad; [email protected] > *Subject:* Re: [jose] Working Group last call on > draft-ietf-jose-jwk-thumbprint > > > > 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. > > [JLS] I have to agree with this as long as the draft is going to say that > we want to hash the equivalent of a SPKI value rather than a certificate. > It is not like we are going to suddenly decide that an EC point should be > represented as an array of two values. If we want to hash the equivalent of > a certificate (personal position) then we have things like key_ops which > are JSON objects and need to be dealt with. Some arrays are ordered and > some are not – which is this? > > 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. > > [JLS] If we are just looking at a method of computing kid values, I don’t > think this needs to be done. The only reason that it would be required to > be able to determine the hash function is if one is planning to have both > the sender and the recipient compute the values independently. That is > not a requirement for kid. This is one of the problems that I have with > having a jkt member that sits in a jwk object, having a pointer to myself > that is computable by the recipient seems odd. I have normally used > thumbprints in the order of – do I already have this key in my database of > keys. This means pointing from a message makes sense but I compute the > value when I put it into my database for lookup purposes. Otherwise it is > just a random key identifier and it does not matter how it is computed. > > > > > > > > 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
