Peeling the onion - how many layers should your PKI have?

  • Article

I‘ve been talking to a colleague who insists a 1-tier PKI infrastructure is better than a 2-tier PKI infrastructure but without providing details on exactly why.
Is it better?

 The word „Better“ is fairly meaningless as a quantitative descriptor.  If you‘re talking to someone that uses that word when describing an IT-related subject it probably means that it‘s a question of belief and preference rather than a matter of logic and factual evidence.

Easier to deploy and simpler to manage, yes – Better, no.

The answer to the 1-tier vs. 2-tier question for PKI deployments is entirely dependant on what you intend to do with the PKI environment and, more importantly, the requirements of other organizations that you want to establish a certificate relationship with.

For example; most military or financial institutions that you want to establish a certificate trust with will typically dictate security requirements that you must fulfil in order for them to start considering whether they can trust you (and this will typically include a requirement for the Root CA to be offline while the issuing CA‘s can be online.

The general rule of thumb is that you should not spend more money on protecting assets than what they are worth.  However, this cost can include goodwill, privacy concerns, prestige and loss of reputation from a breach so even if you‘re not protecting an asset that has a high value in itself the secondary value needs to be considered in the equation.

The primary reason for deploying an offline root CA is typically to minimize the attack surface of it and simplify revocation in case of a breach as distributing a CRL for a revoked issuing CA to all affected workstations requires less work and takes less time than removing a trusted Root CA certificate from the clients (especially for unmanaged clients that you don't have direct control of). 

A secondary reason for a 2-tier deployment is to be able to revoke the issuing CA certificate without needing to redeploy the trusted root certificate which would be necessary for a 1-tier online issuing root CA.

Additionally, if you have no management control over the clients you cannot remove a breached Root CA certificate from them whereas revoking a SubCA certificate will be subject to normal revocation checking and will be picked up by the clients the next time they download your CRL (or OCSP response) without you being involved.

Policy requirements and company politics can also come into play for the design decisions, for example if you have several different departments that must be able to manage their own issuing CA servers then the overhead of distributing and managing multiple trusted Root CA certificates is higher than having one Root CA that all issuing CA‘s chain up to.

In short; there are pros and cons for both 1-tier and 2-tier PKI infrastructures, you need to start any PKI project by evaluating what your needs are and what your budget is before you decide on a 1-tier or a 2-tier deployment (or a 3-tier for that matter).  Just make sure you don't let anyone tell you one is always better than the other, that is simply not the case.

 

For a second opinion from non-Microsoft sources, please consult the following non-Microsoft sites:

Hierarchies in PKI
http://networklore.com/hierarchies-in-pki/

 

3.4.1 PKI Certificate
Hierarchy Recommendations for ICCP Networks Each certification hierarchy has
its advantages and disadvantages, and each network is different. See section 1,

http://energy.gov/sites/prod/files/oeprod/DocumentsandMedia/19-Secure_ICCP_Integration.pdf

From page 88:

 

[1-Tier]

This centralized approach has several strengths and weaknesses:

Strengths

  • • Certificates are managed by one central site, relieves burden from
    individual companies
  • • A node needs to send only its own certificate in the handshake
  • • CRLs are simpler and valid across the system
  • • CRLs are managed at one central site
  • • Simplicity; getting PKI services is very straightforward

Weaknesses

  • • Does not scale to large networks (500+ nodes)
  • • Centralized solution provides a single point of failure
  • • “One size fits all” model of security for all nodes across
    different companies. Changes to the security policy must be more formal and
    restrictive since they affect all nodes.
  • • Companies must trust the single CA to manage everyone fairly
  • • Single node responsible for CRLs can experience heavy load
  • • The process of adding a node to the CRL can be complicated

As networks grow larger, the flat PKI structure becomes difficult
for a single entity to manage and service. Furthermore, either out of
convenience or distrust, organizations may prefer to manage their own PKI nodes
themselves. To satisfy these issues, a tiered PKI hierarchy can be implemented.

[2-tier]

Strengths

  • • Scales very well for larger networks. There can be multiple tiers
    of CAs between the root CA and the end node.
  • • Each company can independently manage its own nodes
  • • There is much less stress on the single root CA
  • • The burden of circulating the CRL is no longer on a single node
  • • A failure or compromise at a company’s CA will only affect that
    company’s nodes

Weaknesses

  • • Complexity. This scenario is slightly more complex. The company
    CAs must occasionally have their certificates updated, which in turn must be
    distributed to all the nodes.
  • • There are multiple CAs that must be secured from failure and
    attack
  • • Each company must maintain its own CRL and distribute
    certificates.
  • • Multiple certificates must be passed to provide proper
    authentication
  • • Lower-tiered CAs must have
    reachback to the primary “root” CA.