Monthly Archives: September 2008

Rehosting: Last preparations

* Preperation day CRday banner

Yesterday, 26th of September, The website was down for a brief period around 7PM CET.
An extra disk was added to the server for backup purposes.
The final backup will be made on monday around 7PM CET.

This is the first blog entry where CAcert informs the users on the progress of the rehosting of the critical servers.

CAcert Server transfer and downtime.

cr-day_banner1.jpg

As you may have read in previous blog entries, CAcert are moving the last servers from Austria to the Netherlands. These servers are the mission-critical systems. This is done to comply fully with the very strict security rules that are in place for inclusion into mainstream browsers. The Netherlands location is planned to host the servers in a full dual control and 4 eyes environment, at both physical and logical levels. As an audit requirement, this is essential for balancing the security of certificates. Also, some internal protocols will have to change due to hardware issues.

The systems will have a short shut down on Friday evening, 26th at 19:00 for a brief period for backups. The servers will be shut down from 07:30 Tuesday morning, 30th September. We have blocked-out the period September 30 to October 4 for the project. Hopefully, we will not be down for that entire time, but because of the size of the project it is best to plan on at least 2 days downtime. During the downtime, an alternative page and the blog will show the progress on the moving. The blog, e-mail list and wiki will be available since they are already hosted at the new location in the Netherlands. During the downtime, no Account changes can be made, nor new Certificates or Assurer actions can be done. Please be aware of that downtime period. CAcert will inform all Members via the blog as soon as the Services are again up and running. More details are found on the wiki.

An international team of experts will be working on this relocation project. As well as our CAcert systems people, we will be supported in the Netherlands by people from BIT (ISP), Tunix (firewalls) and Oophaga (CAcert hosting in NL). In Austria, we will be supported by Funkfeuer (ISP) and Sonance (Verein). Should any problem arise during the move, the team will tackle them there and then.

If the servers are moved succesfully, we will be back on track with the audit and CAcert can move on. If CAcert does not relocate the servers, or fails to do so, it will have severe consequencies for CAcert. In such a case the chance to pass the audit and ability to achieve RootKey inclusion in the mainstream browsers will fail. The Austrian servers will be shut down permanently.

At the Annual General Meeting of CAcert Inc. on 7th of November, a report will be made to the Association Members and if needed decisions for the future will be taken.

update:

The Backup date will be on Monday, 29th (19h CET).

PGP Keysigning und CAcert Assurance Event 2008 in Esslingen am Neckar

Am Freitag den 24.10.2008 findet das zweite PGP Keysigning und CAcert Assurance Event der Hochschule Esslingen (Fakultät: Informationstechnik) statt. Wir laden alle Intressierten herzlich ein. Alle Informationen auf der angegebenen Hochschulseite und in aller kürze hier:Datum – Freitag, 24.10.2008
Zeit – ab 19 Uhr
Ort –
Hochschule Esslingen, Flandernstr. 101
VeranstalterHochschule Esslingen
Anmeldung/Info – http://www.hs-esslingen.de/de/42537
OrganisatorFabian Fingerle

Anmeldung (bis 21.10.2008) ist keine Pflicht aber zumindest für PGP eine enorme Erleichterung.

Wir freuen uns über euere zahlreichen Anmeldungen!

AR.20080902.A1 CPS issues: 2 bugs

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

  1. always Assured?
  2. always strong through some other mechanism, either Assurance or elsewise?
  3. sometimes be Assured, sometimes unknown, like now?
  4. 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.

Audit Report 20080802

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:

  1. The new plan for critical systems is now in place and approved by Board of CAcert.
  2. 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.
  3. The data will be incorporated into the Netherlands machines over the days following that date.
  4. So, service to CAcert will be interrupted from 30th September.
  5. 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.
  6. Which means, if the migration does not succeed, then CAcert may be left without an operating CA.
  7. 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:

  1. 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.
  2. 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.)
  3. 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.
  4. 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.
  5. 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!
  6. 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!