Regarding the recently discovered random number vulnerability:

CAcert’s root keys are not affected, since they were created before the bug existed.
CAcert’s internal systems were affected, and are currently being cleaned up.
A lot of our users are affected.
We are currently working on improved methods to detect the vulnerabilities and inform the affected users about them.
In general, digital signatures and certificates are only affected in the case the any of the underlying keys are compromised. Signatures and certificates do not contain any additional random numbers, so they can’t be affected on their own, if the keys are not compromised.

We currently think that the articles in the media hasn’t informed everyone about the whole impact of the problem yet.

The affected distributions contain Debian, Ubuntu, Kubuntu, Knoppix, Grml, and various other Debian based distributions.
Also various embedded systems that are based on Debian are likely affected.

Regarding the applications, OpenSSL, OpenVPN, OpenXPKI, OpenCA, OpenSSH (especially client authorisation keys!), boxbackup and various other software packages are affected.

All systems that are relying on keys that were generated on affected systems are affected.
This means that you should scan all your SuSE, Fedora, Redhat, BSD, … SSH-servers for compromised keys in the authorized keys files of all users, and blacklist the compromised keys accordingly. (And the same for any other services that might rely on the compromised keys.)

If you want to assess the quality of your own random number generator, you can use our free service here:
http://www.cacert.at/random/

We are currently developing a X.509 vulnerability detection system, which will be available for all CA’s, to discover similarly compromised keys as early as possible. If you want to participate and help there, please contact us.
http://wiki.cacert.org/wiki/HashServer

Message to all non-Debian-derived vendors: Please ship blacklists and blacklist-detection software in your security updates. (Port ssh-vuln to your distribution, …) And warn your users too, not to rely on compromised keys anymore.

General information about the vulnerability:

http://wiki.debian.org/SSLkeys
http://www.debian.org/security/key-rollover/
http://www.debian.org/security/2008/dsa-1571

Luciano Bello discovered that the random number generator in Debian’s openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable.

[…more]

The Perl Authors Upload Server (PAUSE) has had a self signed cert for it’s SSL stuff. As of April 19, 2008 it will use a cert signed by CAcert.

For more information: http://www.cpan.org/modules/04pause.html#ssl

CAcert group is now approved on LinkedIn, and open to the CAcert community. The group is reachable at http://www.linkedin.com/e/gis/89248/182D4E19701F

At the Penguin Convention in Michigan there will be a keysigning party for Michigan and the
surrounding cities (Flint, Lansing etc.). Penguicon is open to the public, but registration is now at the door only for this year.  Penguicon will take place next weekend, April 18-20. in Michigan, US and the details can be found on the official website.  The keysigning portion will take place on Saturday.
More information on the Penguicon Website (http://www.penguicon.org/).

CAcert is now official under the GPL Licence Version 2. More information and the Source Code could be found under http://www.cacert.org/src-lic.php

die Assurer Challenge, die demnächst für alle CAcert Assurer Pflicht sein wird, kann jetzt auch mit deutschen Fragen abgelegt werden. Und auch die Anleitung gibt’s inzwischen auf deutsch: http://wiki.cacert.org/wiki/AssurerPr%C3%BCfung

As promised, there is now a current report posted on the wiki from Audit. Highlights:

• CAcert is in the process of rolling out its new CAcert Community Agreement. The website now refers to it.
• Soon, expect to see checkboxes to tick with statements like “I agree to the CAcert Community Agreement”.
• The Assurance Policy is the next policy that the Audit needs tied down. Currently, it is at an advanced stage. Debate is going on as to whether to drop the requirement for Dates of Birth, as these are considered useful for fraud in some places. Unfortunately, the system does use this as an internal discriminator, so there are pros and cons.
• Pat Wilson is now working on the Security Manual. Thanks, and welcome Pat!
• The critical systems are the critical path for audit! Evaldo has been tasked to build the sysadm team, move the systems and implement dual control. See other blog entries!
• Have you met the Assurer Challenge yet? CATS is in place, and some time soon, assurances will be blocked for those who have not as yet met the challenge.
• If you are interested in the Audit work, there is a ToDo list on the wiki, and I have put the audit criteria online with the working commentary and (wip) conformance. See the main report for that location and the secret password!

That’s it from the Audit side. Now over to you!