On Fri, Jan 23, 2015 at 2:02 PM, Mike Jones <[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!
>
You may notice that I put something similar in my first message on this
thread :)
My point is that this style of code is brittle and deals poorly with things
like escaping.
I can see your point w.r.t. separators. That seems to indicate that Matt's
suggestion of a JSON array is the right answer:
tp_input = JSON.stringify([jwk.e, jwk.kty, jwk.n]).replace(/\s/g, "")
That way the order is preserved, but the JSON serializer handles all the
string serialization.
--Richard
>
>
> *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]
>
> *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]>
> 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]] On Behalf Of John Bradley
> Sent: Friday, January 23, 2015 10:18 AM
> To: Matt Miller
> Cc: Richard Barnes; Jim Schaad; [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]> 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] >
> > Cisco Systems, Inc.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> > Comment: GPGTools - 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]
> > https://www.ietf.org/mailman/listinfo/jose
>
>
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
