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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
