What has to be the biggest black eye for the US banking industry in recent times had nothing to do with phishing attempts, it didn’t have anything to do with intercepting and brute forcing SSL packets, and it didn’t have to do with any root keys escaping into the wild.

What it does have to do with is a shady person talking high level bank employees into stealing the details of the banks customers and to go on and hassle people based on false collection claims, not to mention potential identity theft attacks as well.

Full story can be read on the CNN website.

While our progress with the Mozilla Foundation is currently (and has always been for that matter) been in go slow mode we have been making progress on other fronts. Of late a number of distributions have either included us (such as Knoppix) or are putting considerable thought into including us (such as Ubuntu), with Debian the latest distribution to include us.

While this may not seem like much to the nay sayers (I still get told no one will ever use CAcert because it’s not included, which I think is strange), it shows that we are getting more widely accepted and more to the point, gaining credability.

I’m pleased to announce that we finally worked out the correct way to not only issue certificate requests with subjectAltName (SAN) extensions, but have certificates issued with the correct SAN extensions and this is important for a number of reasons. The reason it took so long to actually get this implemented correctly was due to the poor and misleading documentation for OpenSSL on the topic, as well as the fact that the proper extension in the RFC is dNSName and OpenSSL implemented it in configuration as DNS instead.

It would seem at first glance both MSIE and Firefox both support SANs correctly, so this means you can have multiple host names, even from completely separate domains and it will simply just work. We’re still working on setting up hosts for a full compliment of browser testing, but you’d have to assume other browsers for the most part should also support this feature.

The other thing of note is multiple commonNames are ignored on certificates, only the first one is accepted and used, so if you want to do anything other then wild cards, this is a tad limiting. Someone also sent me a short perl script that can be used to easily generate valid certificate requests with SAN extensions. I’m also contemplating ignoring multiple commonNames and just issuing certificates for the primary commonName, the commonName is ignored if any valid SAN extensions are on the certificate are present, so if you want to include the host you also have in the commonName this has to be also listed as a SAN (and I’m sure this will catch a few people out).

While this is useful for a single website with SSL, we’re not sure if apache or other server software will allow multiple vhost entries to share the same certificate and do all the handshaking properly, and neither apache nor mozilla browsers implement/use the TLS handshaking ability to utilise multiple certificates from multiple vhost entries. It’s also highly useful for mail servers that are known by multiple host names, such as having an interface on the inside of a corporate network, and also having an external interface.

We’ll keep our wiki page on this up to date as we learn more, or as new code gets added to browsers etc…

Do you know of an event coming up where assurers will be present? If so please let us know so we can add entries to this blog, currently all known events have been added to the database and on the right hand side of the site there is an events calendar which can be used to find events in the future that you can attend and be assured at.

There is also an ics/vCalendar file of the events (dynamically generated) you can download and load into your favourite program: http://blog.cacert.org/calendar.ics

It’s preferable if you are going to be at an event to list a contact address as many people haven’t managed to make contact with assurers in the past, which can be quite frustrating to say the least.

Currently as many of you know there is some issues with our current system, and one big way to over come the entire problem is to have as many people with 50 or more points in the system, to us it would be beneficial to have everyone with 100 or more, but for the most part 50 would satisfy most of the current issues people have with including our root cert.

Step one is to raise awareness of the situation, and this will be executed via a mass mail of all unassured people in the CAcert database, the notification will be along the lines that we have been given indications that we could be better included in Ubuntu, and perhaps many other linux distributions if we stop issuing unassured server certificates. If everyone is serious about us being included in browsers and given the opportunity to be assured (via a distributed world tour?) no one should have a problem with this in theory (and everything works in theory).

Step two will be to actually get people out and about, and assuring people en mass. While CAcert doesn’t have unlimited amounts of funding, CAcert is a cash positive, self sustaining entity which gains funds from donations, memberships and google ads displayed on the website. Utilising these funds or gaining further donations to tip the balance of assurers in areas should be something considered a high priority.

Step three of course is phasing out the ability for people with less then 50 points from being issued a server certificate from our main root certificate, if at all. This was one of the original goals, while we don’t yet have any sort of critical mass, this has brought the issue to the forefront and will only serve to increase the overall security of the system, not to mention that this will also gain us a lot more credibility and will be one less barrier to inclusion.

I’m sure there is other things we will need to do, and as always feedback is appreciated.

I’ve spoken to some very influencal people of late, one of whom happened to be Mark Shuttleworth today at the Ubuntu down under conference. He had one particular concern about control of domain certificates, and that he didn’t feel comfortable including our current root certificate at present until we either stopped issuing them under our present root (ie setup another root certificate for assured certificates, or start issuing unassured certificates from a new root), or alternatively we can just not issue them to unassured people.

Also worth mentioning that at one point webtrust certification was mentioned but he wasn’t really that concerned about it, he was more worried about the security (or insecurity) of control of domain type certificates.

This isn’t the first time that it’s been suggested that we alter how many root certs we operate and under what conditions people are allowed to issue from which certificate, at this point in time it’s a difficult decision to make and we’re looking to the community for feedback on the issue (as this will effect a lot of people no matter what happens) and what the best course of action to take is.

Comments on this are important!

* one possible solution might be to issue a new root cert signed by the current root cert (since this issue only effects server certificates) that way it should work with least amount of impact to most/all people.