Design and build a privately hosted Public Key Infrastructure
Pages
Page 8 of 21
How to use these principles
On first reading, you should work through these principles in order, so you become familiar with the structure which they provide. Subsequently, this will make it easier for you to apply the principles individually, to the relevant stage or component of your system.
This guidance details the elements of a high level PKI design, but does not provide a solution for individual PKI use cases. However, the principles can be used as a guide when assessing specific products or services for use in a wider PKI architecture. We don't recommend creating your own PKI software or hardware components. You should use trusted services and products developed by reputable vendors.
Using these principles does not guarantee a secure private PKI but will help you to consider what elements are important in a private PKI architecture.
Is a PKI right for your authentication needs?
Before using our design principles you should consider if you require a PKI for your authentication challenges.
Private PKI's are complex to set up and require a constant level of maintenance by skilled practitioners. Alternative methods of authentication which are easier to implement may meet your requirements just as well. For example, using a federated identity service or a managed cloud identity service. You could use a managed cloud identity service for user authentication to a service while a PKI may be better option for authenticating an end entity for a VPN. A private PKI might be required for technical reasons but also by standards or regulation.
Our guidance on identity and access management and how to establish an authentication policy, will help you determine whether a PKI is right for you.
Design Trade Offs
As part of the design process, it's perfectly reasonable to trade off certain aspects based on technology and environmental constraints, or a risk based decision.
Whenever you are considering trading off different functions of the system, you still need to make sure you are achieving your security goals and mitigating the risks posed to your organisation.
Below are some example trade offs that you might have to consider when using these design principles. This is not an exhaustive list.
1. Key Storage vs Certificate lifetime
Storing private keys in a location with strong security properties reduce the likelihood of compromise. Meanwhile, a short certificate lifetime reduces the impact of compromise. Therefore, if you can protect the key well - for example with a TPM or tamper-resistant USB hardware token - you can have longer-lived certificates
Likewise, if you can have very short-lived certificates, you may be able to use a weaker method to secure the keys i.e using a software based method.
2. Certificate lifetime vs Revocation
If the certificate and associated private key have a shorter lifetime - perhaps 1 day - you will be less reliant on a revocation system. As a compromised certificate and private key will expire quickly, the attacker has a limited time before the credential becomes worthless. This limits the potential impact of a compromised credential.
The other factor in deciding on your revocation system design is how long it will take to detect a compromised certificate and private key. For example, if it will take a few days to detect a compromised certificate that has a lifetime of a week, the impact of the revocation system will be limited.
3. Quick recovery time vs less Highly available
If you have a well manged and practised disaster recovery procedure, this could mean you can restore the PKI with a tolerable amount of downtime. This could lead to certain components not needing to be highly available, as long as your organisation can tolerate the amount of down time the restore process takes.
4. Certificate Life time vs CA Infrastructure availability
If the CA infrastructure is highly available, with minimal downtime, then the end entity has the ability to regularly contact the CA to renew its certificate. This enables short certificate lifetimes, as you have confidence the end entity can contact the CA reliably.
