Stephen asks why JWK Thumbprint should do something other than hash a SPKI key representation. Here are a few reasons:
1. The whole premise of JOSE was to create easy to use crypto data formats and algorithms that are based on JSON. Saying “SPKI exists – everyone should use it” is like saying “CMS exists – everyone should use it, or perhaps XMLDSIG exists – everyone should use it”. It does not seem consistent or helpful to developers for JOSE to effectively say “You can use JSON-based structures for everything except key hashes and for those, you have to use a binary structure (based on ASN.1).” 2. The point of the draft is to create thumbprints of keys that are already represented in JWK format. Requiring a format conversion to ASN.1, which most developers consider to be unapproachable, will result both in more code and less adoption. (If the keys are already in X.509 certs, by all means, hash the SPKI value because it’s easy. JWK Thumbprint is similarly easy for JWK keys.) Stephen also states “The benefit of doing the same as others is that one can use the same value to refer to the same key in different contexts”. That sounds great on the face of it, but it is not clear that there’s much/any benefit to this in practice. A key is typically deployed for a particular application context or among applications running over a TLS connection. Key reuse across different applications contexts is arguably a security concern and not something likely to occur much in practice. Each application defines what key format it uses (X.509/SPKI, XML, JWK, etc.) and how to create key identifiers for those keys. Letting the application choose a JSON-based way to create key identifiers is both logical and good for adoption of usable crypto. I also took a look at some adoption data as background information. - Browser support for WebCrypto is still iffy. See http://caniuse.com/#feat=cryptography. - Notably, all the Android Browsers before Android L (5.0) do not support WebCrypto, and there are tons of them out there. They will be there for years. - There are many enterprise deployments of IE below 10, which are not going to be upgraded anytime soon. - PHP started supporting SPKI in ver. 5.6, which was released Aug. 28, 2014. Its deployment is very small as you can expect - 0.7%. Server platforms do not do major version upgrades frequently. See http://w3techs.com/technologies/details/pl-php/5/all. - Python seems to have been supporting SPKI for sometime as a NetscapeSPKI object. - So does Ruby. - I am not sure if the same is true for Perl. A cursory search didn’t turn up any useful data. In closing, the point of JOSE (and the point of the JWK Thumbprint spec) is to enable widespread adoption of usable crypto with the development tools people actually have NOW. That seems to be reason enough to have this draft progress now towards RFC status. Best, Nat 2015-03-02 15:50 GMT+09:00 Stephen Farrell <[email protected]>: > > > On 02/03/15 05:49, Jim Schaad wrote: > > The previous discussion on the serialization did not reach a consensus > > either to keep or change serialization string method. Given this the > > decision to keep the previous one is a conservative decision. If people > > want to re-litigate this issue and try to come to a consensus this is the > > time to do it. > > Other hashed-public-key things all use SPKI as the input. Doing > something different is IMO a bad plan for zero benefit. The benefit > of doing the same as others is that one can use the same value to > refer to the same key in different contexts. With the current > approach, one cannot. > > S. > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
