3

When you look at currently used concept of Root CA (primarily in SSL/TLS context), you can see a single-point-of-failure vulnerability, which means, if your private key is disclosed, you automatically lose whole chain.

Current State of Trust Chain topology
CA trust chain

Means, you start with one self signed certificate, declared as Root CA Certificate (see http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/x160.html ), which then signs other certificates (not necessarily intermediate)

Disclosing private key for Root CA Certificate, will force you to revoke whole chain.

Possible Ring topology
Ring CA topology

I think about topology, where you have both-way signed certificates, where each CA is signed by at least two others. This could boost some security params of certificates, such as

  • compromising single CA will not mean revokation of whole chain (compromising CA_1 won't remove whole chain of neither CA_2 or CA_3)
  • creating fake CA will require you to fake at least two of them, so you can create valid chain

So the questions are:

  • What led creators of public key certificates to use SPoF vulnerable chain?
  • Is there anything, I'm missing on ring topology?
2

All root CAs are self-signed. Which means we feel forced to implicitly trust that the CA is operated responsibly and securely. This isn't always the case (Diginotar).

There are alternatives to the certificate authority method. One of these is the web of trust, which is used mainly in PGP / GPG / OpenPGP implementations.

There are situations that can arise in PKI implementations where we need one PKI to "trust" another. This is called cross-signing or cross certification.

One of the key components of a PKI is an LDAP directory service. This is where signed certificates and revocation information are published to be publicly available. The directory takes the form of a tree structure. Each entry in the tree forms part of the entry's distinguished name (DName). An example being CN=NRC, OU=IT, O=MyOrg, C=GB. In this DName the root element is C, which is a country, followed by O, for organisation, OU, org unit and CN, which is common name. Each DName element is an entry in the directory tree, which has a specific schema object class. The object class defines the mandatory and optional attributes for an entry. The CN element is usually represented in LDAP terms by the schema object class called inetorgperson, however specialized types have been developed for PKI purposes. The full LDAP schema for PKI objects is defined here.

Included in this is the definition of the PKI CA Object Class. This includes the crossCertificatePair Attribute. Using this attribute extra certificates for the CA can be issued by another CA (as in your diagram). This means, although the core CA certificate is self-signed, for cross-certification purposes its trust anchor is another root CA. Indeed, if RootCA1 signs a cross certification certificate for RootCA2, then RootCA2 may also sign a cross certification certificate for RootCA1. Indeed, as you have specified in your question, it is possible through cross certification to have the ring situation, where RootCA1 signs RootCA2, RootCA2 signs RootCA3 and RootCA3 signs RootCA1. Validation of cross certified CAs requires that the validation process look up cross certified certificates in the LDAP entry for the CA, because there is no reference to these in the Root CA certificate (the self-signed "core" certificate), although there should be a reference to the LDAP entry for the CA in the Subject Information Access extension.

When taking into account cross certification, certificate path validation can become an incredibly complex process. However, specialized software services have been developed which allow users to "outsource" the complex process to trusted validation authorities. These services are called online certificate status protocol and server-based certificate validation protocol servers. The Axway VA is a server which includes both OCSP and SCVP in one and can be configured to provide full certificate path validation in cross certified CA environments.

3

I can think of many reasons. The first one, is economical. Effectively, getting a certification is costly, and the higher you are on the chain, the more expensive it gets. Using, what you propose might theoritically be interesting, but it will cost twice as much to companies (don't forget, CA are economical entities that sell their services, they won't do it for free). Some studies have pushed your solution further and have proposed even P2P certification, here is one paper that talks about it. However, the problem with distributed certification (in opposition to centralized) is the difficulty to control and establish normes and rules.

Finally, if we look at the solution you propose i can see some inherent problems in it. At least, in the way you present it there is no hierarchy CA-3 is certifiyng CA-1 and vice versa, but clearly one has to be a higher authority and that one can't be certified by a lower authority.

  • Paper about P2P certificate trust is something similar to what I got in mind, it's not about higher authority, but increasing security and stability of trust web. Thanks – Marek Sebera Mar 25 '14 at 16:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.