A few days ago, a group of scientists and security specialists finally succeeded to create a rogue CA that was able to issue certificates that are accepted by all browsers:

http://www.win.tue.nl/hashclash/rogue-ca/ and http://www.phreedom.org/research/rogue-ca/ The problem underneath are weaknesses that were discovered in the MD5 hash-algorithm.

CAcert has switched from MD5 to SHA-1 for certificate-issueing a few years ago, when the first research results were made public that indicated that such an attack will become feasible. CAcert is currently still using an intermediate CA that was issued with an MD5 based signature 3 years ago. We are currently working to phase out this intermediate CA.

We suggest that all certificates (except for root certificates, which aren’t affected), regardless of which CA has issued them, that were still issued with MD5, be replaced with SHA-1 based certificates within the next 3 months. We also suggest that all company-internal or organisation internal CA’s be checked and switched from MD5 to SHA-1 where necessary. To detect, whether a webserver certificate or any of the intermediate certificates are MD5 based, you can use this Firefox extension: http://codefromthe70s.org/sslblacklist.aspx

Happy new year!

Although the new RootKeys are generated, they are not yet availlable. At the moment there is a review of the new keys going on to see if they comply fully with the requirements for inclusion in the mainstream browsers. When the review is succesfull, the new RootKeys will become public and will be used to sign new or renewed certificates.

The blog will be the first place where you can read they have gone on-line, as well as additional info

Today, Friday 28^th of november, CAcert is creating new RootKeys for signing the certificates. This is done to comply to the audit requirements of having everything documented. Our current RootKeys are audit fail because it lacks documentation about the procedure.

The current RootKeys will NOT be revoked yet because there are thousands of certificates still relying on them.All new or renewed certificates will be signed by the new RootKeys as soon as they are operational. Some extensive testing is done in the last few months for creating, securing and implementing the RootKeys on a very high standard and open way.

The generated RootKey and two sub-root keys for assured community members (class 3) and (not assured) community members (class 1) makes use of open source tooling, certified in the past with FIPS 140-2 certificate for OpenSSL (Mar 2006).

Replacing the RootKeys is the last part of the server rehosting to the Netherlands which was done in October.

As mentioned by Maurice, I presented this at LISA2008:

An Open Audit of an Open Certification Authority

How does a lightweight community Certification Authority (“CA”) engage in the heavyweight world of PKI and secure browsing? This talk tracks the systems audit of CAcert, an open-membership CA, as a case study in auditing versus the open Internet, community versus professionalism, quality versus enthusiasm. It will walk through the background of “what, why, wherefore an audit,” look at how CAcert found itself at this point, and then walk through some big ticket items: risks/liabilities/obligations; assurance and what’s in a name; disputes and reliance; and systems and security.

Can CAcert deliver on its goal of free certs? The audit is into its 3rd year as of this writing; and remains incomplete. Some parts are going well, and other parts are not; by the end of the year 2008, we should be able to check all of the important areas, or rethink the process completely. Hence, finally, the talk will close with progress and status, and recommendations for the future.

There are slides and a very long paper on my paper’s page.  As this was a talk invited by LISA, and as the job of audit is to look for the bad things, not the good things, this talk is quite brutal in parts. Not for the squeamish.

Gleich zwei CAcert-Parties gibt es diese Woche in Düsseldorf/NRW:

Der Chaos Computer Club Düsseldorf (www.chaosdorf.de) bietet am 28.11. ab ca. 20:00 eine Zertifizierungsmöglichkeit an. Hier können sich Interessenten auch über die Hintergründe zum Thema CAcert und PGP-Verschlüsselung informieren. Einlass ist ab ca. 19:00.

> Chaos Computer Club Duesseldorf
> Fuerstenwall 232
> 40215 Duesseldorf

(Sollte das Tor nicht offen sein, bitte klingeln).

Im Anschluß an den Java-Vortrag der Rhein-Jug (www.rheinjug.de) zum Thema Open JDK und Da Vinci VM gibt es am 30.11. eine weitere Möglichkeit, sich assuren zu lassen. Der Vortrag selbst findet ab ca. 19:00 statt, Assurer werden ab ca. 18:30 vor Ort sein. Während dem Vortrag ist KEINE Assurance möglich, erst wieder ab ca. 21:00.

> Institut für Informatik
> Heinrich-Heine-Universität Düsseldorf
> Gebäude 25.22
> Hörsaal 5G

CAcert and secure-u e.V. are at the Systems 2008. You can find us at Hall B3 Booth 127.

CAcert und secure-u e.V sind auf der Systems 2008. Sie finden uns in Halle B3, Stand 127.

The CAcert Inc. association baord election will take place at the upcoming CAcert Association Annual General Meeting (AGM 2008) of the 7th of November 2008. If you are a CAcert Association Member and will become nominated for this election please get in touch with the CAcert board and have you nominated by at least two association members.

More details on the CAcert Inc. assocation can be found at the association wiki page
The upcoming AGM2008 agenda and references to reports can be found here

The CAcert critical services are now running on machines in the Netherlands.  This involved shutting down the machines in Vienna, transporting the data to Netherlands, handing over to a new team, and bringing the data up in the new location.

Names and places of the running systems will be mentioned elsewhere no doubt, but our thanks go to two groups in Vienna:  Funkfeuer and Sonance.  These two community groups provided the help when it was needed, and now they stand down from operational support to CAcert, retaining only a mention in the history (and, of course, many future Assurances).

To look at the audit context:  Although I was there, this move was not an audited, officially monitored operation;  this is because (a) the audit was frozen back in December of 2006, partly because of the difficult systems issues, (b) we still lack the full documentation set against which to audit, (c) the new team are focussed on getting basic control, and are not ready for dual control.  Also, always remember to view the auditor presence under the Heisenbergian lens of skepticism! It is your job to check the move and make it safe.  The auditor makes sure you are doing the job, so that we can all rely on the job being done each and every time.

Once we get a declaration that things are under control, the team expands its vision from the brutal short-term needs, and starts on its impressive task list, we will look at getting the audit formally restarted.

Still, that all said, the big job has been done, and done well.  The systems are now in place in the BIT high security ISP, and the new team is doing the work-through.  That will take place over the next few weeks.  At some stage, the new team will then be looking to carve up the work and bring in new people.  This latter expansion will be handled carefully, but it is necessary.  Think about that…

You can help in two ways.  One, take load of the systems people by helping in support, software and a myriad of other tasks.  Two, getting the CPS into DRAFT by answering the two blocking challenges.  Over to you!