Category Archives: Information

General news/information to the CAcert community or about security in general

Assurance Policy now in DRAFT

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:

  1. The general standard of a Name is that it is as written on a government-issued photo ID.  It should be recorded as fully as possible.
  2. However, because there are many variations in real life, multiple names will be possible.  That is, the online system will have a new feature added to it to add extra names, each requiring full Assurance independently.  When that is done, this will address the difficulties that people have with different documents, transliterations, married names, middle names and initials, etc.
  3. We’ve always encouraged Assurers to assure each other mutually, and this policy goes one step further:  it encourages non-Assurers to also assure you, under your supervision.  That is, when assuring a Member, you take the Member through the process of Assurance as if she were an Assurer.  You advise her on the steps, and encourage her to allocate 0,1,2 Assurance Points to you according to her judgement.  Be strict, it is better for her to allocate zero points to you to get used to the idea of assessing Name and other issues. You keep the forms, and when we get the system changed, you will enter in her points. Mutual Assurance will help us in the future:  It has the benefit of equalising the relationship, explaining the whole process, preparing the junior Member for the role and responsibilities of Assurer, and also identifying who you are to her.  As you the Assurer will be responsible for the entire result, and it takes extra time, you can choose to do it or not.
  4. As we now live in a world of Identity Theft, it is important for you the Assurer to protect the Members from harm.  In particular; false Assurances do happen, and could be used to acquire valuable information.  To this end, the Assurance Policy states:

    “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.

  5. The final big change is that Experience is no longer to be reflected in the Assurance Points.  In the future, there will be a separate set of points, called Experience Points.  Each Assurance you conduct will earn you 2 Experience Points, as before.  Separating out the points to match their meanings gets rid of a lot of mental gymnastics.  Again, we have to wait until the software is done.

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?

Canberra Australia assurance event and CAcert presentation, 24th July

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 SSL Guardian

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/

Assurers at Festival Of Roses 2008

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.

CAcert.org at OpenExpo08 in Zürich/Winterthur – September 24./25., 2008

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

Audit Report 20080602

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 CAcert Community Agreement is in place as policy, now, but the roll-out of other important issues such as CAP form (here), agreement on the website, and emailed notifications of change are all lacking.  Lack of developers is an issue, and is probably the same story as with the systems administrators team.
  • Arbitration is working out well, and we are now in the “teething stage” of working through the little and unexpected problems.
  • The Assurance Policy work-in-progress is now in a call to go to DRAFT, which will make it binding on the community.  This important document lays the framework for Assurance, leaving most of the details for the Handbook.  There are a couple of fairly minor changes that Assurers will need to be aware of:
    • Assurance points now only cover Assurance on your details, and there is now (to be) a new count for Experience Points.  Assurance Points will therefore always indicate only of how others have assured you, and Experience points will indicate how many Assurances you have done.
    • Mutual Assurance is now a standard option, and the CAP form will be upgraded to show that.  In effect, a non-Assurer can now assure an Assurer, but, this assurance happens under the supervision and responsibility of the Assurer.  For this, a non-Assurer can allocate 0,1,2 points according to her judgement, and you should teach her to be skeptical!
  • As soon as we can make it, the older Assurers who have not done the Assurer Challenge will be blocked from more Assurances.

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.

Recent Debian private key generation vulnerability

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 handling by CAcert

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.

Archived copies of Identity Documents should be destroyed within CAcert.

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.