Hi Nat, Nat Sakimura wrote: > 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.
Sorry, but that's bogus. SPKI is easy to use and simple on pretty much all web development platforms. Claiming that this is ASN.1 and therefore bad is just not a valid argument since there is no requirement for any decoding and there is no complex encoding at all. > 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, Same bogus argument, sorry. Using ASN.1 as a scare tactic is just not credible here, once one looks at the facts. > 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.) Nonsense. SPKI is trivial to generate from any form of public key. > 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. Please demonstrate such a concern. Vague arm-waving isn't useful. Using the same input bits for the same key would help e.g. to ensure weak keys like the old debian ones would be more easily spotted in signature applications, so there are security benefits to consistency here. (That's a modest, benefit for sure though.) > > 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. WebCrypto makes SPKI access the obvious thing to do. Other platforms require a line of code or so to create the SPKI bits as a hash input, and that's true in JS or any other dev environment I've used. > > > - > > 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. And precisely zero of all of the above support the current draft's approach. > > > 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. You have IMO only used bogus ASN.1-is-bad arguments to back up your usability claim. I don't really feel that strongly about the WG doing the wrong thing here (i.e. wrong-thing==current I-D) but we should decide based on valid arguments. S. PS: In case it's not clear - this is all me arguing as an individual and nothing to do with IESG evaluation of the draft when it gets there. > > 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
