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
