Secure email and certificate-based authentication

Why this matters

Two cryptographic use cases that share a property worth noticing: both are places where the cryptography has been available and correct for decades and adoption has been decided by operational cost rather than by capability.

End-to-end email encryption is the clearest example. The mechanisms work, they are standardised, and adoption outside specific sectors is minimal — because key distribution is hard, and because the layer that did deploy widely solves a different and more common problem. Understanding why is more useful than memorising the acronyms, and it is what the exam tests: given a requirement, which layer addresses it.

Certificate-based authentication is the second, and it is the direction of travel for identity across the estate — for users, devices and workloads. Its cost is a lifecycle obligation, and that obligation is where it succeeds or fails.

The lesson

S/MIME and PGP: trust models, key distribution and why adoption stalls

Both provide end-to-end confidentiality and authenticity for message content. The difference that matters is how you come to trust a key.

S/MIME uses a hierarchical trust model: certificates are issued by certificate authorities, and a recipient trusts a sender's certificate because it chains to an authority they already trust. Support is built into most enterprise mail clients, and enrolment can be centrally managed, which is why S/MIME is the one that appears in organisations that deploy this at all.

PGP and OpenPGP use a decentralised model: trust comes from direct verification or from a web of trust in which users sign each other's keys. There is no central authority, which suits parties with no common institution and makes organisational deployment harder.

Both encrypt with the recipient's public key and sign with the sender's private key, giving confidentiality, authenticity and non-repudiation of the message content, end to end, independent of the mail servers in between.

Why adoption stalls, which is the examinable part:

• Key distribution. You need the recipient's key before you can send encrypted mail. Within one organisation that is solvable by directory publication; across organisations it is a negotiation per correspondent.
• Key loss is message loss. A lost private key makes years of archived mail unreadable, which pushes organisations toward key escrow, which reintroduces a party who can read everything.
• Mobile and webmail support is inconsistent, and users read mail on many clients.
• It breaks server-side processing. Encrypted content cannot be scanned for malware, inspected for data loss, indexed for search, or archived in readable form for compliance. This is frequently the blocking objection and it is a genuine trade rather than an excuse.
• Metadata is unprotected. Sender, recipient, subject and timing remain visible, and in many threat models the metadata is most of the sensitivity.

The consequence worth stating: signing is far more deployable than encrypting, because it requires no prior key exchange with the recipient and breaks nothing server-side. An organisation that cannot deploy encrypted mail can often deploy signed mail, and signing addresses the impersonation threat, which is the more common attack.

SPF, DKIM and DMARC as the authentication layer that actually deploys

These do something different from S/MIME and PGP, and the distinction is the one scenarios test: they authenticate the sending domain, not the message content, and they protect recipients of mail claiming to be from you.

• SPF publishes, in DNS, which servers are authorised to send mail for a domain. A receiver checks the connecting server against that list. It validates the envelope sender, which is not the address the user sees, and it breaks on forwarding.
• DKIM signs selected headers and the body with a key whose public half is published in DNS. A receiver verifies the signature, establishing that the message was signed by the domain and not altered in the signed parts. It survives forwarding, which SPF does not.
• DMARC ties the two to the visible From address — requiring alignment between it and the authenticated domain — states a policy for failures (none, quarantine, reject), and provides reporting so a domain owner can see who is sending as them.

Why this layer deployed where end-to-end encryption did not: it requires no change by the recipient, no key exchange with correspondents, and no change to how mail is read. It is DNS records and a signing configuration on outbound mail, and it protects everyone who receives mail claiming to be from your domain.

Two implementation points that recur. DMARC must be deployed in stages — monitor first, using the reports to find legitimate senders you did not know about, then quarantine, then reject — because going straight to reject reliably blocks a genuine service nobody remembered, and the third-party senders are always more numerous than expected. And it does not stop everything: display-name spoofing, lookalike domains, and compromised legitimate accounts all pass authentication perfectly, which is why this is one control rather than the answer to phishing.

The clean comparison to carry: S/MIME and PGP protect the message; SPF, DKIM and DMARC protect the domain. A scenario about confidentiality of content wants the first; a scenario about spoofed sender addresses wants the second.

Certificate-based authentication for users, devices and workloads

Authentication by possession of a private key, proven by a challenge, with a certificate binding that key to an identity. It appears in three contexts.

Users. A certificate on a smart card or in a hardware-backed store, used for logon, VPN and application access. Its strength is that the credential cannot be phished — there is nothing to type and nothing to relay — which makes it, alongside modern hardware-bound authenticators that work on the same principle, one of the few controls that genuinely addresses credential phishing rather than raising its cost.

Devices. A certificate provisioned at enrolment, ideally with the key in a hardware root of trust so it cannot be copied to another machine. This is the device identity that lesson twenty-two's posture signals and lesson twenty-five's decisions depend on, and the hardware binding is what makes it meaningful rather than a file anyone can steal.

Workloads. A certificate per service, used for mutual TLS as lesson thirty-six described. Short-lived, issued automatically, frequently tied to an attested identity.

The advantages over shared secrets are worth stating precisely: nothing reusable is transmitted, so interception and replay do not work; it is resistant to phishing because no secret can be typed into a false site; it binds to hardware where a root of trust exists; and it produces strong audit evidence of which identity acted.

The trade is that a certificate is only as good as three things: the protection of the private key, the rigour of the issuance process, and the ability to revoke. A certificate authority that issues without verifying identity produces credentials with the appearance of strength, and issuance is the step that gets weakened for convenience.

Enrolment, renewal and revocation, and the outage caused by an expired certificate

The lifecycle is where certificate deployments succeed or fail, and each stage has a characteristic failure.

Enrolment. How does the authority know the requester is who they claim? Options range from an in-person identity check for high-assurance user certificates, to automated verification of control over a name, to attestation of a workload's identity by the platform. Enrolment is the root of the whole system's assurance, and the common failure is an automated process that will issue to anything able to reach it.

Distribution and protection. The private key should be generated where it will live — ideally in hardware — rather than generated centrally and transported. A key that travelled has been in more places than the device it now protects.

Renewal. Certificates expire, which is a feature: it bounds the damage of an undetected compromise and forces the lifecycle to work. It is also the source of the most common operational failure in this lesson — the expired certificate outage, which is a self-inflicted availability incident in a security control.

The controls are unglamorous and effective: automated renewal wherever possible; inventory of every certificate with its expiry, including those issued by teams outside the process and by third parties; alerting well ahead of expiry with escalation, not a single reminder; and short lifetimes, which as lesson thirty-six argued make renewal automation mandatory and therefore reliable, rather than an annual manual task everyone forgets.

Revocation is the genuinely hard part. Revocation lists become large and are cached; online status checking adds an availability dependency and is often configured to fail open, which means an attacker who blocks the check defeats revocation entirely. Two practical answers: short lifetimes, so expiry does revocation's job on an acceptable timescale; and stapling, where the server presents a recent signed status, removing the client's dependency on reaching the responder. A scenario asking how to handle revocation at scale is usually looking for short lifetimes rather than a better list.

Reading a scenario for whether the requirement is confidentiality or authenticity

The closing method for the objective, because these two use cases are where the distinction most often decides the answer.

Confidentiality means the content must be unreadable by anyone except the intended recipient. Signals in a scenario: sensitive content, an untrusted intermediary, a regulatory duty to protect content, or an explicit statement that a party must not be able to read it. The control is encryption to the recipient — S/MIME or PGP for mail, and above the layer of the excluded adversary for stored data.

Authenticity means the recipient must be certain who sent it and that it was not altered. Signals: impersonation, spoofing, fraud, a need to prove origin, or a requirement that an action be attributable. The control is a signature — S/MIME or PGP signing for content, DKIM and DMARC for the domain, certificate-based authentication for identity.

Non-repudiation is authenticity plus the property that the sender cannot credibly deny it, which requires the private key to be under the sender's sole control — which is why hardware-held keys matter for it and escrowed keys undermine it. A scenario emphasising that a party must not be able to deny an action is asking for this specifically, and it is the one that rules out any design where a second party holds the key.

Three closing observations. Most scenarios want authenticity, because impersonation is the more common attack and the more deployable control — and candidates reach for encryption reflexively. The two are independent: you can have either without the other, and encryption without authentication is the trap lesson thirty-six named. And the requirement is usually in the scenario's first sentence, in the description of what went wrong or what must be prevented, rather than in the technical detail that follows.