Closed Bug 1083118 Opened 9 years ago Closed 9 years ago

window.crypto.signText replacement

Categories

(Core :: DOM: Security, defect)

Product:
Core
Component:
DOM: Security
Version:
33 Branch
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox33 - wontfix
firefox34 + verified
firefox35 + wontfix
firefox36 + wontfix
relnote-firefox --- 34+

People

(Reporter: lobach_pavel, Assigned: keeler)

References

(
URL
)

Details

(Keywords: dev-doc-needed, site-compat, Whiteboard: [use the addon in the link in the URL field])

Attachments

(2 files, 1 obsolete file)

set dom.unsafe_legacy_crypto.enabled to true by default (for beta)
2.72 KB, patch
bzbarsky
: review+
lmandel
: approval-mozilla-beta+
Details | Diff | Splinter Review
backout v2 (no string changes)
176.33 KB, patch
bzbarsky
: review+
lmandel
: approval-mozilla-beta+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36

Steps to reproduce:

After updating to Fx 33, window.crypto.signText function doesn't working due to removing window.crypto proprietary functions


Actual results:

Now, there is not any native methods for signing data in Firefox (using SmartCards and Personal certificates in browser key storage). 
Page at https://wiki.mozilla.org/SecurityEngineering/Removing_Proprietary_window.crypto_Functions proposes 
"webcrypto and/or addon" for replacing  window.crypto.signText, but webcrypto doesn't work with keys in X509 certificates or smartcards.
Exensions for Firefox 33 or later can't be developed due to removing nsICMSMessage* interfaces, so none of this proposes can't be realized.


Expected results:

I think this function should be returned in the next release, until functionality similar to window.crypto.signText will be avaliable in webcrypto. We are using this function in our corporate system. This is only solution for cross-platform data signing. Plugins are also proposed for removing from Fx, so there is not any usable aletrnatives...
Severity: normal → major
Component: Untriaged → Security
this is related to
https://bugzilla.mozilla.org/show_bug.cgi?id=1036546

the workaround is to enable the preference:
dom.unsafe_legacy_crypto.enabled=true
and restart the browser
> the workaround is to enable the preference:
> dom.unsafe_legacy_crypto.enabled=true
> and restart the browser

Yes it's working for Fx 33, thanks
But this functions will be entirly removed in the next release (2014-11-25 for Fx 34) and there is still no appropriate replacement
Component: Security → DOM: Security
OS: Windows 7 → All
Product: Firefox → Core
Hardware: x86 → All
Just a note to confirm that the removal of crypto.signText without the provision of a replacement just DoSed a claims management business. The removal is a serious bug - there needs to be a compelling and standards compliant replacement that exists for real before any attempt is made to remove this functionality, and such a replacement does not exist at this time.
dkeeler, can you comment as to the plans here?
Blocks: 1036546
Flags: needinfo?(dkeeler)
Keywords: site-compat
I'm also getting inbound communications about this; it would be good to have a clear statement on what we are proposing to existing users of this API.

Gerv
Obviously I can't speak for everyone at Mozilla, but as far as I know, we have no plans to directly replace window.crypto.signText. Please see the earlier announcement regarding our reasoning: https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/hR_bjx9OVJA
For those who need time developing a replacement (e.g. some combination of an addon and webcrypto or even a separate native application), I suggest you use ESR31 in the meantime.
Flags: needinfo?(dkeeler)
All arguments in flavor of removal of non-standard window.crypto functionality in this thread is that generateCRMFRequest had bugs in the past and is not available in Chrome. And No one had any objection for removing generateCRMFRequest, that can be replaced by <keygen> tag, or smart card events, that almost no one use. But there is no stated problems with crypto.signText, it was removed just because it is not part of web standards and is not available in Google Chrome.

Gecko currently has many non-standard JavaScript methods of standard objects or proprietary extensions of standard methods that will not be removed in foreseeable future if ever because they are used in real web sites just like crypto.signText.

For example quote(), trimLeft() and trimRight() methods of String are non-standard, flags argument of replace() is non-standard, and I think any web developer can add examples to this list. Some of these methods are not available in Chrome too, and form most is trivial to be replaced with just few lines of JavaScript.
(In reply to David Keeler (:keeler) [use needinfo?] from comment #6)
> For those who need time developing a replacement (e.g. some combination of
> an addon and webcrypto or even a separate native application), I suggest you
> use ESR31 in the meantime.

We can't develop a replacement using "some combination of an addon and webcrypto", because:
- webcrypto doesn't work with keys in X509 certificates or smartcards.
- Exensions for Firefox 33 or later can't be developed due to removing nsICMSMessage* interfaces
- plugins are candidates for removing from future releases of Fx
(In reply to Pavel Lobach from comment #8)
> - Exensions for Firefox 33 or later can't be developed due to removing
> nsICMSMessage* interfaces

This doesn't really make sense. signText doesn't use those interfaces, and even if it did, an add-on could bundle them.
(In reply to David Keeler (:keeler) [use needinfo?] from comment #6)
> Obviously I can't speak for everyone at Mozilla, but as far as I know, we
> have no plans to directly replace window.crypto.signText. Please see the
> earlier announcement regarding our reasoning:
> https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/hR_bjx9OVJA
> For those who need time developing a replacement (e.g. some combination of
> an addon and webcrypto or even a separate native application), I suggest you
> use ESR31 in the meantime.

Keeler:

It took lots of years to have crypto.signText working (please, see https://bugzilla.mozilla.org/show_bug.cgi?id=29152)

Now, you are trying to remove crypto.signText  :'(

Please, keep in mind that crypto.signText is still being used to sign texts in the Spanish Public Administration. crypto.signText is being used in Firefox and CAPICOM is being used in Ms Internet Explorer (Chrome is not used because crypto.signText is missing in Cjrome).

If you remove crypto.signText, people will be forced to use Ms Internet Explorer or other java-applet-based solutions.

We really need crypto.signText.

Please please please do not remove crypto.signText. Please please please, bring crypto.signText back.

Thank you very much.

Jose
> Please, keep in mind that crypto.signText is still being used to sign texts
> in the Spanish Public Administration.

As does the Belgian Supreme Administrative Court. Just so you know. 

No alternative to java-hell now I suppose... Reminds me of how Microsoft cut support for Capicom, leaving no alternative either.

Pj.
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 1030963
(In reply to David Keeler (:keeler) [use needinfo?] from comment #6)
> Obviously I can't speak for everyone at Mozilla, but as far as I know, we
> have no plans to directly replace window.crypto.signText. Please see the
> earlier announcement regarding our reasoning:
> https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/hR_bjx9OVJA
> For those who need time developing a replacement (e.g. some combination of
> an addon and webcrypto or even a separate native application), I suggest you
> use ESR31 in the meantime.

Let's summarize things here based on comments and provided links: 
1) You are removing a functionality which banks and numerous government agencies across Europe rely on to provide respectively online banking services and public administration services to their citizens. 
2) You are in the process of implementing some spec which is still a draft and, according to some comments here, even when implemented will not be able to support keys/certificates stored on smart cards. 
3) You are giving users of the API a "heads up" to develop a replacement before completely removing the code in question in the next release which is a less than a month away (according to comment 2).

Do you realize how much time is needed to get these mastodons - banks and especially government agencies, to get moving? As we speak, banks are already suggesting on their sites to downgrade to firefox 32 and disable updates. How is that more secure in the long run?
[Tracking Requested - why for this release]: Removal of crypto.signText is breaking things.
tracking-firefox34: --- → ?
To keep everyone in the loop: We had a meeting to decide how to handle this situation. To the best of my understanding, this is what was decided:

- The patch removing this functionality will be reverted in 34 (currently beta)
- The pref that disabled this functionality by default in 33 will be flipped in 34, thus re-enabling it by default
- An addon will be developed by Mozilla that can either be used directly or as the basis for site-specific addons that will essentially implement the necessary functionality in a safer way
- When that addon is ready (target is 35, currently aurora), the native implementation will again be removed
Thank you for summarizing David. I'd like to hear from the people impacted whether this plan will work and if there are any additional constraints of which we should be aware.
Is it necessary to revert the entire change, or could you just add window.crypto.signText back? It seems like signText is the only thing that people are really concerned about, AFAICT.
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #17)
> Is it necessary to revert the entire change, or could you just add
> window.crypto.signText back? It seems like signText is the only thing that
> people are really concerned about, AFAICT.

I would prefer to just revert the whole thing, lest we get other bugs like this.  It's all going away in 35 anyway.
(In reply to David Keeler (:keeler) [use needinfo?] from comment #15)
> .... skip
> - An addon will be developed by Mozilla that can either be used directly or
> as the basis for site-specific addons that will essentially implement the
> necessary functionality in a safer way
> - When that addon is ready (target is 35, currently aurora), the native
> implementation will again be removed

Thank you, David. It is interesting to track the work on this addon for me. I can help in developing (test, review, bug fixing, etc...)
Hi David,

Thanks very much for listening to the feedback on this. I have one query:

(In reply to David Keeler (:keeler) [use needinfo?] from comment #15)
> - When that addon is ready (target is 35, currently aurora), the native
> implementation will again be removed

It would be unfortunate if we were to put the addon at version 1.0 ("ready for deployment") at exactly the same time as we released the version of Firefox which switched off the native functionality. People using window.crypto.signText need a little time to do compatibility testing with the new implementation, and even if they don't need to update their entire sites, they still need to add a check for the presence of window.crypto.signText and direct people to install the addon if it's not present.

So I hope that we will allow some time between announcing that the addon is ready for use, and shipping a release version of Firefox which removes the native functionality.

It would also be good to try and make some more noise about this so web developers know it's coming. Can we write up a wiki page with this plan and details of what sites will have to do that people can be referred to? Can we do a Hacks blog post? Can use of window.crypto.signText in 33 or 34 write a warning to the console? 

Gerv
Updated the site compat docs.
https://developer.mozilla.org/en-US/Firefox/Releases/33/Site_Compatibility
https://developer.mozilla.org/en-US/Firefox/Releases/34/Site_Compatibility

[Tracking Requested - why for this release]: Since this is a major site compatibility issue in Firefox 33, can we flip the pref to re-enable the API in 33.1, without waiting for 34?
tracking-firefox33: --- → ?
Keywords: dev-doc-needed → dev-doc-complete
See Also: → 1094825
(In reply to Gervase Markham [:gerv] from comment #20)
> Can use of window.crypto.signText in 33 or 34 write a
> warning to the console? 

Almost certainly. I've filed bug 1094825
Sorry, it is too late for 33.1...
status-firefox33: affected → wontfix
tracking-firefox33: ? → -
(In reply to Gervase Markham [:gerv] from comment #20)
> Hi David,
> 
> Thanks very much for listening to the feedback on this. I have one query:
> 
> (In reply to David Keeler (:keeler) [use needinfo?] from comment #15)
> > - When that addon is ready (target is 35, currently aurora), the native
> > implementation will again be removed
> 
> It would be unfortunate if we were to put the addon at version 1.0 ("ready
> for deployment") at exactly the same time as we released the version of
> Firefox which switched off the native functionality. People using
> window.crypto.signText need a little time to do compatibility testing with
> the new implementation, and even if they don't need to update their entire
> sites, they still need to add a check for the presence of
> window.crypto.signText and direct people to install the addon if it's not
> present.
> 
> So I hope that we will allow some time between announcing that the addon is
> ready for use, and shipping a release version of Firefox which removes the
> native functionality.

Right - I guess what I meant to say is that we'll get the addon ready as soon as possible in order to iron out any difficulties in time for the release of a version without these functions implemented natively. The current goal is to do that for 35.

> It would also be good to try and make some more noise about this so web
> developers know it's coming. Can we write up a wiki page with this plan and
> details of what sites will have to do that people can be referred to?

I'll update https://wiki.mozilla.org/SecurityEngineering/Removing_Proprietary_window.crypto_Functions
Attached patch 1083118-backout.diff (obsolete) — — Splinter Review 
This is the patch that backs out the removal of the legacy window.crypto functions. I'm not sure if it would be useful for someone to actually review this or not. The backout command (`hg backout 68499003df5e`) succeeded without needing a merge. Building initially didn't work because nsCrypto.cpp had included nsCxPusher.h, which has since been removed, but it turns out it didn't depend on it anyway, so I just removed the include.
Assignee: nobody → dkeeler
Status: NEW → ASSIGNED
This sets the pref to re-enable these functions by default.
Here's how try went initially:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=144bd1e9a06e
This is after fixing mochitest-3:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=bdaa7e2d0745
Compared to a try run on beta without these patches ( https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=a4ac81abcba4 ), I think this looks not entirely too bad (although, see an earlier try run on all platforms: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=2544e32f7d27 )
Attachment #8519297 - Flags: review?(bzbarsky)
Comment on attachment 8519297 [details] [diff] [review]
set dom.unsafe_legacy_crypto.enabled to true by default (for beta)

r=me
Attachment #8519297 - Flags: review?(bzbarsky) → review+
Comment on attachment 8519292 [details] [diff] [review]
1083118-backout.diff

Approval Request Comment
[Feature/regressing bug #]: removal of window.crypto.signText (bug 1030963)
[User impact if declined]: users of some banks won't be able to do their banking, citizens of some countries won't be able to vote and/or file their taxes, apparently
[Describe test coverage new/current, TBPL]: there are minimal tests
[Risks and why]: This is a large patch. However, it's just a backout of a previous change. The backout caused no merge conflicts and had only one simple build issue (#include of a file that had been removed and was no longer necessary anyway), so it should be as if the original change had never been made.
[String/UUID change made/needed]: nsIDOMCryptoLegacy.idl and nsIFormSigningDialog.idl were re-added (they had previously been removed), some strings that had been removed were re-added to security/manager/locales/en-US/chrome/pippki/pippki.dtd and security/manager/locales/en-US/chrome/pippki/pippki.properties
Attachment #8519292 - Flags: approval-mozilla-beta?
Comment on attachment 8519297 [details] [diff] [review]
set dom.unsafe_legacy_crypto.enabled to true by default (for beta)

Approval Request Comment
[Feature/regressing bug #]: soft-disabling legacy window.crypto functions with a preference (bug 1036546)
[User impact if declined]: users won't know how to enable things like window.crypto.signText
[Describe test coverage new/current, TBPL]: there are tests specifically for this preference/functionality
[Risks and why]: low (this basically just flips the pref by default)
[String/UUID change made/needed]: none
Attachment #8519297 - Flags: approval-mozilla-beta?
(In reply to David Keeler (:keeler) [use needinfo?] from comment #29)
> [String/UUID change made/needed]: nsIDOMCryptoLegacy.idl and
> nsIFormSigningDialog.idl were re-added (they had previously been removed),

This shouldn't pose a problem because the entire idl is being re-added.

> some strings that had been removed were re-added to
> security/manager/locales/en-US/chrome/pippki/pippki.dtd and
> security/manager/locales/en-US/chrome/pippki/pippki.properties

This will likely cause issues. Can you do the backout without adding the strings back?

ni pike/flod for guidance on how to proceed.
Flags: needinfo?(l10n)
Flags: needinfo?(francesco.lodolo)
The fact that strings were present at some point doesn't help, this patch simply results in 4 strings added to a string frozen branch (one week from sign-off).

The only way I can see this landing is without the string addition, and with hard-coded strings instead.
Flags: needinfo?(francesco.lodolo)
(In reply to Francesco Lodolo [:flod] from comment #32)
> The fact that strings were present at some point doesn't help, this patch
> simply results in 4 strings added to a string frozen branch (one week from
> sign-off).
> 
> The only way I can see this landing is without the string addition, and with
> hard-coded strings instead.

This was my expectation. If the strings are required, let's hard code them for 34 as it's preferable to take the backout than not.

keeler - Can you get either a modified patch (preferable) or a second patch that hardcodes the 4 strings on the bug ASAP to make beta8?
Flags: needinfo?(l10n) → needinfo?(dkeeler)
(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #33)
> keeler - Can you get either a modified patch (preferable) or a second patch
> that hardcodes the 4 strings on the bug ASAP to make beta8?

Yes, I can do that.
Flags: needinfo?(dkeeler)
Attached patch backout v2 (no string changes) — — Splinter Review 
Approval Request Comment
[Feature/regressing bug #]: removal of window.crypto.signText (bug 1030963)
[User impact if declined]: users of some banks won't be able to do their banking, citizens of some countries won't be able to vote and/or file their taxes, apparently
[Describe test coverage new/current, TBPL]: there are minimal tests
[Risks and why]: This is a large patch. However, it's mostly just a backout of a previous change. The backout caused no merge conflicts and had only one simple build issue (#include of a file that had been removed and was no longer necessary anyway), so it should be as if the original change had never been made. The changes to the UI code that were made so that we didn't change any strings makes this more risky, but I did verify by hand that the signing form works as it used to.
[String/UUID change made/needed]: nsIDOMCryptoLegacy.idl and nsIFormSigningDialog.idl were re-added (they had previously been removed)
Attachment #8519292 - Attachment is obsolete: true
Attachment #8519292 - Flags: approval-mozilla-beta?
Attachment #8520106 - Flags: approval-mozilla-beta?
Comment on attachment 8520106 [details] [diff] [review]
backout v2 (no string changes)

Approving the backout. Thank you for addressing the string changes. Can you please test once this is in beta8. If there is any issue with the backout, we can respond in beta9.

Beta+
Attachment #8520106 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8519297 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment on attachment 8520106 [details] [diff] [review]
backout v2 (no string changes)

bz - this backout includes changes to webidl files, and the commit hooks won't let me land without DOM peer review. If you could have a look, that would be great. Thanks!
Attachment #8520106 - Flags: review?(bzbarsky)
Comment on attachment 8520106 [details] [diff] [review]
backout v2 (no string changes)

r=me on the webidl bits
Attachment #8520106 - Flags: review?(bzbarsky) → review+
Pavel, could you confirm that the fix is present in the latest Firefox 34 Beta 8 build:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/34.0b8-candidates/build1/?
Flags: needinfo?(lobach_pavel)
Jose, Pieterjan, and others affected by this bug, can you try out Firefox Beta 8 and let us know here if the backout fixed your issues?  Thank you very much!
Flags: needinfo?(pieterjan)
Flags: needinfo?(jose.vano)
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #40)
> Pavel, could you confirm that the fix is present in the latest Firefox 34
> Beta 8 build:
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/34.0b8-candidates/
> build1/?

I confirm, that signText is working in 34.0b8 on Win32
unfortunately can't check on Mac yet.
Flags: needinfo?(lobach_pavel)
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #40)
> Pavel, could you confirm that the fix is present in the latest Firefox 34
> Beta 8 build:
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/34.0b8-candidates/
> build1/?

on linux x86-64 also working as expected
Does your plan (to revive the legacy crypto functions) include the generateCRMFRequest API?

FYI, the open source project Dogtag Certificate System ( http://pki.fedoraproject.org/wiki/PKI_Main_Page ) uses it for its web interface.

It would be highly appreciated if the generateCRMFRequest API could be kept until a equivalently capable replacement API reaches production quality.

The <keygen> html tag feature only provides a subset of the functionality offered by the generateCRMFRequest API, and Dogtag makes use of the extended features.
(In reply to Kai Engert (:kaie) from comment #44)
> Does your plan (to revive the legacy crypto functions) include the
> generateCRMFRequest API?

Currently we're focusing only on signText. The addon should serve as a guide for anyone who wants to extend it to include the other deprecated functions.

> FYI, the open source project Dogtag Certificate System (
> http://pki.fedoraproject.org/wiki/PKI_Main_Page ) uses it for its web
> interface.
> 
> It would be highly appreciated if the generateCRMFRequest API could be kept
> until a equivalently capable replacement API reaches production quality.
> 
> The <keygen> html tag feature only provides a subset of the functionality
> offered by the generateCRMFRequest API, and Dogtag makes use of the extended
> features.

From https://fedorahosted.org/pki/ticket/577 it seems like one of those features is archival (aka key escrow, I'm assuming, although that's just a guess). WebCrypto could be used for this.
Echoing Kai's comment, as far, the generateCRMFRequest API has been used by Dogtag for key archival purpose. We as well as our customers will greatly appreciate its continued support.

David, you mentioned that WebCrypto could be used for archival.  I actually looked into that some time ago but did not find such information.  Could you please point us to that?  Thanks.
Flags: needinfo?(dkeeler)
Unless I'm misunderstanding your use-case, after you've generated a key with crypto.subtle.generateKey, you should be able to wrap it with crypto.subtle.wrapKey. Then you can transmit it for archival.
Flags: needinfo?(dkeeler)
Release noted for Firefox 34 as "Proprietary window.crypto properties/functions re-enabled (to be removed in Firefox 35)"
relnote-firefox: --- → 34+
(In reply to Liz Henry :lizzard from comment #41)
> Jose, Pieterjan, and others affected by this bug, can you try out Firefox
> Beta 8 and let us know here if the backout fixed your issues?  Thank you
> very much!

Sorry, late reply: All good in FF 34.0.5 (Win 8.1), many thanks !

I'll try to follow the add-on development, and get involved if time permits it.
For now I have some mails to write..

Pj,
Flags: needinfo?(pieterjan)
The addon has passed preliminary review and is available for download on AMO:
https://addons.mozilla.org/en-US/firefox/addon/signtextjs/
For those that need it, please try it out and let me know if you find any issues (you can file them here: https://github.com/mozkeeler/signTextJS/issues ).
I can not confirm, that signTextjs addon is working

11 days ago FF35 went on beta channel, there is less than a month to become RELEASE and still there is no way to use the signText.

let me ask (and repeat comment comment #20) - allow some time between announcing that the addon is ready for use, and shipping a release version of Firefox which removes the native functionality.
Addon is not working and some of it functionality (password protected certificates) is not yet released.
So, I think signText must be kept in the future Firefox releases until 100% working addon developed and released.
(In reply to sharapanoff from comment #51)
For the knowledge of the thread, looks like keeler fixed the general "not working" issue here: https://github.com/mozkeeler/signTextJS/issues/6

(In reply to Pavel Lobach from comment #52)
Looks like the password issue is still open: https://github.com/mozkeeler/signTextJS/issues/3


Thanks for the ongoing testing/commenting.
Works on FF35.0.5 on Linux with key on PKCS#11 connected usb crypto token but the master password is displayed in clear text, see https://github.com/mozkeeler/signTextJS/issues/7
(In reply to karlsen from comment #54)
> Works on FF35.0.5 on Linux with key on PKCS#11 connected usb crypto token

That should read FF 34.0.5.
From a user that I asked to test the add-on: "It seems this extension fixes the problem! [...] I tried with one of the banks I'm using"
Looks like we can point to the addon for 35 and there's nothing else to do here.
I see signTextJS is marked as experimental.

Am I correct in my assumption that you will be properly testing signTextJS and releasing it as a proper production release with at least a v1.x version number before the functionality is removed from Firefox again?
Also noting that signTextJS marks itself as "Not available for Firefox 34.0" when attempting to install it on the most recent FF (34.0.5).
The current version 0.6 does not install into a Seamonkey 2.31.

Does it need to be compatible with (future versions of) Seamonkey?
Tested it on latest public release (35.0), works like a charm.

You can install it on 35.0 then downgrade back to 34.0.5, add-on will still be active but can be toggled at will (effective immediately).

Now to get that confusing "master password" field away !
In signTextJS v. 0.6 certificate list gets filled incorrectly, loosing some certificates in process.
https://github.com/mozkeeler/signTextJS/issues/21
Thanks for the singTextJS add-on. It works fine with our OpenCA in firefox 35. 

I just noticed that it lists expired certificates, too (in contrast to the browser's built-in dialog). 

I'm happy to use this add-on but the section "About this Add-on" states: "...This addon re-implements window.crypto.signText as a stop-gap measure that can be used to restore this functionality on affected sites." 

I would also be happy to use the WebCrypto-API if it provided the feature to import certificates and keys from the browsers keystore. All examples that I have seen so far create the keypair on the fly, but if I want to log in somewhere with an X509 certificate which has been signed before by some authority I must be able to use key-material which is persistent across sessions (maybe this is already possible, but I haven't found the appropriate documentation?). 

Martin
As far as I understand, 36 is just like 35: wontfix.
status-firefox36: affected → wontfix
This bug will not be fixed by any changes to firefox. The addon is available for users who need it while sites transition to standardized APIs.
URL: https://addons.mozilla.org/en-US/fire...
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Whiteboard: [use the addon in the link in the URL field]
Switching this to ddn: I need to create Crypto.signText page with info about the right way of doing it. People having a non-working .signText will look for it on MDN and having the right info is important to help them.

I'm currently documenting Web Crypto, so I should be able to do this as part of this work.
Keywords: dev-doc-complete → dev-doc-needed
The signTextJs application currently has the following problems:

- It has a prerelease version number 0.[something]
- It is marked "This add-on has been preliminarily reviewed by Mozilla.", which is explained as meaning "Use caution when installing experimental add-ons and uninstall the add-on immediately if you notice problems."
- The addon is unsigned ("Author Not Verified").

When will the security addon be properly security signed? When will we see a Full Review for the addon? When will v1.x be released?
Flags: needinfo?(dkeeler)
Hi Graham,

The version number doesn't mean much. I've requested a full review on addons.mozilla.org. Once that happens, the warning should go away. As for signing, apparently all addons on addons.mozilla.org will be signed by Mozilla soon, so that should be addressed in the near future as well.
Flags: needinfo?(dkeeler)
You need to log in before you can comment on or make changes to this bug.