Public Key Infrastructure
When people refer to public or private PKI [01], they are actually referring to publicly trusted and privately trusted infrastructures. Please keep in mind that public and private keys are not related to public and private PKI.
What’s more, both cases refer to hosted PKI or PKI-as-a-Service (PKIaaS) solutions. Internal (or locally hosted) PKI can work as private PKI, but it takes a significant amount of effort and resources to implement the tools and services you would get from a hosted PKI or PKIaaS provider.
Fundamentally, a PKI has two functions:
- to manage a collection of public[02] and private keys, and
- to bind each key with the identity of an individual entity such as a person, or organization.
Binding is established through the issuance of electronic identity documents, called digital certificates [03]. Certificates are cryptographically signed with a private key so that client software (such as browsers) can use the corresponding public key to verify a certificate’s authenticity (i.e. it was signed by the correct private key) and integrity (i.e. it was not modified in any way).
Publicly trusted and Privately trusted PKI
While both PKI configurations provide the same function, their distinction is quite straightforward.
Public PKIs are automatically trusted by client software, while private PKIs must be manually trusted by the user (or, in corporate and IoT environments, deployed to all devices by the domain administrator) before any certificates issued by that PKI can be validated.
An organization that maintains a publicly trusted PKI is called a Certificate Authority (CA). To become publicly trusted, a CA must be audited against standards such as the CA/B Forum’s Baseline Requirements [04] and be accepted into public trust stores like the Microsoft Trusted Root Store Program.
Although private PKI implementations can be just as secure as their public counterparts, they are not trusted by default because they are not provably compliant with these requirements and accepted into trust programs.
Why choose a publicly trusted PKI?
Being publicly trusted means that publicly trusted root certificates (associating the identity of a CA with their official public keys) are already distributed in most clients. Browsers, operating systems, and other client software are shipped with a built-in list of such trusted public keys that are used to validate certificates they encounter. (Responsible vendors can also be expected to update these lists when updating their software.) In contrast, privately trusted root certificates (needed for a private PKI) must be manually installed in a client before certificates from such private PKIs can be validated.
As a consequence, if you are trying to protect a publicly accessible web site or other on-line resource, a certificate issued from a publicly trusted PKI (i.e., a CA) is the way to go, since requiring each visitor to manually install a private PKI’s root certificate into their browser is not practical (and the consistent security warnings likely to result will negatively affect your site’s reputation).
Why choose a privately trusted PKI?
Public PKIs must strictly follow regulations and undergo regular audits, while a privately trusted PKI may forgo auditing requirements and deviate from standards in any way its operator sees fit. Although this can mean that they do not follow the best practices as rigorously, it also allows customers using a private PKI more freedom regarding their certificate policies and operations.
One example: the Baseline Requirements prohibit publicly trusted CAs to issue certificates for internal domains (e.g. example.local). A private PKI can, if desired, issue certificates for any domain as needed, including such local domains.
Publicly trusted certificates must also always include specific information in a manner strictly defined by their controlling regulations and formatted in a certificate profile mapping to the accepted X.509 standard for public certificates. However, some customers may require a custom certificate profile, specifically tailored to their organization’s anticipated uses and security concerns. A private PKI can issue certificates using a specialized certificate profile.
Apart from the certificate itself, private PKI allows for full control of the identity and credentials verification procedures as well. A customer’s own access control systems (such as single sign-ons or LDAP directories) can be integrated with the private PKI service to easily provide certificates to parties already trusted by the operator. In contrast, a publicly trusted PKI must perform strict manual and automated checks and validation against qualified databases before issuing any certificate.
Certificate Transparency
We should also note that a private PKI is not required to participate in Certificate Transparency [05].
Browsers such as Chrome now enforce [06] CT for all publicly trusted certificates, which requires CAs to publish all certificates issued to a publicly accessible database. Private PKI operators, however, are not obliged to implement CT, and may as a result provide better privacy for sensitive applications, or where public disclosure of internal network structure would be considered harmful [07].
Conclusion
Selecting one PKI solution over the other is not a trivial decision. Both public and private PKI offer benefits and drawbacks, and your own choice can depend on many factors, including need for public access, ease of use, and security and policy requirements for control of your infrastructure.
Here at SSL.com, we are happy to help you build an effective PKI plan that suits your organization’s unique needs.