Learning PKI
Note
I do not usually retroactively edit blog posts after writing them, but I may choose to edit this one to add to it and expand on it. It's not meant to tell a story but to explain some of the complex relationships in PKI. I've also chosen to take advantage of some features that allow for use of abbreviations while allowing you to hover over the usage to see the full text. Where, possible, I've expanded these directly in the text as well.
A few years ago, I transferred to the Data Security Department to work on our PKI inside of Salesforce. The brief description of what we do includes an internal Registration Authority that authorizes certificates from our Certificate Authority we have a contract with for externally facing certs as well as an entire internal Certificate Authority and all of the fun that entails.
When I moved over, I had a fairly basic understanding of what was involved in PKI. I had mostly consumed PKI and had learned much of what I knew from working on python-requests and certifi. However, there is a great deal to learn and many ways to approach it. Beyond constantly attempting to learn more myself, I have the honor and privilege of helping other engineers at Salesforce learn more about PKI.
Standards
PKI is based around a set of standards, best practices, and policies or requirements. The flow of standards, best practices, and requirements is fluid. Often times, one influences the other so paying attention to one is not sufficient. There are several bodies involved in these various areas:
- IETF
- Concluded PKIX Working Group
- Limited Additional Mechanisms for PKIX and SMIME
- Automated Certificate Management Environment (ACME) Working Group
- Related but not directly PKI IETF Groups:
- CA/B Forum
- Browser Root Programs (yes, there are multiple)
- Apple Root Certificate Program
- Chrome Root Certificate Program
- Microsoft Trusted Root Program
- Mozilla Root Store Program/Policy
In many ways these various bodies feed into each other. For example, a specific root program might start to push for a more stringent requirement and that may then turn into a ballot within the appropriate CA/B Forum WG (usually Server Cert). Sometimes, you'll also see another body, e.g., NIST, standardize something which then requires updates to existing RFCs in the appropriate WG or RG before it is adopted by the CA/B Forum. As an example, RFC 8657 added the ability to restrict CAA records to a specific ACME account URI. This is a stronger authorization than CAA records previously allowed for which scoped it to an entire CA.
RFC 5280
Probably the resource I refer to most often is RFC 5280. Whilst it was written in 2008 (it's nearly 20 years old!) it defines much of what is standard for PKI today. Section 4 defines X.509 for Certificates. Section 5 defines Certificate Revocation Lists (CRLs). Section 6 defines how to validate a certificate is trusted (a.k.a. Certificate Path Validation). Section 7 describes Internationalized Domain handling (i.e., handling names defined in RFC 3987 which is different from RFC 3986).
RFC 5280 also leans heavily on other RFCs and standardized languages and serialization formats that existed before it. It may be necessary to eventually learn about ASN.1 (X.680) and Distinguished Encoding Rules (a.k.a., DER, X.690)
RFC 5480
Most relevant today as we look towards making harvest now, decrypt later more difficult by by moving away from RSA keys to Elliptic Curve keys. Eventually there will likely be further RFCs specifying how to handle Subject Public Key Information for PQC keys as well as updates to TLS to support cipher suites that will work with PQC.
Baseline Requirements
Planning to start issuing certificates? These are documents you should read. If you're planning for your certificates to be publicly trusted, you MUST read these documents and adhere to them. You'll also need to read the root program policies for all of the root programs you might want to be included in.
Even if you only intend to issue certificates internal to your organization, you should probably be able to find relevant information in these documents. You will find that some X.509 and TLS implementations are more forgiving than others, while some are more strict. You might notice that something doesn't work and these will likely answer your questions.
The caveat, of course, is that you must know what your certificate will be doing to know which of the BRs to read.
Tables of Links
Documents
This is a non-comprehensive, unordered set of documents helpful for referencing quickly when working with PKI
| Document ID | Title | Description |
|---|---|---|
| RFC 5280 | Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile | Covers Certificates and Certificate Revocation Lists (CRLs) |
| RFC 5480 | Elliptic Curve Cryptography Subject Public Key Information | Defines behaviours for using Elliptic Curve keys and how they are treated in the Subject Public Key Information section of an X.509 certificate |
| RFC 6960 | X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP | Obsoletes RFC 2560 and RFC 6277 and defines how an Online Certificate Status communication works between a TLS verification stack and an OCSP responder. OCSP has always been considered a privacy problem and thus OCSP Stapling was introduced to enable a server to send the response in the handshake. That has not gained wide browser or general client adoption though. Note: Let's Encrypt is turning off its OCSP responders on 2025 August 6. [LEOCSP] |
| RFC 8555 | Automatic Certificate Management Environment (ACME) | This is the standard interface for Let's Encrypt and every CA that supports automated certificate management via tools like Certbot or Caddy. |
| Apple Root Certificate Program | Apple Root Certificate Program | This contains the standards that Apple expects a Certificate Authority to adhere to in order to be included in their trust store on their devices. |
| Chrome Root Program Policy | Chrome Root Program Policy | This contains Google's standards for inclusion in the Chrome project's root store. Note: This is also available as markdown on GitHub at GoogleChrome/chromerootprogram. |
| Mozilla Root Store Policy | Mozilla Root Store Policy | This contains the standards that Mozilla expects a Certificate Authority to adhere to in order to be included in the trust store it generates for the various products it distributes. |
| Microsoft Trusted Root Policy | Program Requirements - Microsoft Trusted Root Program | This contains Microsoft's standards for inclusion in their trusted root program. Note: There are actually multiple separate pages to this, but I didn't want to list them all individually. The Trusted Root overview has the table of contents available as does each sub-page. |
| Chrome's documentation about pursuing improvements | Moving Forward, Together | The Chrome Root Program often aspires to improving the state of the art and pushing Certificate Authorities and Browsers to move more aggressively to improve the security of the internet. These are listed as distinct from the Root Program Policy. |
| CA/B Forum's Server Cert Baseline Requirements | Baseline Requirements | These are the bare minimum requirements that any Certificate Authority must adhere to in order to be publicly trusted. The requirements are extensive and they are adopted by ballots. They also reflect both best practices as well as incident retrospective action items found to be good learnings for all CAs (e.g., the recent requirement to lint certificates pre-issuance). |
| CA/B Forum's Server Cert Extended Validation Guidelines | Extended Validation | Most Certificate Authorities offer DV and OV certificates for different prices. Some CAs also offer EV certificates for significantly more. These certificates don't change the functional security of the connection being established. They can provide additional guarantees for those checking attributes on the certificate. As a result some organizations prefer these types of certificates. However, no browser distinguishes between any of these certificates. |
| CA/B Forum's S/MIME Baseline Requirements | Latest S/MIME Baseline Requirements | An S/MIME Certificate contains a public key bound to a mailbox address and may contain the identity of the person controlling the mailbox. The public key in the certificate can then be used to sign, verify, encrypt, and decrypt email. |
| CA/B Forum's S/MIME Baseline Requirements | Latest Code Signing Baseline Requirements | These are the baseline requirements for certificates issued by CAs for publicly-trusted code signing certificates. If you've ever had to allow a binary to run on your machine because it wasn't from a recognized author, that's because the binary wasn't signed with a publicly trusted code signing certificate. |
| CA/B Forum's NetSec Requirements | Latest Network and Certificate System Security Requirements | These define terms for identifying systems accurately and the minimum requirements for securing those systems. These are complementary to all of the baseline requirements files above. |
Libraries
| Language | Library | Commentary |
|---|---|---|
| Python | pyca/cryptography | I've used this personally in the past and it is excellent. It supports most things you'll need to deal with when working with PKI. It's feature-rich, ergonomic, and leverages OpenSSL. |
| Golang | crypto/x509 | I use this constantly these days. I enjoy the interface and it works without issue. The only concern I've found is a recent (Go 1.23) change that disallows parsing certificates with negative serial numbers. Normally, I'd be less worried about this except that I've seen a CA certificate with a serial number that parses as a negative integer, so this seems like it could impact folks inadvertently. That said, this is the correct behaviour and I'm also all for pushing best practices forward rather than letting bad software continue to operate without accountability. |
| Golang | encoding/pem | This is the perfect standard library companion to crypto/x509 |
| Golang | encoding/asn1 | This is in the Go standard library and it powers the crypto/x509 library |
| Rust | rust-asn1 | This library focuses on supporting DER serialization which is the standard and most common serialization with ASN.1. I also already know the authors and know that they use this extensively in pyca/cryptography so while I haven't used it directly, I am confident in its excellence. |
| Rust | x509-parser | I've yet to use this library personally but it does seem to be an often recommended library for parsing X.509 certificates. It does use a separate library for parsing ASN.1 (both BER and DER). |
Linters and Tools
| Tool | Purpose | Commentary |
|---|---|---|
| PKI Meta Linter | Pre- and post-issuance linting of certificates (i.e., for RAs or CAs) | This tool was developed to combine several other linters around various specific purposes in PKI. It does not re-implement the checks itself. In many ways this is a lot like flake8 or golangci-lint. The tool can be run as a service as well. It is written in Golang but the linters it integrates with are in various languages (Python, Ruby, C, etc.). |
| certlint | Lints certificates for compliance with RFC 5280 and CAB Forum TLS requirements | Written in Ruby, forked from Amazon, and maintained by the PKI Meta Linter author, it checks basic certificate compliance. |
| pkilint | Certificate, CRL, and OCSP linter for compliance with RFC 5280 and CABForum TLS and S/MIME requirements | Written in Python by Digicert. It uses pyca/cryptography. |
Other Efforts and Projects
| Project | Description |
|---|---|
| Community Cryptography Specification Project (a.k.a, C2SP) | A project where implementers can share a variety of resources to facilitate maintenance and interoperability. |
| Wycheproof | Project Wycheproof contains test vectors that can be used to test crypto libraries against known attacks. |
| Community Cryptography Test Vectors (a.k.a., CCTV) | CCTV is an experiment, part of the Community Cryptography Specification Project, in test vector collection and reuse. |
| x509-limbo | A suite of test vectors and tooling for X.509 certificate path validation. |
Books and Other Media
| Type | Title | Personal Recommendation | Notes |
|---|---|---|---|
| Books/Courses | Feisty Duck Resources | No | I've seen multiple people recommend these resources. |
| Podcast | Root Causes | Yes | I've been listening to Root Causes for over a year now at least. The episodes are short, sweet, and to the point. I personally enjoy the aspirational and realistic takes, the different perspectives on evolutions in technology, and the occasional griping about frustrations. |
| Bug Tracker | Bugzilla | Yes | Mozilla's Root Program uses bugzilla to track numerous things around their Root Program. Most other Root Programs will also accept incident reports that are links to Mozilla Bugzilla Incident Bug Reports. Following this has been a learning experience but also occasionally entertaining [1] [2]. |
| Database | Common CA Database | N/A | This is a collaborative effort sponsored by the Linux Foundation to coordinate information about CAs in one place that is gathered by the various Root Program operators. This is actually, managed on Salesforce. This was transitioned from a spreadsheet managed by one person as described in their retirement email. |
| Podcast | Security Cryptography Whatever | Yes | This is a podcast I listen to primarily for its cryptography content. It has excellent guests and entertaining hosts. It's not strictly PKI related but it's also not unrelated. |
| Wiki | Responding to an Incident | Yes | These are the expectations of a CA responding to an incident. |
| Blog | The Random Number Digest | Soft Yes | A Substack blog that aims to be a monthly digest of news from PKI by Corey Bonnell. Cory works at DigiCert and cares very much about practical PKI implementation it seems. There's only 3 months of reviews there as of this writing, but I've found it interesting given how much there can be to keep up with. |
| [LEOCSP] | https://letsencrypt.org/2024/12/05/ending-ocsp/ |
| [1] | https://bugzilla.mozilla.org/show_bug.cgi?id=1950144 |
| [2] | https://bugzilla.mozilla.org/show_bug.cgi?id=1961406 |