On 2012-04-19 17:09, David Dahl wrote: > Hello All: > > [I have cross posted this message to dev-platform and dev-tech-crypto, > perhaps we should discuss this on dev-platform as it has a larger subscriber > base?]. > > I am just putting together a draft feature page for an internal API needed by > the eventual DOM bindings for DOMCrypt (see: > https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest and > http://www.w3.org/2012/webcrypto/ ). I would like for this API to not only > support the eventual Web Crypto API, but also to allow extension developers > to have a useful, high-level API to work with. This seems to be quite in > demand based on the number of companies and developers who have contacted me > about hacking on my fork of WeaveCrypto ( in the DOMCrypt Extension > https://addons.mozilla.org/en-US/firefox/addon/domcrypt/ .) > > Mozilla developers will also be able to take advantage of this internal API > to more easily create browser features and/or extensions in the security and > privacy space. I would also like to produce a Jetpack wrapper. > > The existing spec for DOMCrypt will no doubt change very soon as the Web > Crypto Working Group is ramping up and based on discussions with bent and > khuey, we need to move to an event-driven interface. The Internal API > described on this feature page: https://wiki.mozilla.org/DOMCryptInternalAPI > should be able to handle that, however, some wider discussion and feedback > will really be appreciated, especially with all of the changes in line for > our DOM bindings. The initial work for this internal API is in bug 649154. > > Regards, > > David
I have already provided feedback on this in a W3C list, so this a condensed version of on the Mozilla list. As I understand it, this scheme is about public keys bound to a domain which is a bit like cookies on steroids. This shouldn't introduce any new or difficult security concerns. Regarding real-world use-cases, I'm slightly less convinced. In particular encryption has proved to be hard to exploit but OTOH there are [still] folks out there who claim S/MIME is the flagship of PKI so I guess somebody knows what they are asking for.... However, the WG has also taken on "Signing High-value Transactions". I find this use-case poorly researched. There have been no references to existing web signature systems although such have existed since late 90'ties. I suggested early on dropping this topic, as it with a high probability will jeopardize both the time schedule as well as uptake by other browser vendors. In addition, it is claimed from time to time that a future version of DOMCrypt will also support X.509 certificates. If I had developed a car, I would be rather hesitant saying that the next iteration will fly without having a pretty good idea of how. I'm personally continuing on the path created by Netscape eons of time ago, where cryptographic operations in browsers are performed in self-contained applications like HTTPS URL innovation, <keygen>, and signText() because they have proven to work, while (for example) Microsoft's CertEnroll has been a complete failure due to the issues created by exposing APIs to untrusted web-pages. Somewhat surprising the WG excluded smart cards in spite that built-in security hardware will be a standard feature in every high-end mobile device by the time this WG has finished! IMHO, smart cards in browsers is actually quite easy; you just bypass the vendors and define a card/container for the web :-) If you ever had looked into the OpenSC mailing list it is pretty obvious that supporting conventional cards is impossible, at least for enrollment. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
