Hi David, IMO the Web Crypto API is on the right level.
There are tons of people out there that are writing wrappers and that covers the need you mention. What Mozilla really need is a new PKI client, the current is useless, particularly for B2G (since PCs seem to be a lost case due to MSFT): http://webpki.org/papers/PKI/certenroll-features.pdf Mozilla's <keygen> meets a *single* of these possible requirements which forces most serious parties to "roll-their-own". Since you asked about Web Crypto, my question remains: how does Web Crypto WG intend to deal with keys in NSS, CryptoAPI, "KeyChain"? br ar On 2013-02-13 21:55, David Dahl wrote: > Hello dev-tech-crypto: > > I want to solicit more opinions, criticism and feedback around the W3C Web > Crypto API. Based on this feedback, I want to try and gauge what kind of > implementation resources we might put on this API. > > * Charter: http://www.w3.org/2011/11/webcryptography-charter.html > * (lower-level API) > https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html > * (higher-level API) > https://dvcs.w3.org/hg/webcrypto-highlevel/raw-file/tip/Overview.html > * Use Cases: > https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html > > The Working Group charter specifically states that the WG is working on a > high-level API that web developers will be able to approach somewhat easily. > The low-level public working draft we have is not that API, rather it is a > quite a bit lower-level than what I imagined when pushing DOMCrypt ( > https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) - which > was the initial strawman for the W3C Web Crypto WG. > > While this API is designed to be rather open-ended and allow > inter-interoperability with existing systems and protocols, I fear we are > handing web developers a 'footgun'. Naturally, a JS library will evolve that > wraps this API, making it much easier to use - won't having a simpler API > built into the browser be safer? (The jury seems split here) > > DOMCrypt was originally designed to try and 'simplify' a crypto API for the > DOM, allowing relative novices to get useful (non-backward-compatible) > functionality. I think having a low-level API is going to be great, but, > based on a lot of the feedback on our FPWD, I wanted to try and draft a > high-level API that did only encryptAndSign/decryptAndVerify (public key) and > seal/open (symmetric key). > > The main issue is: What does Mozilla actually need here? What is Mozilla's > official policy or thinking on a crypto API for the DOM? > > The working group is also very interested to know what a potential timeline > is for Mozilla to implement. > > Regards, > > David > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
