The only use I had for something like this with symmetric keys was in PKCE/SPOP https://tools.ietf.org/html/draft-ietf-oauth-spop-06
However trying to do it with a JWK added more complexity that it is worth. We settled on hashing the symmetric key directly and getting people to use 256bit keys to eliminate the need to salt. I can live with limiting this to public keys. John B. > On Jan 23, 2015, at 3: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. > > 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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
