On Sat Jan 24 02:12:10 2015 GMT, Mike Jones wrote: > > -----Original Message----- > > From: Stephen Farrell [mailto:[email protected]] > > Sent: Friday, January 23, 2015 3:13 PM > > To: ⌘ Matt Miller; John Bradley; Mike Jones > > Cc: Richard Barnes; Jim Schaad; [email protected] > > Subject: Re: [jose] Working Group last call on > > draft-ietf-jose-jwk-thumbprint > > > > On 23/01/15 21:50, ⌘ Matt Miller wrote: > > > Or maybe we seriously consider SPKI. > > > > Yes. It works. It's used elsewhere so offers better interop. All libraries > > support it so coding up the thumbprint stuff with that is trivial and far > > less > > error prone. > > I believe you that you have SPKI support if you're writing in C/C++, Java, or > C# but not necessarily if you're writing in JavaScript, Ruby, Python, etc.
Sorry I think you're wrong. Afaik all of em and php have this if they have crypto. S > > > It avoids any need for (even more) pointless debate about > > hash-input nitpicking. There's less spec text needed too. All useful > > asymmetric algs will have a well defined SPKI for the next decade because > > those are used in TLS and for the WebPKI which is not going away no matter > > how much you want it to go away. That is a pile of advantages. > > > > And, most important, there is zero advantage in pointlessly inventing a new > > variation. Frankly the supposed advantages offered so far: > > > > - - a line or two less code, (maybe, maybe not, > > unimportant in any case) > > - - "not asn.1" (nonsense, SPKI needs no generic > > asn.1 support, we've known for decades how > > to do without that, and your library constructs > > the octets from the key already) > > - - "it should be json" (more nonsense, it's a hash > > input and never sent or stored, nobody cares what > > format it has) > > > > ...are utterly unconvincing in any rational view. > > If you follow this line of reasoning to its logical conclusion, we would have > insisted on people always using SPKI and/or X.509 key representations, rather > than "pointlessly inventing a new variation" called JWK. And for that > matter, we would have insisted on people using CMS rather than developing JWS > and JWE. ;-) > > I'm not saying that it's not possible to construct SPKI hash inputs from JWKs > in JavaScript, etc., but creating the one specified in the draft seems a lot > more straightforward to me if what you already have is a JWK. > > > PS: As another data point, the W3C sub-resource integrity spec [1] uses ni > > URIs today. I've no idea if that's likely to last into a W3C REC or get > > deployed, > > but seems to me like not-reinventing in this space is one sensible thing > > those > > folks have > > (sensibly:-) done, given the utter lack of benefit from re-inventing. > > > > [1] http://www.w3.org/TR/SRI/ > > P.S. There's nothing stopping someone from writing a very short draft also > registering header parameter names for hashes of SPKI key values. I'm all > for that. Then people can vote with their feet (with their code) on which > they prefer to build and use. > > -- Mike > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
