Before: Arbitrator BernhardFröhlich (A), Respondent: CAcert (R), Claimant: Michael T. (C), Case: a20110312.1

History Log

Original Dispute, Discovery (Private Part)

Corresponding bugreport in Mantis are 918 (sending mails) and 954 (mass revocation).

Original Dispute


Results of Script run:

It turns out that a single run of the script took about 9 hours :-( So if we need to run this script again in the future with multiple output filters, I'll think of a more efficient way; mkfifo and tee might come to our rescue here :-)

The job finished this morning at 6:30am ... The outcome of the first run (with openssl-vulnkey filtering) reported 879 lines, while the second run (without filter) reported 1679 lines. In addition the output contains a number of warnings for certificates with 8192-bit keys, like:

This happened for 64 certificates in each run. Since you seemed to insist on storing as little information as possible on disk, I have removed those WARN lines from the attached script output. But they are still available when really needed.

+ date
Mon Apr 18 12:26:55 CEST 2011
+ ./
+ grep openssl-vulnkey
+ wc -l

real    525m23.119s
user    298m11.082s
sys     108m13.862s
+ ./
+ wc -l

real    555m6.856s
user    298m17.675s
sys     108m25.471s
+ date
Tue Apr 19 06:27:26 CEST 2011

Confirmation of mass revocation script run by critical admins:

Op 28-7-2011 10:10, Wytze van der Raay schreef:
> On 27.07.2011 23:02, Bernhard Fröhlich wrote:
>> ...
>> Once the scripts are installed you should execute them according to
>> The execution command is to pipe the result of into
>> mass-revoke.php:
>>   ./ | ./mass-revoke.php
> The run has been started. I will mail you the results when it has completed
> (probably some time later today).
Here is the result of the mass-revoke run:

Started: Thu Jul 28 10:08:12 CEST 2011
Certificates revoked: 938 server certs, 133 client certs, 57 Org server
certs, 0 Org client certs.
Update failures: 0
Finished: Thu Jul 28 20:09:14 CEST 2011

-- wytze

EOT Private Part



First intermediate Ruling

Like explained by the Claimant it seems that CAcert has issued certificates for keys which can easily be broken. As part of our mission to educate and protect our members action shall be taken to investigate the problem in detail.

I therefore rule that Software Development shall create a set of scripts to find out the affected certificates and their owners, which will be executed on CAcert's main database.

Also I rule that Software Development shall prepare a patch to the web page so that weak keys will not be accepted for certificate creation in the future.

Second intermediate Ruling

After discussion with Software Development "weak keys" are defined as

A test run of the created scripts is authorized to evaluate number of affected keys per category.

Third and last intermediate Ruling

After the software fixed have been installed creating new certificates for weak keys should not be possible anymore. Now the owners of weak keys must be notified that they should create new keys to avoid being attacked, and the existing certificates must be revoked after a grace period for user interaction.

The scripts extracting the mail adresses of affected users and sending the mails have already been prepared and reviewed. Their execution is hereby authorised, the action date (line 140 in mail-weak-keys.php) shall be set to '2011-07-15'.

Software Development shall prepare the necessary tools to revoke all weak key certificates as soon as possible after July 15, as announced in the mails.


Similiar Cases

Arbitrations/a20110312.1 (last edited 2011-07-31 13:55:35 by BernhardFröhlich)