Trust, as it pertains to most components within a Public Key Infrastruture (PKI) is earned. It’s established as the result of some sort of evaluation. An evaluation that often involves a revocation check or policy check.
In the case of the root CA however, trust is *not* earned. In the case of the root CA, trust is assigned. This assigned trust is quite often mandatory from the perspective of subscribers and relying parties.
It is for this reason, that when considering the creation of a new root CA, it’s imperative to do so in a manner that is well understood, well documented and well executed.
The resulting root CA’s security story should be beyond reproach, and capable for all assurance levels that may ultimately chain to this new root. It is this story that is ultimately the basis for any assigned trust.
However, in order to effectively tell this security story, it is often necessary to create a series of formal documents, one of which is called a root CA key signing ceremony document. This a document that outlines and governs the key creation process for a new root CA. It is this initial process that creates the root CA’s key pair that the entire PKI will ultimately chain to. Putting this another way, a PKI’s trust starts with the root CA and the processes used to create it.
For this reason, it is not uncommon to require the presence of multiple parties, such as audit, legal, operations, and witnesses to view this process. These participants provide an affidavit that all established practices were followed, and that any trust in the root is indeed warranted.
Without a doubt, the root key ceremony is an important part of the creation of a new PKI. This blog will detail the top five root key ceremony mistakes that I typically encounter when evaluating customer PKIs.
- Chain of custody
When creating a root CA key pair, it is imperative that compensating controls are established and implemented throughout the entire process. This means always knowing who has control and access to those keys, including during the build process.
It does little good to create a comprehensive multi-part access plan to the root CA private keys, if after they are created, the root CA is left out unattended in the conference room during a lunch break.
It is critical to the PKI’s trustworthiness story to be able to legitimately claim that all established controls have always been used, throughout the entire life of the keys. Including the day of creation.
It’s imperative to maintain a credible chain of custody, with the private keys continually protected by all applicable controls.
The role of audit is to provide notarization to the process. These are the folks that theoretically have no vested interest in the PKI, other than to sign off on whether or not the established processes were followed.
Audit’s attestation of adherence to well-known process during key creation is integral to establishing foundational trust in any PKI.
Not having an audit component to a root key ceremony means that relying parties must just trust that you did the right things. Depending on the assurance levels you intend to deliver with the resulting certificates that is often not good enough.
An independent auditor should always be present during all parts of the root key ceremony.
A root key ceremony is necessarily a group event. An event that may take a few hours or a day.
It is not uncommon that intended assurance goals of the resulting PKI mandate the presence of a process owner (master of ceremonies), an audit team, legal team, compliance officers, key holders and operational staff, including executive witnesses.
All of this is designed to eliminate any possible claim that the root CA keys have been mishandled and that from their inception, the root CA’s keys have been created and maintained in a manner that is compliant with all expectations.
Noting this, you can see that it does little good to merely task the AD guy with standing up a new root CA, to do so in a room all alone. Who would trust that?
Participation during root key ceremonies should be sufficient to support the assurance levels claimed by the PKI. This will often mean operational staff, legal, audit and compliance.
After the root CA’s keys have been generated, it’s often important to keep several remnants of the root key ceremony process. These records form the permanent record describing why trust in a given PKI is warranted (at least for the purposes intended).
Given the lifespan of most root CAs, it’s entirely conceivable and appropriate that the trust in any given root CA be periodically reviewed. This can only happen if there is sufficient material to evaluate.
These artifacts are commonly in the form of root CA key signing ceremony document. This document is step by step record of exactly what transpired during the process, and is often signed off line-by-line by a member of the audit team.
The entire document is then signed and notarized by all involved. It’s also not uncommon whatsoever to video record the entire event.
The point here is that this provides a permanent record of what took place, and ultimately why trust is warranted.
It does little good to follow a well thought out process, complete with participation and audit, if in the end, there is no record of it.
Always preserve the root CA key signing ceremony documentation.
The number one mistake made during a root key ceremony is putting the offline root CA online. The whole point of the root CA being offline (and off), is that the airgap allows the root to be immune from those common threats associated with being online.
This maximizes the assurance that this CA has not been made to maliciously sign anything, and this CA has only ever been operated using normal and established processes.
The last thing that anyone wants to hear during a root key ceremony is “Ok, I’ve patched the root CA server and it’s now disconnected.”
I often say that there is no 5-second rule when it comes to the Internet. Once you connect, you are online, and there is no walking that back.
Time to re-build if that occurs.
Certainly there are other common mistakes made during a root key ceremony, but this was just meant to be a quick list of five things that when avoided, are sure to make your root CA a lot more credible in its claim to being secure.