Das erste BarCamp in Stuttgart wird am 27. und 28. September 2008 im Literaturhaus Stuttgart und den Räumen der MFG stattfinden. Hier wird es auch die Möglichkeit der CAcert Assurance geben.
Weitere Infos auch unter http://wiki.cacert.org/wiki/BarCampStuttgart2008
A week or so ago, the policy group pushed the Assurance Policy into DRAFT, which means according to PoP that it is now binding on the community. To all the Assurers out there, this is your policy!
You should take a moment to have a look at it. As it is in DRAFT, there is room for change, although each change will need to be voted through in the policy group. You will see its evolution in the striking and bolding of parts. Also be aware of the Assurance Handbook, which is where most of the daily practice will end up. Now that there is a policy, the Handbook should also evolve more clearly and more rapidly.
The Assurance Policy establishes many things that in the past have been unclear or subject to variation. Here’s a brief list of some changes:
“A Member may check the status of another Member, especially for an assurance process…”
In the future, we will need some way for you the Assurer to show you really are an Assurer. How that is done is left up to the systems and management people; a future thought puzzle.
As you can see, there is more work to do! The policy needs to be reviewed, improved and taken the final step to POLICY. Until it goes to POLICY, you still have a chance of fixing or improving it, even though it is already binding on you, the Assurer. And, the Handbook needs updating with the new Policy work.
Also, the account system needs to be updated to add these features: multiple names, a new set of points for Experience, mutual Assurance, and perhaps some support for showing your status as Assurer. This will take time, but help will make it go faster: are there any PHP programmers who can help make those coding changes?
There will be a CAcert presentation and a WoT assurance event in Canberra on the 24th July at 7pm (localtime). It will be held at the ANU as a Canberra Linux Users Group meeting. Anyone who wants to turn up is welcome. The initial talk will be on Linux music, followed by a brief talk on SSL, certificates, CAcert services and needs, and finally assurance services will be offered.
Bring along your government IDs, printed personalised WoT forms available from CAcert My Account (CAP/TTP Forms) and $6 for pizza afterwards.
Heise has developed the SSL Guardian tool, which is able to detect compromised server certificates for all Windows applications that are using the CryptoAPI. To secure your windows machine for free, please head over to http://www.heise-online.co.uk/security/Heise-SSL-Guardian–/features/111039/
On august 8, 9, 10 and 11 the Festival Of Roses (Rozenfestival) is held in Lottum, the Netherlands.
If you plan to visit and you’re looking for assurers, Maurice and Joost will be at the festival itself (and several more in the vicinity).
There will be no official CAcert stand and no official CAcert presence. plese make arrangements with us in advance, otherwise finding us can be hard.
OpenExpo, the Swiss conference and trade show for Free and Open Source Software, takes place for the 5th time Wednesday and Thursday September 24 and 25, 2008 at the Eulachhallen in Zürich/Winterthur. Read more… http://www.openexpo.ch/en/openexpo-2008-zurich
Additional Swiss assurers or assurers from any country with successfully passed assurer test and willing to help, register in the CAcert.org Wiki: http://wiki.cacert.org/wiki/OpenExpoCH2008-Z%C3%BCrich/Winterthur
———————————————————————————————————————————————–
OpenExpo, die Schweizer Messe und Tagung für Freie und Open Source Software findet in fünfter Austragung am Mittwoch und Donnerstag, 24./25. September 2008 in den Eulachhallen Zürich/Winterthur statt. Mehr unter… http://www.openexpo.ch/openexpo-2008-zuerich
Zusätzliche Schweizer Assurer oder Assurer aus irgend einem Land mit erfolgreich absolviertem Assurer Test, welche mithelfen wollen, tragen sich bitte im CAcert.org Wiki ein: http://wiki.cacert.org/wiki/OpenExpoCH2008-Z%C3%BCrich/Winterthur
The June Audit report to the Community, the latest in a series of two-monthly reports, is now on the wiki. Here are some highlights.
The biggest issue facing CAcert is the state of the systems and the systems administration team. The Audit requirement is for the systems to be under a secure regime that is suitable for a certificate authority: dual control, extra eyes over the critical systems, and reasonable physical security. These things have not been done for the critical systems, and only partly done for the non-critical systems such as email, wiki.
The recent plan to have Evaldo lead the process has been dropped (not in my opinion due to any failing on his part). Now the board of CAcert has to work up a new plan to make this happen somehow.
The move of the critical systems and the rebuilding of systems administration into a team has taken on the aspect of a never-ending Nordic saga, which is no good sign. I will give it until the end of the year to see if CAcert can build the team, and put the systems into shape. If not, we as a Community will have to re-examine how we are going to move forward without systems that are adequate to the certificate authority mission.
Other highlights:
The Audit is a long way behind schedule. As above, the systems are completely stalled. The policy work is also slow, and although not a blocking action, it should be stressed: we need these policies in place, not perfect, but usable. Seek for consensus, and be prepared to lose some battles. By the end of the year, we should have the Assurance process on a good strong basis.
Recently discovered predictable RSA and DSA key generation vulnerabilities occurring in Debian OpenSSL packages[1][2]. 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[3]. The rest of this advisory will focus on key and X509 certificate implications.
Description:
Users and system administrators generate RSA and DSA keys for a large number of applications[4]. 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[3] 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
[1] http://www.debian.org/security/2008/dsa-1571 Debian Security Advisory
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166
[3] http://www.debian.org/security/key-rollover/
[4] http://wiki.cacert.org/wiki/DebianVulnerabilityHandling
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:cacert-policy@cacert.org) 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.