Then this does beg the question, why isn't it a printf statement like this instead:
if kty == "RSA" then printf(e, ".", kty, ".", n) else if kty == "EC" then printf(crv, ".", kty, ".", x, ".", y) Pretending it is a JSON structure doesn't help me if I can't input a JSON object from my source language in a meaningful fashion. -- Justin On Jan 23, 2015, at 2:02 PM, Mike Jones <[email protected]<mailto:[email protected]>> wrote: In practice, you wouldn’t ever implement the sort. You’d have printf statements for the key types you support (and we’ve only defined three of them to date – only two if you only use public keys). So in pseudo-code, the hash input generator I would write would look something like this: if kty == “RSA” then printf(‘{“e”:”’, e, ‘”,”kty”:”’, kty, ‘”,”n”:”’, n, ‘”}’) else if kty == “EC” then printf(‘{“crv”:”’, crv, ‘”,”kty”:”’, kty, ‘”,”x”:”’, x, ‘”,”y”:”’, y, ‘”}’) else FAIL No sorting code involved! From: Richard Barnes [mailto:[email protected]] Sent: Friday, January 23, 2015 10:54 AM To: Mike Jones Cc: John Bradley; Matt Miller; Jim Schaad; [email protected]<mailto:[email protected]> Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint On Fri, Jan 23, 2015 at 1:39 PM, Mike Jones <[email protected]<mailto:[email protected]>> wrote: I was about to write a similar message to John's. James Manger also pointed out the need to have different hash inputs for different kinds of keys, so as to avoid the possibility of collisions. The simple suggestion earlier in the thread of using an array of values for the hash input doesn't have this property. If there were two kinds of keys with the same number of values in the input, for instance three values such as [A, B, C], then without also having the member tags "kty", etc. in the hash input, collisions are possible. That's why James suggested that the natural and safe hash input for a JWK is a sorted JWK itself. We went with that. The problem is that there's no good way to create a "sorted JWK". (BTW, you also mean "whitespace-free".) Thankfully, the whitespace problem is easy to deal with here. Since the included attributes do not allow any internal whitespace, you can just delete all whitespace. But sorting is a big deal. Like I said, it basically requires you to hand-serialize the JSON. At which point, you might as well use ASN.1 :) ISTM that (1) including "kty" and (2) using a delimiter that's not in the allowed character set would together address the collision issues. So we could get away with something like "kty-value|n-value|e-value". Miller's proposal to use a JSON array would also work for me, although it would require removing white space in case the serializer added any. Anything that doesn't require custom serialization code :) I agree that encodings using ASN.1 sort of defeat the point. Others could define how to do that and add them to the appropriate registries if they want, but using JSON solutions is the point of the working group and this draft. As for symmetric keys, I don't think we actually have a use case for them at present. I'd be fine with the working group deciding to drop them or to add security considerations on the necessity for there to be sufficient key entropy if a thumbprint is to be exposed to a party not holding the key. Or the security considerations could say that the thumbprint MUST only be exposed to parties already in possession of the key. While I understand going the salt route, I'm only comfortable with us doing that now if someone has a real use case for it. Since I think the chairs want to have this draft complete quickly, I'd rather drop symmetric keys than figure out the salt mechanisms on the fly. But others are free to propose otherwise, obviously. At a meta-point responding to Jim's message, I think this morning's discussions exactly demonstrate the value of the draft being in the working group. There's a lot of good discussion going on about the choices made, tradeoffs, and alternatives that wouldn't necessarily happen if this weren't a working group draft. Thanks all, -- Mike -----Original Message----- From: jose [mailto:[email protected]<mailto:[email protected]>] On Behalf Of John Bradley Sent: Friday, January 23, 2015 10:18 AM To: Matt Miller Cc: Richard Barnes; Jim Schaad; [email protected]<mailto:[email protected]> Subject: Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint Mat in the first version that we did, we didn't have delimiters. I think it was James Manger that pointed out that without delimiters there were some potential attacks. Depending on the order of the parameters the issues are different. I think the specific issue was concatenating e directly to n. That lead us to create the current doc. John B. > On Jan 23, 2015, at 2:28 PM, ⌘ Matt Miller > <[email protected]<mailto:[email protected]>> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 1/23/15 7:54 AM, Richard Barnes wrote: >> I would summarize my reaction to this document as "I can live with >> it, but it makes me really sad that we didn't do the stupid simple >> obvious thing." >> >> The computation of the hash input is technically workable, but >> unnecessarily complex. Rather than building a simple string based on >> the components (say, ), it basically requires the implementor to make >> a custom JSON serializer to ensure that the fields are serialized in >> the right order. >> >> Using Javascript as an example, instead of just doing a simple string >> construction: >> >> tp_input = [jwk.e, jwk.kty, jwk.n].join("|") >> >> ... instead, I construct and fill in a template: >> >> tp_input = '{"e":"JWK_E","kty":"JWK_KTY","n":"JWK_N"}' >> .replace("JWK_E", jwk.e) .replace("JWK_KTY", jwk.kty) >> .replace("JWK_N", jwk.n) >> >> Requiring a lot of manual coding like this seems to invite interop >> issues. >> >> The remainder of the text looks fine to me, though. >> > > I agree with Richard that the hash input looks needlessly complex. > Picking a delimiter isn't necessary if it instead takes advantage of > existing JSON implementations by simply serializing an array of the > required values, still ordered lexicographically according to their > associated member names. > > In some real code, that's: > > * JavaScript: tp_input = JSON.stringify([jwk.e, jwk.kty, jwk.n]); > * Ruby: tp_input = JSON.generate [ jwk["e"], jwk["kty"], jwk["n"] ] > * Python: tp_input = json.dumps([jwk['e'], jwk['kty'], jwk['n']) > > This could very well get rid of most of section 5. It might also get > rid of some of text in Section 7 regarding weird member names if we're > careful. > > > - -- > - - m&m > > Matt Miller < [email protected]<mailto:[email protected]> > > Cisco Systems, Inc. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org<https://gpgtools.org/> > > iQEcBAEBCgAGBQJUwoTDAAoJEDWi+S0W7cO16gYH+wbQ+RhWRoPOXDEXa0ieyqzD > GxS+6Jj77QQjknkm9bfw+6mTzP0+CFshy4OJP/qNQScRLSTvDS20sQUPPb4/NAbq > CV/xV9Td/OrT/73iwR17PHoovLkwHOhbgxX93U4XA6JXVXSlslM0hUKBsDfmqM4j > jBI0yRvowAweDhmQ5rqdHhH4WBQQamR2XT8y61H9ERHAvlru3v5C9n3Qwa9Y8/ju > 1SjzQc1t1UIE3vOmhkxZWlkDfnWI6grOoGDt/JIy7JIK/0WJ/g8mjbqUTh61xU3V > a6SAjw0fjvhfJQ6FJfmmteOYVCOeUO0fCNTCjnkDBMtz9Zho+H7WUfXBvE5QrrY= > =lZoe > -----END PGP SIGNATURE----- > > _______________________________________________ > 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
