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.
CAcert certificate issuance with unverified arbitratry email addresses
The CAcert issuance of certificates had a vulnerability that permitted an attacker to add arbitrary email addresses without verification.
Issuance of certificates is by means of login to a webpage by Members. After authenticating the Member, she is offered a choice of certificates, with a choice of pre-verified email addresses.
In the POST response to that choice, there is insufficient checking on the paramaters supplied, and it is possible to add multiple additional email addresses that are not pre-verified.
The specific failure is use of register_globals and insufficient paramater testing.
A Member may add email addresses from a limited range of TLDs (Japan only has been verified).
The paramater checking has been fixed. Register_globals is now turned off in the test system to explore side effects. Operational software will follow
Only Japan TLD addresses may have been affected. There is no indication that any prior issued certificates with Japan TLD email addresses are other than valid.
This is a Member-reliance issue only. Any disputes will be filed in CAcert’s internal Arbitration forum.
CAcert credits Kriss Andsten for reporting this issue.
CAcert, Teus Hagen
Recently discovered predictable RSA and DSA key generation vulnerabilities occurring in Debian OpenSSL packages. As many Linux distributions are based of Debian derived distributions like the popular Ubuntu, Knoppix, Kubuntu distributions, there are a significant number of vulnerable RSA and DSA private keys around now.
SSH keys generated on Debian distros have these vulnerabilities too. This will affect SSH system administrators and users. These users should refer to available advice. The rest of this advisory will focus on key and X509 certificate implications.
Users and system administrators generate RSA and DSA keys for a large number of applications. Those who have OpenSSL, or any of the many applications that use OpenSSL libraries, on vulnerable platforms are affected. Those systems that allow remote access as a result of a user provided vulnerable public key may also be at risk of unauthorized access.
How is CAcert affected?
Luckly, the CAcert Root Class 1 and 3 keys are not affected as these were generated before the vulnerability was introduced into Debian in September 2006. The process that signs CSR (certificate signing requests) and therefore all signed public keys does not use any key generation, so they are not affected by CAcert. Conclusion: CAcert does NOT have to reissue every signed certificate.
But if you have generated a new certificate later as August 2006 and used OpenSSL on a Debian system please read on. First is explained what actions have been undertaken by CAcert in order to recover from this vulnerability event. If you used Debian this may help you as well.
CAcert is using Debian OS and so CAcert’s internal systems were affected, as they generated predictable RSA and DSA keys for internal use, eg ssh authorized_keys for remote system administration. As SSH access is restricted to only to a few static configered IP addresses this posed only a very low risk.
The server certificates of servers like https://www.cacert.org and https://secure.cacert.org were affected by a poor key. CAcert has replaced those keys.
How can servers and clients be affected and what should you do now?
Please refer to our Debian Vulnerability Handling wiki page.
Daniel Black, system administrator for CAcert
 http://www.debian.org/security/2008/dsa-1571 Debian Security Advisory
Date of Birth information is needed for operational purposes and could not be dropped.
CAcert takes strong measures to maintain and guard your private information. Currently CAcert uses for individuals the full formal name, date of birth (DoB) and email/domain address(es). The DoB is used for discrimination of similar names of individuals.
A long debate on the CAcert policy email list (email:email@example.com) discussed the issue if date of birth could be dropped from the archive. Alternatives for purpose of name discrimination were explored and debated upon. But it did not result in an accepted and efficient alternative.
CAcert made the decision to comply fully with the European privacy directive (EU DPA). The DoB information is however felt to be archived and needed for operational measurements at Assurance time (Web-of-Trust) and later. Alternatives, which are hopefully better in the name resolution, will continue to be investigated and solutions are challenged for.
It is noticed that the date of birth information is commonly used in the internet environment (and even more private information is made available) and that this data is poorly managed. Even some (European) governments are providing this information openly in some instances. The data of birth (and even email addresses) are only available to CAcert Assurers and only in times of assurance requests and arbitration cases if needed so. There are binding policies for the Assurers for doing so, subjected to arbitration.
CAcert will destroy archived copies of ID’s and asks their Assurers to do so as well.
When CAcert started in 2002 it was required that copies of ID’s were archived for 7-10 years in the archives of CAcert or archives of CAcert Assurers. In a later instance CAcert required to take note of ID numbers and/or social security numbers of the individual instead of the copy of the ID. In 2006 for privacy reasons this data (copy of ID, personal numbers) was dropped. The CAcert Assurance Programme (CAP) form states however that the information should be kept 7-10 years.
As CAcert Inc. dropped the requirements for copies of ID and personal numbers the CAcert Inc. association by order of the Committee (Board) decided to remove this information from the CAcert archives and require that the CAcert Assurers who are in possession of that information to do the same: destroy archived copies of ID’s and delete social security numbers from the CAP forms. The information should be deleted with care as stated in the CAP agreement.
At the NLUUG (dutch Unix/Linux user group) conference, Ede, Holland on the 15th of May 2008 CAcert will have a special booth for CAcert assurances (information, individual and organisation assurances). See conference details .
CAcert Inc. as association, will have a Special General Meeting on two by-laws issues to be voted upon:
- Rules defining non-profit (a prerequisite for tax reasons);
- Enable to vote via email by CAcert association members (needed to get an easier influence from membership).
The SGM is on 4th of April 2008 11 pm MET, via CAcert irc channel. The details are in the SGM agenda.
CAcert association members are called to attend this meeting. The minimum quorum for a formal meeting is five attendees. Even if these voting topics are not much of a discussion the SGM is important and minimizes the costs of operation.
At the ApacheCon April 7-11, 2008 in Amsterdam, the official Apache User conference of the Apache Software Foundation there will be a CAcert booth for Individual and Organisation Assurances from 9-11 April. Visit the booth!
Be prepared and if you are not a CAcert Coimmunity Member yet, read the Community Agreement, join and registrate and print at least three Community Application (CAP) forms with your name and email address for the Assurance event.
The Oophaga Foundation, which organisation is taking care of CAcert events in Holland is looking for CAcert assurers who can help to assure on these conference dates. Please react to cacert-support if you want to help.
As you may know, CAcert started a big effort in 2007 to address who we are as members of a CA service provision, the Community and the increase of the recognition of CAcert as a professional CA.
CAcert belongs now to the top ten CA’s in the world! This all was inspired and demanded by the need to have CAcert Root Key included in the browsers. For this CAcert started the Audit process, which focused on the questions of Risks, Liabilities, and Obligations amongst us all.
CAcert has now conquered that monumental task. Core of that task was defining who we are as a community, and writing a CAcert Community Agreement that we can all agree to, which brings us together as that community, and which protects you, using the CAcert issued certificates, legally, financially and freely.
Here you can read the details of the CAcert Community Agreement .
Introductory notes on the agreement are on the wiki. This introduction attempts to explain some of the parts, which need maybe some more explanation, eg on free certificates, privacy concernings, certificate care and usage risks, and the CAcert Community.
The Agreement is now approved: by the Board, by the Policy Group, and by the Association, and it is now ready for you!
CAcert software developers will modify the website and the Assurance team will modify the Assurance processes to ask people to agree to it.This will take some time.
In the end we will need agreement from everyone inside the CAcert Community, because it protects each and every one of you, and all of us together, as a community.
CAcert Management Sub-Committee
At the upcoming Fosdem’08 Free and Open Source Developers’ European Meeting, 23-24 Febr 2008 in Brussels, Belgium there will be at Sunday 24 Febr 2008 12-14 pm, Ferrer room a CAcert Assurance event as well a PGP signing party will be helt. During the meeting days there will be enough assurers around to assure you also if you cannot make it on this time.
Be prepared and take the CAcert Assurance Programme form and for PGP your PGP fingerprint with you to the meeting. For details see http://www.fosdem.org/2008/keysigning. For early birds: make sure you can improve the distribution algorithm to be explored on the 22nd of Febr during the Fosdem Pink Elephant Edition event.