12.2 Understand Public Key Infrastructure
Key Takeaways
- A certificate authority issues a leaf certificate from a certificate signing request that carries the public key and identity; the private key is generated on the host or hardware security module and never sent to the CA.
- Fundamental key management on the SSCP outline is storage, rotation, composition, generation, destruction, exchange, revocation, and escrow — not 'make a key and forget it.'
- A lost or stolen private key is a compromise: revoke the certificate through a certificate revocation list and/or Online Certificate Status Protocol, replace the key pair, and install a new certificate. Waiting for notAfter leaves the stolen key usable.
- Hardware security modules generate and use high-value private keys without exporting them; they are the storage control for CA, code-signing, and payment keys. A help-desk mailbox is not an HSM and is not responsible escrow.
- Web of Trust (Pretty Good Privacy, GNU Privacy Guard, blockchain) distributes trust without a central CA. Enterprise key escrow of data-encryption keys preserves availability after personnel change and trades some confidentiality for recoverability.
Understand public key infrastructure
Knowledge Area 5.4 — understand public key infrastructure (PKI) — is how the protocols in 5.3 get identities. TLS, certificate-authenticated IPsec, and S/MIME all fail or succeed based on whether a certificate authority (CA) bound a public key to a name, whether that binding is still valid, and whether the private key is still only where you think it is. Domain 5 remains 9% of the SSCP exam; 5.4 is the operational half of that slice.
The outline's two bullets are fundamental key management concepts (storage, rotation, composition, generation, destruction, exchange, revocation, escrow) and Web of Trust (WOT) examples: Pretty Good Privacy (PGP), GNU Privacy Guard (GPG), and blockchain. You also need the machinery those bullets assume: CA hierarchy, certificate signing request (CSR), certificate revocation list (CRL) versus Online Certificate Status Protocol (OCSP), conceptual certificate pinning, and hardware security module (HSM) storage.
CA hierarchy, certificates, and the CSR
A public key certificate is a CA's signed statement: this name owns this public key, until this date, for these uses. The matching private key never belongs in the certificate and never belongs at the CA.
Typical hierarchy:
- Root CA — trust anchor. Its certificate is distributed in trust stores (browsers, operating systems, mobile devices, IPsec gateways). It should be offline or tightly controlled. Compromise of the root is a full-environment incident.
- Intermediate (issuing) CA — signed by the root, issues leaf certificates to websites, VPN gateways, people, and services. If an intermediate is compromised, you revoke that intermediate instead of burning the root.
- Leaf (end-entity) certificate — the one on the load balancer, the IPsec peer, or the S/MIME mailbox. Names live in Subject and, in practice, in Subject Alternative Name (SAN) (DNS names, sometimes IP addresses or email). Key usage and extended key usage constrain the key (server authentication versus code signing versus email protection). A web-server certificate offered to sign mail, or an email certificate offered as a TLS leaf, is a composition error.
CSR (typically PKCS#10): generate the key pair on the system — or inside the HSM — that will use the private key. The CSR carries the public key and the requested identity. The CA validates that identity (domain control for public TLS, HR process for a person, inventory process for a machine), signs a certificate, and returns only the certificate. If a vendor asks you to email the private key with the CSR "so we can install it," that is a finding, not a convenience.
Validity is a pair of timestamps (notBefore / notAfter). Expiry is planned invalidation. Revocation is unplanned invalidation because the private key leaked, the name is wrong, the employee left, or the CA no longer vouches for the binding. Expiry is not a substitute for revocation: a stolen key remains cryptographically usable until relying parties are told to stop trusting the serial.
Key management lifecycle
The outline's eight words are the whole job. A team that can generate RSA keys but cannot revoke or destroy them does not run PKI.
| Concept | Practitioner meaning | Failure you will see on the exam |
|---|---|---|
| Generation | Create the key pair with an approved random source, on the device or HSM that will hold it. High-value CA, code-signing, and payment keys are generated inside an HSM. | Generating a production issuing-CA key on a laptop, copying it to a USB stick, and calling that "the CA" |
| Composition | Algorithm, length, and allowed uses (for example RSA 2048+ or elliptic-curve keys; digitalSignature, keyEncipherment, keyCertSign). Match composition to the protocol: a 1024-bit RSA web key is a strength problem from 5.2 and a PKI composition problem here. | Reusing one key pair for TLS, S/MIME, and code signing "to keep it simple" |
| Storage | Private keys in an HSM, Trusted Platform Module (TPM)-backed store, or cloud key management service with access control and audit. Encrypt any software store. Never commit keys to git, a shared drive, or chat. | Private key in the web root, in a runbook screenshot, or in an email attachment |
| Exchange | Public keys and certificates may travel openly. Private keys, if they must move, are wrapped (HSM export under dual control, TLS or IKE session keys agreed ephemerally). | Emailing an unencrypted PEM private key to the load-balancer vendor |
| Rotation | Replace keys on a schedule before expiry, and on events (role change, suspected exposure, algorithm retirement). Rotation includes issuing a new cert and cutting over listeners without an outage. | Waiting for the warehouse IPsec cert to expire on a Saturday (Section 12.1) |
| Revocation | Tell relying parties the binding is dead now: CRL and/or OCSP, then replace the key. | "We'll wait for notAfter" after a stolen laptop |
| Destruction | Zeroize HSM slots, crypto-erase disks that held software keys, dual-control for CA keys, record the destruction. | Decommissioning a CA server by reselling the disk |
| Escrow | A recoverable copy of a key that protects enterprise data, held under dual control, so availability survives personnel change. | Escrowing the offline root private key to the help-desk shared mailbox |
Revocation: CRL versus OCSP
When a private key is lost, stolen, or the identity is no longer true, the CA revokes the serial. Relying parties (browsers, VPN gateways, mail clients) must learn that fact before notAfter.
| Certificate revocation list (CRL) | Online Certificate Status Protocol (OCSP) | |
|---|---|---|
| What it is | A CA-signed list of revoked serials, published on a schedule | A query for the status of one serial |
| Freshness | As fresh as the last CRL issue; can be hours stale | Near-real-time response from the responder |
| Size | Grows with every revocation; large lists hurt constrained clients | Small response |
| Privacy | Downloading the whole list does not reveal which certificate you are checking | The query reveals the serial to the responder |
| Failure mode | Clients cache CRLs; some fail open if the CRL cannot be fetched | Soft-fail (treat "unknown" as good) versus hard-fail; OCSP stapling has the TLS server present a short-lived signed status so clients need not query |
| Operational fit | Bulk distribution, air-gapped or periodically connected relying parties | Interactive TLS where you want a current, per-cert answer without a giant download |
Stapling is the usual public-web compromise: the load balancer fetches OCSP, caches the response, and "staples" it into the TLS handshake. Clients still need a path to learn revocations; turning checking off because "it caused an outage once" is how a revoked stolen key keeps serving checkout.
Scenario — lost private key. A jump-box laptop that stored the PEM for the public website's TLS private key is stolen from a parked car. Disk encryption status is unknown. Treat it as compromise. Revoke that leaf at the CA so CRL and OCSP say revoked, generate a new key pair on the load balancer or HSM (do not reuse the stolen key), install the new certificate, and watch for the old serial. Waiting for natural expiry leaves the thief a working key. Emailing the passphrase to the CA does nothing useful — the CA never held the private key. Moving the site to HTTP "until we find the laptop" removes confidentiality instead of restoring a trustworthy certificate.
Certificate pinning, conceptual
Certificate pinning is a client (often a mobile app) that will accept only an expected leaf, public key, or intermediate — not "any chain that chains to a public root." It reduces the damage of a rogue or coerced public CA. The operational cost is change: if you switch content-delivery networks, rotate the leaf, or replace the intermediate, a pinned app hard-fails until you ship an app update that includes the new pin (and a backup pin). SSCP wants the concept and the outage mode, not a vendor SDK. Pinning is not a substitute for revocation, and it is not how a browser's default TLS works.
HSMs and storage
A hardware security module is a tamper-resistant appliance (network-attached or PCIe) that generates, stores, and uses private keys so the key material does not export in plaintext. CA keys, code-signing keys, and payment keys belong there. Operators authenticate to the HSM and request a signature; they do not copy the key to a jump box "just for this change window." A host TPM can bind keys to a single machine; it is not a network HSM for the issuing CA. Domain 7 will treat TPM as an endpoint control; here, remember HSM as the PKI storage control.
If you cannot name where the private key lives, you do not have storage. "It is on the shared drive in the PKI folder" is the wrong answer.
Escrow versus availability
Key escrow means a recoverable copy of a key exists under someone else's control — typically the employer, split across dual control or a recovery agent — so encrypted enterprise data can be opened after an employee leaves, is incapacitated, or loses a token. Without escrow, strong encryption becomes a denial of availability: the ciphertext is perfect and nobody can read the tax files.
Escrow is a confidentiality trade. The spare key is a new target. Do it for data-at-rest keys that the organization owns. Do not treat these as escrow:
- Emailing the root CA private key to a help-desk mailbox.
- Storing TLS web-server private keys in a vendor ticket "so they can recover the site."
- A single administrator's personal GPG passphrase written in a wiki.
Scenario — escrow and GPG. Finance encrypted a share of tax files with one employee's personal GPG key. The employee left. There is no escrow. The files will not open. Enterprise escrow of the data-encryption key (generated in an HSM, recoverable under dual control) would have preserved availability. That is the lesson. A public CA would not have decrypted GPG files via a CRL. Certificate pinning would not have decrypted them either. Using software GPG was allowed; skipping escrow on organization-owned archives was the key-management miss.
Web of Trust: PGP, GPG, and blockchain
PKI is centralized trust: everyone trusts the CA. Web of Trust is distributed trust: people (or systems) sign each other's keys, and you decide whose signatures you accept.
- PGP and GPG implement WOT for email and file signatures. Two sysadmins sign a release tarball and sign each other's keys at a team meeting. There is no public CA in that loop. Key loss without escrow is the availability problem above. Key authenticity without enough introducers is the trust problem.
- Blockchain, listed in the outline, is an append-only ledger of signed transactions. Trust is in the consensus rules and the public keys (addresses), not in an issuing CA. The SSCP point is the trust model — decentralized, cryptographic non-repudiation of recorded events — not a request to design a cryptocurrency. Domain 5's AI notes also mention ledgers as a way to sign provenance; treat that as the same idea: signatures without a corporate CA.
WOT does not replace public TLS. You will not run the retail checkout on a GPG web of trust. You might sign vendor drops with GPG and serve the portal over TLS with a CA-issued leaf. Different trust models, different protocols.
When you sit the exam, ask: who generated the private key, where is it stored, how would we rotate or destroy it, and if it is gone today, do we revoke or did we just lose the data? That is Knowledge Area 5.4.
Section takeaways
Issue certificates from CSRs while the private key stays on the host or HSM. Run the full lifecycle — especially revocation and planned rotation — instead of treating notAfter as your only control. Use CRL and OCSP so stolen keys die before expiry. Escrow data keys for availability; do not mailbox-escrow CA keys. Know WOT (PGP, GPG, blockchain) as the non-CA alternative, not as a PCI checkout plan.
A jump-box laptop that stored a public-facing web server's TLS private key is stolen from a parked car. Disk encryption status is unknown. What is the correct PKI action?
A load balancer must prove to browsers that a leaf certificate has not been revoked, with a small per-certificate status and without forcing every client to download a large list. Which mechanism matches that operational goal?
Finance encrypted a share of tax files with one employee's personal GNU Privacy Guard key. The employee left with no key escrow, and the files cannot be opened. Which statement correctly describes the key-management lesson?