Prompted by Steve's request for an SSL cert, i'm going to air some grievances i have with the X.509 PKI that tends to go along with SSL and TLS. The current real-world X.509/TLS infrastructure gets in the way of real trusted, secure communication. It favors the creation of opaque, commercialized certificate authorities which are answerable to no one and have incentives to behave in un-trustworthy ways.

A small change in infrastructure to allow multiple signatures in each certificate could move us in the direction of more trustworthy, reliable digital communication. User education about digital trust would help too, of course, but i'm not naive enough to think that'll happen soon.

Let me start with the underlying technical/social problem of single-signer certification:

• TLS negotiation, as i read it, provides no way to to offer multiple X.509v3 certificates for the server (the chained certificates mentioned in section 7.4.2 are for the purposes of connecting the server's certificate to a single root authority, which is not the same thing). Clients can offer multiple certificates, however, but this doesn't solve the problem for servers (and client-side certs are still rarely used!)
• X.509v3 certificates, from what i can tell, offer no way to include multiple signatures in a single certificate.
• Given the above two limitations, i see no way for a server offering TLS or SSL communications to provide a set of possible alternative certifying signatures. This means that all clients connecting to the server will need to ultimately trust the same root certificate authority.
• Since an administrator must pick a single CA (and assuming they want to provide automated authentication for as many clients as possible), sie will most likely pick CAs with a higher pre-trusted client base (e.g. those distributed with the major browsers). If there were ways to provide additional signatures, a site's administrator could request certification from multiple authorities, and satisfy users who trust any of them.
• Since servers tend towards the big CAs, there is little incentive for clients to investigate or adopt any of the smaller CAs, even though the smaller CAs may in fact be more trustworthy (e.g. provide better investigation of identity prior to granting a certificate, or not have financial incentives to grant as many certs as possible). So for most users, sites which are certified by a smaller authority will appear broken, which further reinforces the dominance of the existing big CAs.

All of this could potentially be mitigated if we could have multiple signatures in a single certificate. Then end users could approach certification from something approaching a GPG-style web-of-trust model. As a client, i might trust CAs A, B, and C, but not D, E, and F. If you run a server, you can get yourself certified by any or all of those certificate authorities. I won't care if you've been certified by D, E, and F, of course, but there may be some folks who prefer those authorities.

But wait! There's a solution on the horizon: an internet draft proposes a solution for this, using OpenPGP certificates (which can have multiple signatures) instead of X.509 certificates. It even provides a bandwidth-saving technique whereby the OpenPGP fingerprint is the only thing transmitted, and the client can assess the presence or absence of the key from a keyserver or a local cache.

I'm not sure what needs to be done to get this pushed out of draft status and into the standards track, but i'd like to see it happen. it's languished in draft state for years so far, though. Modification of various bits of software would be needed, probably starting with popular web browsers and web servers. apache and mozilla foundations, i'm looking at you! GnuTLS already has experimental support for this feature, but doesn't have the reach of OpenSSL. Developers whose software can use GnuTLS could get this feature for free, though!

If support for this new model becomes widespread, it could be used to attack a major underlying social/economic problem:

• The current financing models used by the major commercial CAs appear to be pay us money, we'll give you a certificate. There is no incentive in this model for any of the CAs to do any actual verification of identity for the certification. In fact, their incentives go in the opposite direction.
• Even if the CAs were to move to the model of pay us money, we'll evaluate you, and then maybe you'll get a certificate or not; but we'll keep your money either way, there would still be significant pressure to grant certification: a CA who takes an administrator's money and then provides no certificate would probably get very noisy bad press, given the poor state of understanding about certification.

If we had a multi-signature scheme widely available for TLS certificates (using OpenPGP certs or any other approach), someone could create a certificate authority with a totally different financing model. Rather than having the certified entities pay for their own certification, the CA could be funded by users who want a strict level of trust, perhaps by defining a rigorous set of tests or procedures.

These new-model CAs would then, on behalf of their clients, seek out and certify entities their clients care about. Want to set up an account with a local bank, but their web server is not certified by your trusted CA? Ask your CA to check them out using the procedures you've established. If the verification procedures are passed, certification could be granted by signing the relevant public key and publishing it to public OpenPGP keyservers directly.

Let the old-school CAs continue to operate in the meantime, using the X.509 infrastructure. New-model clients could prefer OpenPGP keys if present, and TLS-equipped servers could record the number of OpenPGP-preferring clients accessing the site. An administrator who wants to make the switch simply publishes an OpenPGP key, uses a self-signed X.509 cert as a fallback (or gets it signed by an old-model CA), and is responsive to requests by new-model CAs to verify identity.

This will all take years, of course, if it ever happens at all... And in the meantime, other strategies are being attempted, some of them by the same old corrupt players, and others by more open folks.

• Extended Validation (EV) TLS certificates are apparently being introduced shortly. EV Certs appear to mean no, really, we really did verify this!, which is what the Certificate Authorities were supposed to be doing in the first place! gah...

  If this was one more option in a wide range of possible, pluralistic certificate authorities, i'd welcome its creation. But since it doesn't question the single-signature-per-certificate brokenness of X.509, it looks like it's just going to become another lever for the concentration of power in this arena.

• CAcert.org is another name that gets mentioned a lot when dissatisfaction with the commercial TLS cert vendors comes up. They have an interesting approach towards dealing with the lack of good web-of-trust infrastructure in X.509.

  But you still need to trust CAcert to adhere to their published model, and to not leave any security gaps in their implementation. Additionally, you might not agree with some of their criteria, or feel that they've missed a key procedural check that you need. Again, their approach is welcome, but i'd prefer it if there were multiple groups offering these kind of approaches who could certify side-by-side, so they would have to compete with one another legitimately.

---

Of course, it's possible that i've missed something in the RFCs and in experimenting with TLS libraries, and we really can provide multiple X.509 certs for the server in a TLS transaction, or multiple signatures in a single X.509 cert. If so, please point it out! i'd love to know.

Since this rant is already way too long, i'm saving a couple of other TLS frustrations for later weblog posts. When i get around to them, i'll edit this to link to them.