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]] 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]] 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]] 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
