On Mon, Apr 8, 2013 at 2:52 AM, helpcrypto helpcrypto <helpcry...@gmail.com> wrote: > > While awaiting to http://www.w3.org/TR/WebCryptoAPI/ Java applets for > client signning, signText and <keygen> are needed. > Also things like Handling smart card events or Loading PKCS #11 > modules is being use by many. > So, you _CANT_ remove > https://developer.mozilla.org/en-US/docs/JavaScript_crypto > > If you want/need more detailed discussions, dont hesitate to ask me.
Hi, Yes, I am interested in hearing why you think we cannot remove these functions. I have met with several members of our DOM and web API teams and we've tentatively agreed that we should remove these functions if at all possible--as soon as 2014Q1. That is, we're hoping to remove all of window.crypto.* except getRandomValues, and all of window.pkcs11.* (smart card events). Mozilla's policy about web API removal is to make an announcement that gives websites at least three releases (18 weeks) of notice. This is not that announcement, but I hope to make such an announcement soon. We don't expect other browsers to ever implement this API, so they are effectively a Mozilla-proprietary API. We are trying to avoid creating our own proprietary APIs in the hopes that other browsers will do the same. You can see some of the guidelines we are working on here: https://wiki.mozilla.org/User:Overholt/APIExposurePolicy If we were to try to standardize this functionality, we would almost definitely have to make substantial changes to the APIs as part of the standardization process. For example, the current APIs assume some equivalence relation between RSA key sizes and ECC curve strength. I think smart card events are especially problematic because they seem to add additional privacy/fingerprinting exposure. generateCRMFRequest seems like it can be replaced by some JavaScript + <keygen> + server-side processing, and we suspect that sites that are using GenerateCRMFRequest in Firefox must already do this for other browsers. I understand that <keygen> is not the greatest thing in the world either, but it has the benefit of at least having a specification for browsers to follow. signText seems to be the most difficult thing to remove because there is no way to emulate its smart card access capabilities with standard web APIs. At the same time, the way signText works is problematic enough that I suspect no other browser will ever implement it. We are working on creating a multi-process sandbox for web content, similar to the sandboxes used in other web browsers. This is one of the few remaining APIs that isn't implemented in a multi-process-friendly manner, and given all the above issues we don't want to spent time converting it to be multi-process-friendly. Instead, I would like to figure out what, if any, alternative to signText we can provide, and also what we need to do to enhance our <kegen> implementation to help websites migrate away from generateCRMFRequest. I am very curious, in particular, what products that use generateCRMFRequest and/or signText do for other browsers, especially Chrome. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
