On Fri, Jun 27, 2014 at 9:19 AM, David Keeler <dkee...@mozilla.com> wrote:
> On 06/27/2014 07:37 AM, Nathan Kinder wrote: > > On 06/27/2014 12:13 AM, Frederik Braun wrote: > >> To be frank, I have only ever seen the non-standard crypto functions > >> used in attacks, rather than in purposeful use. > > > > That doesn't mean that aren't being purposefully used. The current > > crypto functions are used pretty heavily by Dogtag Certificate System > > [1], and this has been the case for many years. > > > > I believe that one of the big things lacking in WebCrypto is a suitable > > replcement for generateCRMFRequest(), which allows for key escrow. I'm > > not certain if an addon will be able to replace this functionality. > > Looking at the working draft of the spec[0], there are functions to > generate, export, and wrap keys, so it looks like webcrypto can be used > to implement key escrow (unless I'm misunderstanding the term). > Again, though, addons can pretty much do anything, so if webcrypto isn't > up to the task, an addon should be able to fill the gap. > The issue is that the WebCrypto API uses a totally separate keystore from the X.509 client certificate keystore (if it doesn't, it should be), and the stuff that Red Hat does is about client certificates. AFAICT, WebCrypto doesn't get have any mechanism for accessing the client certificate store and it isn't clear if/when that would be added. However, an addon would be able to do these things, because the addon could literally just use the crypto code that you are proposing to remove, without the DOM parts. However, now that Firefox is minimizing the amount of NSS that is exposed from libnss3 and friends on non-Limux platforms, it is probably the case that the addon will need to use platform-specific APIs to access the operating system keystore, at least on non-Linux platforms. However, I think that is a good idea anyway, because Firefox (and Thunderbird) should be using the native OS for client certificates and S/MIME certificates anyway. As far as whether it is OK to remove functionality that some websites are depending on: In this case, I think you can remove functionality that Chrome currently doesn't support (using the same APIs or different APIs) without hesitation. For example, I don't think Chrome can do the key escrow thing so I don't see why Firefox needs to support it either. The advantages of deleting the code outweigh the value that Firefox gains from supporting those things. We had a conversation about this a year ago on this mailing list and AFAICT nobody has made any effort at W3C to standardize anything related to the functionality for which you are proposing removal. I think that is a good indication of how unimportant it is. So, +1 from me. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
