I've uploaded an updated version 0.2.5, please udpate as soon as possible. Besides an important bugfix, I've added a status information, that will report the version number of the revocation information that you have installed.

When you install this version, it will download the currently known knockout information.

https://kuix.de/ca-knockout/

We need a mechanism to dynamically revoke CA certificates from the Firefox browser (and other Mozilla software). We might see such a solution in the near future.

However, I would like to offer an immediate solution for those who are eagerly waiting for it. During the last two days I worked on a Firefox Add-On which doesn't require any new infrastructure. As of now it's compatible with Firefox 6 and later.

The idea is to dynamically deliver information to your browser, if CA certificates should no longer be trusted, and it can be effective immediately, without having to wait for a software update.

CA-Knockout is an Add-On which I have signed with my code signing certificate.

The Add-On will attempt to download the most recent information, which I currently host on my private server. The data that is download is also signed with my code signing certificate. The Add-On will ignore any data lacking a valid signature.

Another feature is manual import. If user's connections to my server are blocked (e.g. by a smart Man-In-The-Middle), this feature could be used to circumvent the blockade. Users might share the revocation data via other channels, like email, or direct file transfer. With the Add-On installed, open the Tools menu, select CA-Knockout / Import, and in the dialog that shows up, paste the data you have received. As of today, assuming there are no bugs in the Add-On, I'm the only one who is able to create a signed blob that will be accepted by the Add-On.

If you would like to try it, get the Add-On from https://kuix.de/ca-knockout/ – when installing, in the dialog that asks you to confirm the import, ensure it shows my name (Kai Engert). This tells you that the Add-On has been digitally signed by me. (Please update as soon as possible, initial version 0.2.1 contained a bug.)

In this initial version, the Add-On attempts to download just once per session, shortly after starting Firefox (each time you start Firefox). However, you should get notifications if it fails, and it should offer you to retry the download.

The initial data block that I have prepared is at http://kuix.de/ca-knockout/ca-knockout-latest.txt

It contains the same set of knockout certificates that were shipped with NSSCKBI 1.87 and is contained in Firefox 6.0.2

(Only for testing purposes, get Firefox 6, use a new profile, disable Firefox update checking, install the addon and allow it to import the knockout certs. From this time you should be similarly protected when visiting SSL/https sites running DigiNotar certificates. Remember to reenable Firefox update checking after testing.)

There is at least one usability disadvantage of the current implementation. Because the Add-On is restricted to use the features and APIs that are currently available in the Mozilla platform, in order to install the CA knockout certificates, the Add-On uses the same API that is used to install new CA certificates. This means, you will get a dialog asking you „do you want to trust this CA“, showing several checkboxes where you control which trust you would like to add. The default mode is all checkboxes off – which is good, which is what we want. In order to benefit from the Add-On, you must manually confirm with OK each of the knockout certificates that the Add-On wants to download.

Note that it will try to protect confused users. If a user checks any of the checkboxes, the Add-On will automatically remove that trust after import.

I would like to see many users try this. Who knows, maybe we'll see CA disasters in the near future, before software vendors can implement a better mechanism into their core products? If we do, I'll try to give you updated revocation blobs as soon as I can.

Please try it out and let me know what you think.

Disclaimer: I did this as a private project. Provided as is. Provided under MPL license. No guarantees. Add-On might contain evil bugs. If you can, please look at the code and let me know what you think and report bugs. Also, if you decide to use it, please come back and check for updates – there is no automatic update mechanism. I might host it on the official Add-Ons site later, should feedback be positive.

Good luck,
Kai

In order to stop your browser from trusting the DigiNotar CA, you should upgrade to Firefox 6.0.2 or 3.6.22 as soon as possible.
(Equivalent releases of Thunderbird are expected shortly.)

If you cannot upgrade your Mozilla software yet, for whatever reasons (e.g. you are not an administrator on your computer), then you might be able to use the following manual workaround. See https://kuix.de/q/knockout20110906/ for details.

Kai

I consider to implement a Mozilla Firefox/Thunderbird/SeaMonkey Add-On with the following functionality.
I'm striving for something that I (or we) could implement within a minimum amount of time, like 24-48 hours.

(1) it embeds my personal Code Signing certificate ("cert pinning").

(2) it (daily) pings a given URL, e.g. https://ca-knockout.kuix.de/knockout/latest.txt

The URL delivers plain text data, 3 rows.
- line 1: version number 1
- line 2: the number of the most recent knockout certificate (a steadily increasing number starting with 1)
- line 3: a base64 encoded signature, which signs the text contained in line 2

(3) the Add-On keeps track of the most recently download knockout certificate

(4) if the signature of the most recent knockout number is confirmed, then the addon will download all missing knockout certs
Let's say, the addon had previously downloaded knockout number 1, and the server now says latest knockout is number 3.
Then the Add-On will download the following URLs:

https://ca-knockout.kuix.de/knockout/2.txt
https://ca-knockout.kuix.de/knockout/3.txt

In particular we can use prefs like "most-recent-known-knockout-number"
and "most-recent-imported-knockout".

(5) Retry downloading each of them in order, until successful and until
most-recent-known-knockout-number equals most-recent-imported-knockout.

(6) the contents of the knockout files like 2.txt is plain text data, 3 rows:
- line 1: version number 1
- line 2: the knockout number (e.g. 2), a single space, and a base64 encoded certificate that should be marked as not trusted
- line 3: a base64 encoded signature, which signs the text contained in line 2

(7) import each knockout certificate that can be verified

(8) Add another feature to the Add-On - allow users to import the files like 2.txt and 3.txt directly, e.g. by copying the text into a dialog. With this feature, if a user is in an environment that blocks connections to host ca-knockout.kuix.de - then users could obtain the knockout instructions via other channels, such as email from friends, or any other source.

(9) make Add-On available and suggest that users install it

Last week I helped to get the DigiNotar incident addressed in Mozilla's applications, and also in the NSS library. Today I was asked to explain in detail what we did inside NSS. Thanks a lot to Gervase Markham who helped as an editor of the following text.


This is an interim statement, and represents the personal understanding of me, Kai Engert. It has not been reviewed by other members of the NSS team. If necessary, a checked version of this message will be provided after the US/Canada public holiday. However, I have been involved in creating the patches that we used to address the DigiNotar incident.


Summary:
The NSS team has issued a new version of the NSS module that contains
trust information for CA certificates, NSSCKBI version 1.87. We believe it removes all trust in the DigiNotar root and in all known
cross-certificates and in the DigiNotar-controlled intermediates in the Staat der Nederlanden hierarchy. We have shipped a new release of NSS, containing the same code as the previous release and the updated trust store. It can be found here:

ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_12_11_WITH_CKBI_1_87_RTM/


Details:
I have been asked about the NSS crypto library. Because of this, I will skip what has been added at the application level in Mozilla's products (on top of NSS).

Note that the NSS library consists of several modules, which use their own sub-version numbers. For example, NSS contains a binary module that embeds CA certificates and trust information, according to the Mozilla CA policy. This list is stored in a binary module named NSSCKBI, and certificates within it are referred to as builtin certificates.

For the DigiNotar incident, we didn't produce a new NSS library release. Instead, we released newer versions of the NSSCKBI module.

Last week, in our immediate reaction, we simply removed the "DigiNotar Root CA" certificate and its trust from the NSSCKBI module. We used version number 1.85 for that older release of NSSCKBI. This release wasn't published separately, but it was used in Firefox version 6.0.1 and other Mozilla updates released at the same time.

Later, we noticed this approach wasn't sufficient, because other
intermediate CA certificates exist that are cross-signed by other
non-DigiNotar CAs that we still trust. We started to work on a better
approach, but this was delayed until Mozilla made final decisions
regarding the intermediates being used by the Dutch Government.

On Friday/Saturday, after the decision was made to completely remove all trust from CA certificates related to DigiNotar, the following approach was used as a better blocking mechanism.

We attempted to identify as many CA certificates as possible, and
inspected each of them carefully. Because the NSS library does not yet have the ability to actively mark a specific certificate as completely untrusted, in a way to prevent other trust paths to become active, we used a workaround.

We manually manipulated the binary structure of the known CA
certificates, and created special knockout certificates. The following procedure was used to create them:

- start with the original certificate

- manipulate the serial number to a new number, that is unlikely to
collide with other existing certificates (we used 0x*FFFFFFF)

- manipulate the NotBefore and NotAfter embedded in the certificates,
change them to be in the future when compared with the original ones

This has the following effect: When the NSS library attempts to verify a certificate, it will search the list of known/available certificates. If there are multiple candidates with the same subject names, NSS will prefer the ones that are more recent. This means, our knockout certs will be preferred.

Because of an implementation detail of NSS and Firefox, we made an
additional change to the certificates. Mozilla has asked that software users, when visiting an SSL site that uses a certificate issued by one of the DigiNotar CAs, should still be able to override the default trust decisions made by NSS. Because of this, we had to prevent NSS from checking the signature of our knockout certificates. The signatures obviously were no longer correct after our manual modifications.

The easiest way to prevent this was to apply another binary modification to the knockout certificates, in order to make them appear to be self-signed. This means, while several of the original certificates had different fields for subject name and issuer name, we removed the issuer name and inserted another copy of the subject name.

After these modifications, we added the knockout certificates to the
NSSCKBI module and marked them as not trusted.

We have released NSSCKBI version 1.87 which contains a knockout
certificate for the "DigiNotar Root CA" certificate, and 5 knockout
certificates for intermediates. We published a combination of the latest stable release of NSS 3.12.11 with this newer roots module at
ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_12_11_WITH_CKBI_1_87_RTM/

The following is the set of intermediates known to us:

Issuer: C=NL, O=DigiNotar, CN=DigiNotar Root
CA/emailAddress=info@diginotar.nl
Subject: C=NL, O=DigiNotar, CN=DigiNotar Root
CA/emailAddress=info@diginotar.nl
Serial Number: 0c:76:da:9c:91:0c:4e:2c:9e:fe:15:d0:58:93:3c:4c
Not Before: May 16 17:19:36 2007 GMT
Not After : Mar 31 18:19:21 2025 GMT

Issuer: C=US, O=Entrust.net, OU=www.entrust.net/CPS incorp. by ref.
(limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Secure
Server Certification Authority
Subject: C=NL, O=DigiNotar, CN=DigiNotar Services 1024
CA/emailAddress=info@diginotar.nl
Serial Number: 1184640176 (0x469c2cb0)
Not Before: Jul 26 15:59:00 2007 GMT
Not After : Aug 26 16:29:00 2013 GMT

Issuer: C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc.,
CN=GTE CyberTrust Global Root
Subject: C=NL, O=DigiNotar, CN=DigiNotar Cyber
CA/emailAddress=info@diginotar.nl
Serial Number: 120000525 (0x727100d)
Not Before: Oct 4 10:54:11 2006 GMT
Not After : Oct 4 10:53:11 2011 GMT

Issuer: C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc.,
CN=GTE CyberTrust Global Root
Subject: C=NL, O=DigiNotar, CN=DigiNotar Cyber CA
Serial Number: 120000505 (0x7270ff9)
Not Before: Sep 20 09:45:32 2006 GMT
Not After : Sep 20 09:44:06 2013 GMT

Issuer: C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc.,
CN=GTE CyberTrust Global Root
Subject: C=NL, O=DigiNotar, CN=DigiNotar Cyber CA
Serial Number: 120000515 (0x7271003)
Not Before: Sep 27 10:53:32 2006 GMT
Not After : Sep 27 10:52:30 2011 GMT

Issuer: C=NL, O=Staat der Nederlanden, CN=Staat der Nederlanden Overheid CA
Subject: C=NL, O=DigiNotar B.V., CN=DigiNotar PKIoverheid CA Overheid en
Bedrijven
Serial Number: 20015536 (0x13169b0)
Not Before: Jul 5 08:42:07 2007 GMT
Not After : Jul 27 08:39:46 2015 GMT

Issuer: C=NL, O=Staat der Nederlanden, CN=Staat der Nederlanden
Organisatie CA - G2
Subject: C=NL, O=DigiNotar B.V., CN=DigiNotar PKIoverheid CA Organisatie
- G2
Serial Number: 20001983 (0x13134bf)
Not Before: May 12 08:51:38 2010 GMT
Not After : Mar 23 09:50:04 2020 GMT

And what follows are the details of the knockout certificates we have
created. We believe this smaller list is sufficient to handle all the
intermediates listed above, because some of them have identical subject
names.

Issuer: C=NL, O=DigiNotar, CN=DigiNotar Root
CA/emailAddress=info@diginotar.nl
Subject: C=NL, O=DigiNotar, CN=DigiNotar Root
CA/emailAddress=info@diginotar.nl
Serial Number: 0f:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
Not Before: Jul 27 17:19:37 2007 GMT
Not After : Mar 31 18:19:22 2025 GMT

Subject: C=NL, O=DigiNotar, CN=DigiNotar Services 1024
CA/emailAddress=info@diginotar.nl
Issuer: C=NL, O=DigiNotar, CN=DigiNotar Services 1024
CA/emailAddress=info@diginotar.nl
Serial Number: 268435455 (0xfffffff)
Not Before: Jul 26 15:59:01 2007 GMT
Not After : Aug 26 16:29:01 2013 GMT

Subject: C=NL, O=DigiNotar, CN=DigiNotar Cyber
CA/emailAddress=info@diginotar.nl
Issuer: C=NL, O=DigiNotar, CN=DigiNotar Cyber
CA/emailAddress=info@diginotar.nl
Serial Number: 268435455 (0xfffffff)
Not Before: Oct 4 10:54:12 2006 GMT
Not After : Oct 4 10:53:12 2011 GMT

Subject: C=NL, O=DigiNotar, CN=DigiNotar Cyber CA
Issuer: C=NL, O=DigiNotar, CN=DigiNotar Cyber CA
Serial Number: 268435455 (0xfffffff)
Not Before: Sep 27 10:53:53 2006 GMT
Not After : Sep 20 09:44:07 2013 GMT

Subject: C=NL, O=DigiNotar B.V., CN=DigiNotar PKIoverheid CA Overheid en
Bedrijven
Issuer: C=NL, O=DigiNotar B.V., CN=DigiNotar PKIoverheid CA Overheid en
Bedrijven
Serial Number: 268435455 (0xfffffff)
Not Before: Jul 5 08:42:08 2007 GMT
Not After : Jul 27 08:39:47 2015 GMT

Subject: C=NL, O=DigiNotar B.V., CN=DigiNotar PKIoverheid CA Organisatie
- G2
Issuer: C=NL, O=DigiNotar B.V., CN=DigiNotar PKIoverheid CA Organisatie - G2
Serial Number: 268435455 (0xfffffff)
Not Before: May 12 08:51:39 2010 GMT
Not After : Mar 23 09:50:05 2020 GMT

If you have copies of additional intermediates that you would like to
see blocked, please send us full copies of the certificates, and we will see if further action is necessary.

Regards
Kai Engert