Why are we talking about assurance?
‘Assurance’ in the realm of PKI, tends to be one of those topics that is almost guaranteed to send a PKI design meeting down a rabbit hole. And unfortunately, many customers prefer the blue pill, rather than committing to an effort commensurate with a rigorous examination of risk, impact and assurance in the certificate space.
Frankly, I don’t blame them. The reality is that most people simply need certificates to “just work.” That is, folks need to check the box confirming that some vestige of certificate-based authentication is currently in use within their environment. Typically this is in response to a compliance audit – which is most certainly understandable.
But what good is a certificate without any assurance? If a certificate is unable to articulate how much trust it should be afforded, or how it is to be used, or (perhaps more importantly) how it should not be used, then exactly how useful is that certificate?
Certificates are meaningless without policy
I often tell customers, certificates that fail to convey policy offer application owners and relying parties no opportunity to discern what a given certificate should be capable of authenticating or how it should be used. Should, for example, any user certificate be used for non-repudiation purposes? Most would say no, but making the case for which certificates should be used for non-repudiation purposes would most definitely include a certificate policy conversation. And that is where things start to get sticky.
I consider any certificate that is devoid of policy to be a certificate that is incapable of conveying a specific level of assurance. But designating an assurance level is more than just an arbitrary moniker. Specifying assurance levels is more akin to telling a story. Telling that trustworthiness and assurance story is a job that falls to the PKI architect. This is a story that is articulated in the language of Certificate Policies, Certification Practices Statements and compliant operational processes. As a PKI architect, I therefore consider policy to be a fundamental central theme in my philosophical approach to PKI design and architecture.
What assurance means
Assurance is commonly defined as the confidence a relying party can have that the subject listed on a certificate is in fact the one presenting a given certificate. While most customers can readily identify with this statement, this means that the corporate definitions of assurance need to be made tangible. Assurance needs to be described in ways that can be readily understood and agreed to by all.
PKI just got real.
So where do we start in that description of assurance? I have found that a good starting point for an assurance based conversation is one that yields a list of potential risks that can be associated with the misuse of certificates. In other words, what are the bad things that could possibly happen in the event that a malicious, or misconfigured certificate is issued and used from an internal PKI? This might yield a list that looks like this:
- Damage to reputation
- Financial loss
- Harm to product or company
- Sensitive information release
- Personal safety
- Civil / Criminal violations
Refining this impact list into High/Medium/Low impact levels allows customers to readily map any certificate use case back to a set of defined impact levels. As an example…
- Level 1 – Low confidence in the asserted identity
- Level 2 – Medium confidence in the asserted identity
- Level 3 – High confidence in the asserted identity
Developing a thorough, risk/impact matrix that details the potential harm against impact levels, allows corporate risk teams to assign non-arbitrary assurance requirements to any given certificate use case, certificate policy and PKI design requirements.
Note: This process is outlined quite well in the US Federal Government Office of Management and Budget: https://georgewbush-whitehouse.archives.gov/omb/memoranda/fy04/m04-04.pdf
Assigning non-arbitrary values to assurance levels is key to standardizing risk and assurance based conversations within an enterprise. This allows application owners and certificate policy owners to accurately map risk to well understood assurance levels. Developing a common understanding of assurance allows all parties to correctly select the appropriate CAs and appropriate certificate lifecycle processes to meet their certificate needs.
As one can imagine, developing this common understanding of risk, impact and assurance is a non-trivial endeavor. It requires knowledge in multiple different disciplines such as PKI, risk and compliance. Often times accomplishing this in a successful manner requires a team effort. And unfortunately, this level of effort is rare.
More often than not, administrators often just want certificates.
What the lack of assurance means
I would offer that in many cases (more than I care to admit) policy and assurance are secondary considerations when a customer is asking about a PKI design. In the vast majority of PKI designs, I am asked about signature, key exchange or other cryptographic algorithms. But policy is rarely in the forefront of these discussions.
Without an asserted certificate policy there can be no legitimate claim to any specific level of assurance. It’s this lack of guidance that allows for the use of any certificate, issued under any circumstance to be considered useful for any application.
Not ideal to say the least.
This kind of cryptographic anarchy would allow for the least secure certificates to be used to protect the most valuable corporate assets. Why not? Who’s to say otherwise? Think of it this way, would anyone rely on an automatically enrolled user certificate to protect the secret formula used by the company?
A lack of certificate policy means no assurance, and a lack of assurance quite often leads to risk. Not just because certificates can be used in situations where they clearly should not be used, but because the mere use of certificates imparts what is often a falsely elevated sense of security. In fact, digital certificates implemented to improve a corporate security posture could actually make things worse depending on how one’s PKI is designed and operated.
It is for these reasons that I view the creation of a meaningful, and appropriately detailed Certificate Policy, as a central theme when designing a corporate PKI. The ability to prescribe certificate operations against certificate assurance technical capabilities is key to accurately assessing PKI related risk and verifying PKI compliance.
