CAcert NEWS Blog

AR.20080902.A1 CPS issues: 2 bugs

iang — Fri, 05 Sep 2008 15:31:09 +0000

One side issue relating to the earlier post: in order to release funds for the critical systems work, we will need to sort out the CPS quickly. There are two blocking questions that need to be fixed, so I’ll list them here for all to think about:

CPS Bug #1: Assurance is now on a good footing with the DRAFT Assurance Policy, and we can state with some confidence that CAcert does a good job at identifying people within the community.

But, there is a bug: the certificates with names do not always use Assured Names. Specifically, in the Organisations, there is no compelling reason to use Assurance information or anything else to name people. So, Members are faced with a “name” that is either strongly Assured, or worthless, or somewhere arbitrarily in-between.

How are you to tell the difference? Perhaps by further looking in the certificate, but forcing people to investigate every certificate to figure out detailed issues makes a mockery of the process, and of the Assurers.

Let’s put it to you: Should the Name in the certificate (specifically, the CommonName or CN field as shown by software) be

always Assured?
always strong through some other mechanism, either Assurance or elsewise?
sometimes be Assured, sometimes unknown, like now?
be entirely variable at the discretion of the person?

All of these choices have merits. For example, the last one looks odd, but is maybe OK, if we recall that all certificates will identify the Member through the serial number.

What do you think? Over on the policy group, a choice will have to be made somehow, so dive on over there and help.

CPS Bug #2: The domains and email addresses placed in certificates are only ping-tested once, when added. Over time, various changes and problems can occur, such as transfer, expiry, loss, etc, so this is not good. Something has to be improved. The question is, what? There are these possibilities that I have seen so far:

frequent or regular ping checks on email addresses,
automatic revocations on domain expiry or transfer,
a change made to a website through HTML text or headers, etc, to show control,
a change made to DNS records to show control,
a change made to Registry records to show ownership or delegation of control,
a statement of ownership or control made to CAcert in the online system,
or?

Probably, we need some combination of 2 or more of the above, because some of them will be hard for people to do. As before, check in on the policy group to express your opinion.

Bandwidth saved by RSScache.com

Audit Report 20090902

iang — Thu, 04 Sep 2008 15:41:49 +0000

The latest of the audit reports, for July-August, is now on the wiki. As this report and CAcert’s current situation are almost totally dominated by critical systems issues I shall only list those here. First, the big direct issues:

The new plan for critical systems is now in place and approved by Board of CAcert.
The Vienna systems will be shutdown on 30th September. This is a slightly variable date, it could change, but not substantially. The intention is that they will not be restated, see below.
The data will be incorporated into the Netherlands machines over the days following that date.
So, service to CAcert will be interrupted from 30th September.
Until the job is done. There are estimates as to how many days this will take, but I won’t repeat them here. It will take as long as it takes.
Which means, if the migration does not succeed, then CAcert may be left without an operating CA.
I’ll be there. If you are in the Netherlands in the first week of October, and would like to help, let us know. We might need it!

The above plan is the Number One Thing on everyone’s desktop. Other issues that bear mentioning are these, because they effect the plan:

The Vienna systems are Audit Fail. They were always a temporary arrangement, almost emergency status, and represent no base for the future nor a base for a responsible, professional CA. Somewhere, the line has to be drawn, and the board has agreed it is time to draw that line. 30th September. Hence, above, there is no intention to fall-back to the Vienna systems.
The old Roots are Audit Fail. This is because there is no clear history, no documentation, and sanity checks don’t change that view. So, a task for the Dutch team is to create new roots, but only when they’ve got everything else sorted out, and only after the process is properly documented. (As an aside, the roots situation was reported and agreed with the board September 2007.)
There was a security bug reported last month by a member. The handling of that bug was good, as it was more or less dealt with, within around 12 hours, and notified to the community. That’s the good news.
The bad news is that the bug was rather bad, and likely indicative of others of the same class. (If you are into PHP, just think register_globals …) The software development team has a lot of work to do.
Clearly, software development also suffers from the same lack of people as with the systems administration team. After the critical systems is put onto a sound footing, management will have to look at the development side as well. Meanwhile, you can help if you have PHP skills. Ask to get access to the test system, and ask for a small task to look at. There are many!
Meanwhile, there is little benefit in shooting the messenger. It’s impolite and a waste of a good bullet. Security is a process: it is about fixing and improving. It decidedly isn’t about pretending there are no bugs, nor that our code is perfect or even high quality. Our thanks to Kriss for debunking that myth.

Some have said that this report looks overly dark. If anything, it is too polite, not dark enough: CAcert has had 2 years to prepare the critical systems, and has not. It has had over a year in the current situation, and not done the migration. The issues are very clear, and have been repeated maybe a hundred times, so I won’t list them again.

The time has come for CAcert to decide whether you want an audit or not.

That’s it from audit. Next report will be (not before) November. Either it will be lighter, or darker. Over to you!

Bandwidth saved by RSScache.com

CAcert event at Drupalcon Szeged 2008

sanduhrs — Mon, 25 Aug 2008 17:51:40 +0000

Drupalcon is the twice-yearly gathering of Drupalers to learn about, discuss and advance Drupal, and to network with other community members. Experience this thriving community in person yourself in Szeged, Hungary!

See the Drupalcon website for more information.

At Drupalcon we’ll have a CAcert event organized by the people from erdfisch. If you need some assuring you’ll find them every day of the conference from 12:45 to 13:15 on the ground floor in the sitting corner near the registration desk.

See the full announcement CAcert event at Drupalcon

Bandwidth saved by RSScache.com

Wuppertal 24 Live mit CAcert Assurances

dastrath — Sun, 24 Aug 2008 19:10:00 +0000

Im Rahmen von Wuppertal 24 Live (14.09.07 bis 15.09.07, 18:00 - 02:00 Uhr) veranstaltet die Wuppertaler Linux User Group einen (nicht nur Einsteiger-) Themenabend mit Linux-Installationsmöglichkeiten.

Selbstverständlich wird es sowohl die Möglichkeit geben, sich über CAcert zu informieren, als auch CAcert-Assurances durchzuführen.

Bandwidth saved by RSScache.com

CAcert auf den mrmcd111b

jtb — Thu, 21 Aug 2008 17:02:32 +0000

Auf den meta rhein main chaos days 111b: “connecting the dots” vom 05. September bis 07. September 2008 wird es wieder einen Vortrag mit abschließendem GPG-Keysigning und CAcert-Assurance geben.

Mehr Infos im Fahrplan: Key Signing und CAcert

Bandwidth saved by RSScache.com

CAcert auf der FrOSCon 2008

wonderer — Mon, 18 Aug 2008 15:04:48 +0000

Auch dieses Jahr ist CAcert mit einem Informationsstand auf der FrOSCon vertreten (Sankt Augustin 23.- 24.08.2008). Interressierte, Assurer und welche, die es werden möchten sind herzlichst dazu eingeladen den Stand zu besuchen und sich ggf. vorher unter http://wiki.cacert.org/wiki/FrOSCon2008 einzutragen um den Platz entsprechend bereit zu halten.
Die FrOSCon bietet auch dieses Jahr wieder eine große Auswahl an Themen aus dem Bereich Freier Software und Open Source. Das Programm ist online unter http://programm.froscon.de abrufbar.

Bandwidth saved by RSScache.com

[Ad] Oprah's Superfood of the Year!

Detoxify and Lose Weight with AcaiPure - Click Here for Free Trial

Vulnerability Note, 14th of August 2008

teus — Thu, 14 Aug 2008 13:20:40 +0000

CAcert certificate issuance with unverified arbitratry email addresses

Overview
The CAcert issuance of certificates had a vulnerability that permitted an attacker to add arbitrary email addresses without verification.

I Description
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.

II. Impact
A Member may add email addresses from a limited range of TLDs (Japan only has been verified).

III. Solution
The paramater checking has been fixed. Register_globals is now turned off in the test system to explore side effects. Operational software will follow
soon.

Systems Affected
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.

Vendor Status Date Updated
CAcert Fixed 14th of August 2008

References
bug report
Kriss his blog

Credit
CAcert credits Kriss Andsten for reporting this issue.

CAcert, Teus Hagen

Bandwidth saved by RSScache.com

Assuring Party @ DebConf8, Argentina.

Dererk — Wed, 13 Aug 2008 12:21:08 +0000

A new CAcert Assuring Party will take place at DebConf8 in Mar del Plata,  Argentina, right next to the Keysigning Party[1], during this Thursday.
To obtain assurance at the event, login to the CAcert site and click the "CAcert Web of Trust" menu, and then click on one of the WoT forms.

Print that form out, verify that it has complete and accurate information, bring it and 2 forms of government issued photo identification (one will be accepted, but two are preferred in case of document validity doubts). Please also read over the following pages:
http://wiki.cacert.org/wiki/FAQ/AssuranceIntroduction and http://wiki.cacert.org/wiki/FAQ/AssuranceByCAP.

There are some printers you can use to print forms at DebConf FrontDesk on the ground floor of the "Hotel Dora".

See you in there!

Bandwidth saved by RSScache.com

Barcamp Stuttgart mit CAcert Assurances

wonderer — Tue, 29 Jul 2008 08:24:02 +0000

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

Bandwidth saved by RSScache.com

Assurance Policy now in DRAFT

iang — Fri, 25 Jul 2008 01:09:07 +0000

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:

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

Bandwidth saved by RSScache.com