On 2011-06-14 16:48, Jean-Marc Desperrier wrote: > David Dahl wrote: >> From: "L. David Baron"<dba...@dbaron.org> >> On Monday 2011-06-13 15:31 -0700, David Dahl wrote: >>>> In trying to get the word out about a browser crypto API I am >>>> championing (see: >>>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest >>>> ), I wanted to post here for feedback and criticism. >>> >>> Hmm, I may as well respond here, though I'm a little concerned about >>> how many places the feedback on this is going. >>> >> I am trying to communicate this to as many interested parties as >> possible. I also don't want to force anyone to join another list to >> offer feedback. I am not planning to post this to any further mailing >> lists. > > However you did not post this to the obvious choice of > mozilla.dev.tech.crypto. > > I find this API effort very interesting, however I'm left with the > feeling you wish to leave out the use of PKI elements. > A really neutral API would work both with and without PKI.
Given the "open" discussions on key generation / smart card interface requirements on this list in the past, it is probably better to just get something out of the door and see where that leads you. Anyway, a problem with this particular draft is that there are (IMO) too few described use-cases. Client-based encryption of credit card numbers which has been mentioned as a valid DOMCrypt use-case sounds like a cool idea at the 10000m level. When you look closer you will find that it severely disrupts existing business processes. There *may* be other more easily accessible use-cases but the experiences we have to date with *message encryption* (in contrast to transport encryption), are less than satisfying. Sure, security *is* important but not at the expense of convenience! Skype, HTTPS, SSH, and IPSEC already perform encryption for the masses without the users ever needing to know what encryption is. Unfortunately there is another fundamental issue as well... Microsoft's "CertEnroll" demonstrates the drawbacks of performing multi-step cryptographic operations from untrusted browser code into the trusted platform. You typically end-up with a bunch of hard-to-set security/privacy parameters or confuse users with questions they don't understand. This is the sole reason why KeyGen2 runs as an *trusted application* where everything from message order and content to access to critical resources and GUI is handled analogous to how HTTPS is implemented in browsers. Although the interest from the browser-community so far has been zero, I intend making the invocation/extension mechanism of KeyGen2 available for anybody to use. A handful of trusted crypto applications may indeed prove to be more useful than a universal (but de-facto quite crippled) crypto API. -- Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
