Quality of Certificates

Do not confuse the general quality of X509 digital certificates with the Qualified certificates that can be issued in the European Union (EU) for the purpose of using an electronic signature in place of a written one (under the Electronic Signatures Directive 1999/93/EC as incorporated into UK legislation). However, these Qualified certificates suffer from all the same problems (highlighted here by the Electronic Frontier Foundation [EFF]) as other certificates. The implication of issuing such Qualified certificates is that they are inherently of quality and as such can be trusted.

If quality implies trust, then it is instructive to consider one such issuer of Qualified certificates: the Royal Bank of Scotland (RBS), which almost went into bankruptcy during the Financial crisis of 2007 and 2008 and was only saved by being taken into public ownership (that is owned by the British Taxpayer). The situation here is even more ironic. A bank has customers and if the bank only issues digital certificates to its customers and not to the public, then according to Mr Richard Schlecter (DG XIII, European Commission and speaking at the Joint OECD-Private Sector Workshop on Electronic Authentication on 2-4 June 1999 at Menlo Park California), its customers constitute a closed user group and the certificates that the bank issues are not subject to the EU directive. This would appear to be a worse regulatory situation than the light touch regulation which contributed to RBS almost going bankrupt during the Financial crisis. For the actual text see the third to last paragraph on page 19 of this link. To recap: An organization which can claim to have a closed user group and issues Qualified certificates only to that group is not bound by the legislation that applies to those certificates as long as the person accepting such a certificate agrees to abide by the terms and conditions set by that organization. This potentially negates much of the quality and trustworthiness of the certificate.

The AllIncontext view is that the actual Quality of a given digital certificate depends not only on how it was created (and the data used in its creation), but on the quality of the rest of the certificates in the chain going from the certificate in question up to the Root certificate. The problems highlighted in the EFF link above mean that a certificate chain might contain certificates which were issued:

• By different Certificate Authorities (CA's) or organizations in different parts of the world.
• With different Signature Algorithms, some of which are not recommended today as best practice.
• With different Key lengths, some of which are not recommended today as best practice.
• With no limit on the number of CA's which can be in the chain, which opens the chain up to attack by allowing bogus CA's to be inserted in the chain.
• Without specific Key usage and Extended key usage set as critical (or usage not set at all). These settings define what a certificate can and cannot be used for.

This is why AllIncontext issues its own digital certificates and certificate chain in order to have full control over the process and ensure that our certificates conform with current best practice (see the Note at the bottom of this page). It is also important to remember that a certificate: Only represents an identity, much like a Driving Licence or a Passport; Has an effective zero value because it only binds to an identity (the difficulties arise when you expect a certificate to be more, such as a qualified certificate).

If you are browsing a secure web page (the URL starts with https:// and the padlock icon is displayed to the bottom right of the browser window) you can click (or double click) on the padlock to open the web site's current SSL certificate. The certificate (or Page Info) window should open. In IE click on the details tab. In Firefox click on View Certificate, then click on the Details tab. In either case look for the major items:

• Signature Algorithm. For RSA, this should be SHA1 or SHA512, not MD5.
• Public Key/Key length or Subject's Public Key. For RSA, this should be a minimum of 2048 bits. 4096 or higher is preferred.
• Subject. Does the information well define who the certificate is issued to. For example, you would expect to see a Common Name (CN) which is recognizable such as www.allincontext.com; an Organization Name (O) such as AllIncontext Limited; a Location (L) such as Petersfield; a State (S) [although in countries other than the US, this will be a County or Region] such as Hampshire; a Country (C) such as GB.

If you have a Windows Certificate opened, you can click on the Certification Path tab. This shows you the certificate chain. The certificate at the top is the Root certificate. If there are two or more certificates below it, do the following:

• Click on the one below the Root. The View Certificate button should become enabled.
• Click on it to open the certificate at that level in the chain.
• Click on the Details tab.
• Look at the Basic Constraints item. For a CA certificate this should say Path Length Constraint=0 for maximum safety. The 0 means that NO other CA certificates can be in the chain below the current one, only End entity certificates (such as your personal Email certificate). If you see Path Length Contraint=None it means that any number of CA's can be in the chain below the current one.

You can look at all Windows Store certificates by running Certmgr.msc from the Start menu. In XP, click on Run and type in Certmgr.msc and press the Enter key. In Vista and later, type this same string into the Search edit box and then click on the first matching item at the top of the menu (this does assume you have the necessary privilege to open the Certificates window). When the Certificates window opens, you can use the treeview in the left-hand pane to select the specific store you want, and click on any certificate item displayed in the right-hand pane to open that certificate's window. Then using what has been given above, you can make a judgement of the quality of the certificate and its binding to the Subject.

Note1: Best Practice for digital certificates is difficult to pin down because such standards as exist allow for flexibility in what should and should not be done. AllIncontext does what seems sensible to us, as demonstrated in the points given above. PKIX is one of the bodies set up by the Internet Engineering Taskforce (IETF) and it has a charter to develop Internet Standards to support X509 Public key Infrastructures (PKI's). If you look down the list of what has been done and what remains still to be done, you will see that many of these standards have a draft status which has persisted for a number of years. This creates uncertainty and you tend to find people ignoring what a draft standard recommends. In a previous incarnation, the general manager of AllIncontext worked with the members of an ISO standards committee and can confirm that a prolonged draft status is not an ideal situation.

Note2: Peter Gutmann, a computer scientist at the University of Auckland, has been involved with PKI for some time and you might like to dip into his X509 Style Guide which is written in a whimsical way (and dated Oct 2000). A more recent publication is PKI, Lemon Markets and Lemonade presented at the 2011 RSA Conference in which a totally bogus X509 Digital Certificate is accepted by both Internet Explorer and Mozilla Firefox, albeit with trust related book-keeping issues, and by both Windows and OpenSSL. Remember that this scenario is related to using Digital Certificates for encrypting browser connections over SSL where the concept of trust has no discernable metric.