Re: [jose] Working Group last call on draft-ietf-jose-jwk-thumbprint

On Sat Jan 24 02:12:10 2015 GMT, Mike Jones wrote:
> > -----Original Message-----
> > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> > Sent: Friday, January 23, 2015 3:13 PM
> > To: ⌘ Matt Miller; John Bradley; Mike Jones
> > Cc: Richard Barnes; Jim Schaad; jose@ietf.org
> > 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>