It has been a little bit over  a week since VASCO announced the breach discovered on 19 July at Diginotar,resulted in fraudulent certificates being issued.  Apple, Microsoft, Mozilla, Adobe and others have pushed out updates revoking Diginotar certificates (except in the Netherlands). Looking at the press release this line caught my eye

"VASCO does not expect that the DigiNotar security incident will have a significant impact on the company’s future revenue or business plans"
http://www.vasco.com/company/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx

That got me thinking, and during several virtual water cooler chats we discussed the potential impact of this breach.  However before we get to that we need to understand a little bit more of the true nature of Public Key Infrastructure (PKI) and the role the various certificate authorities play in it. You see in PKI it is all about trust.

We know certificates can be used for all kinds of purposes and many organisation will set up their own internal Certification Authority (CA) and start issuing certificates that can only be used internally. If used externally they will pop up as errors, invalid certificate. For certificates to be trusted by everyone, you need one that has been issued by a recognised certification authority such as Thawte, Verisign, Godaddy, Digicert, Diginotar, or others. Once they have signed a certificate you trust it, because …? We will get back to that in a minute, first we need a little bit more CA 101.

A typical CA will have a root CA which is used to sign the certificates for one or more intermediate CAs. The root CA is then often taken offline to protect the private key of the root Certificate.  The intermediate CAs are then used to sign further CAs or are used to start issuing certificates to customers for their web servers, email and so on. When you need a certificate for a web server a public/private key pair is generated. A certificate request is sent to one of the intermediate CAs. The CA creates and signs a certificate using its own private key and sends the certificate back.  Voila, you now have a certificate for your SSL site and browsers will no longer complain about the validity of the certificate.  However that is just the technical side, where does the trust come into it?

The trust we as user have, is in the processes and procedures that a CA has in place to ensure that the request for a certificate and the information in the certificate request is accurate. In other words checking that the person asking for the certificate is not lying. That is where a large part of trust comes from. The rest comes from having confidence that the organisation has the security controls in place to ensure the integrity of the process. Or in other words, fraudulent certificates cannot be issued and the private keys of the CAs are safe. The robustness of the process determines the level of trust and for us the price. A certificate costing $20, probably only needs a valid email address. One costing $1700 will typically have many more checks performed before issuing a certificate. Unfortunately for us security professionals most users won't know the difference between the two.

The onus however is not only on the CAs. CAs have to publish certificate revocation lists (CRL), usually on a url starting with crl, e.g. crl.verisign.com, or Online Certificate Status Protocol (OCSP). These lists contain those certificates that are no longer valid and should not be trusted. Applications using certificates (e.g. when using SSL) are expected to check the revocation list or send a OCSP query to verify that a web server's certificate is still valid. It is however up to the application, so we are trusting the various vendors that they will check. Browsers will typically send a OCSP request, but if they can't reach then the CRL is used. Other applications may do something different.

Trust in certificates rests on trusting the entity issuing the certificate and trusting that they have the protection and processes to maintain the integrity and therefore maintain our trust.  That is a lot of trust, something in my opinion, Diginotar and to some extent other CAs have lost. Governments typically do not get involved in the CAs business (unless the certificates are issued on the governments behalf). There is as far as I am aware no requirement for CAs to demonstrate the robustness of their processes or the security of their systems. Maybe they should?  Mozilla has called for a review http://news.cnet.com/8301-27080_3-20103615-245/mozilla-gets-tough-after-digital-certificates-hack/ or at least some assurance from the CAs who have certificates in the Mozilla certificate stores.

As for VASCO's statement, from what I can see the trust is gone and that is what Diginotar is selling, but I guess we will have to see.

Mark