CS 161, Lesson 31, in 53 slides. It covers the public-key authenticity problem and the trusted directory, in sections 13.1 and 13.2, then self-validating digital certificates in section 13.3, and PKI and certificate authorities with the HTTPS trust model in section 13.4. It goes on to certificate chains and hierarchical PKI in section 13.5, revocation through validity periods and CRLs in section 13.6, and the web of trust together with leap-of-faith, or TOFU, in sections 13.7 and 13.8. It is anchored to textbook sections 13.1 to 13.8.
Subject: Computer Security · 85 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
CS 161 · Lesson 31 of 45
certificates as signed name→key bindings · PKI and certificate authorities · chains, revocation · and the web of trust
Objectives
Warm-up
Discussion prompt
Before we open L31 · Certificates, PKI, Chains, Revocation & Web of Trust: without looking back, what was the main idea of L30 · Digital Signatures: RSA Signatures, Number Theory & EUF-CMA, and what could you do by the end of it that you could not do before?
Hint: One sentence for the idea, one for the skill. If the second one is blank, that is the part to revisit.
Answer:
CS 161, Lesson 30, in 56 slides. It presents digital signatures as public-key MACs with the roles reversed, in section 12.1, then the hash-then-sign RSA idea in section 12.2, the number theory that builds the trapdoor in section 12.3, the RSA signature scheme in section 12.4, and EUF-CMA security and its dependence on the hash in section 12.5. It is anchored to textbook sections 12.1 to 12.5.
Concept
Public-key crypto (L28) and signatures (L30) assumed Alice already had Bob's authentic public key. This lesson finally answers: how does she GET it, when Mallory controls the channel?
Matching
Match the pairs
From Three questions this lesson answers — match each one to what it actually does. The descriptions have been shuffled.
Why: How to get an authentic key?, How does this scale?, How does trust fail? are easy to tell apart while they are sitting next to their descriptions and much harder afterwards, which is what this checks.
Section
Part 1 · §13.1–13.2 the unsolved piece
Concept
Public-key encryption and signatures (L28–L30) all start with a giant assumption: Alice already knows Bob's authentic public key. Where does that key actually come from?
The naive answer — 'just ask Bob to send his key over the channel' — fails. If Mallory sits on the wire, she can substitute her OWN key and Alice would never know.
Counterexample
Discussion prompt
Public-key encryption and signatures (L28–L30) all start with a giant assumption: Alice already knows Bob's authentic public key. Where does that key actually come from?
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Answer:
The naive answer — 'just ask Bob to send his key over the channel' — fails. If Mallory sits on the wire, she can substitute her OWN key and Alice would never know.
Concept
Concretely: Alice asks for Bob's key. Mallory intercepts the reply and sends her own public key instead, claiming it's Bob's.
Key-substitution MITM — An active attacker on the channel replaces the authentic public key in transit with her own. Alice then encrypts to Mallory (who decrypts, reads, re-encrypts to Bob) — a full man-in-the-middle, despite the cryptography being 'unbreakable'.
The math is fine; the binding of identity to key is what's missing. 'Public' does NOT mean 'safe to fetch over an untrusted channel.'
Analogy
Discussion prompt
Explain §13.1 The man-in-the-middle key substitution by analogy to something with no Computer Security in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
Concretely: Alice asks for Bob's key. Mallory intercepts the reply and sends her own public key instead, claiming it's Bob's.
Concept
Idea: introduce a trusted third party, Dirk, who runs a directory mapping names → public keys. Alice hardcodes Dirk's key once; thereafter she asks Dirk for anyone's key.
Trusted directory service — A central, trusted party that stores an authoritative table of name→public-key bindings. Clients hardcode the directory's own key and query it to look up the authentic key for any name.
Definition probe
Sort into buckets
Every line below is part of the definition of Key-substitution MITM or of Trusted directory service — one or the other, never both. Put each where it belongs.
Intuition
It defeats the MITM because Alice no longer trusts a key just because it arrived on the wire — she trusts a key because Dirk vouched for it, and she already has Dirk's authentic key hardcoded.
It's like a phone book run by an authority you've already decided to trust: you don't trust a number because a stranger shouted it at you, you trust it because the book said so.
Ask yourself: we replaced 'know everyone's key' with 'know ONE key (Dirk's).' What did we trade away to get that? (Total dependence on Dirk — see the next slide.)
Concept
A single trusted directory has serious problems — the reasons real systems move beyond it:
Explain it
Discussion prompt
Explain §13.2 The directory's five shortcomings to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
A single trusted directory has serious problems — the reasons real systems move beyond it:
Concept
Directory-style key servers still appear in practice. Secure messengers like Signal run a key directory but pair it with a 'trust but verify' model — key transparency lets users detect if the directory ever lies about a key.
But the offline / reliability / single-point-of-trust problems push the WEB toward a different design: certificates, which let the trusted party go OFFLINE.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'The key is PUBLIC anyway, so Bob can just shout it over the channel — there's no secret to protect.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: 'Public' protects against eavesdropping the key, not against SUBSTITUTION of it.
A student: what property must the key delivery actually guarantee?
Why: 'Public' protects against eavesdropping the key, not against SUBSTITUTION of it. Mallory swaps in her own public key and becomes a man-in-the-middle. The threat is integrity/authenticity, not confidentiality.
Trap
A student: 'The key is PUBLIC anyway, so Bob can just shout it over the channel — there's no secret to protect.'
Accept the key that arrives on the wire as Bob's
Why: Wrong. 'Public' protects against eavesdropping the key, not against SUBSTITUTION of it. Mallory swaps in her own public key and becomes a man-in-the-middle. The threat is integrity/authenticity, not confidentiality.
A student: what property must the key delivery actually guarantee?
Require the key be AUTHENTICATED to Bob's identity, not merely received
Why: §13.1: you need a trusted binding of name→key (a directory or a certificate). Without authenticity, an active attacker substitutes keys freely — secrecy of a public value was never the issue.
Section
Part 2 · §13.3 a signed binding
Concept
A certificate is a signed statement, made by some certifying party, binding a NAME to a PUBLIC KEY. It uses exactly the digital signatures of L30.
Digital certificate — A statement of the form 'name X's public key is K', digitally signed by a certifying party using ITS private key. Anyone holding the certifier's public key can verify the signature and thereby trust the name→key binding.
Socratic
Discussion prompt
A certificate is a signed statement, made by some certifying party, binding a NAME to a PUBLIC KEY. It uses exactly the digital signatures of L30.
Suppose that were not true. What is the first thing in L31 · Certificates, PKI, Chains, Revocation & Web of Trust that would stop working?
Hint: Follow it one step downstream. The answer is whatever was quietly relying on it.
Answer:
Digital certificate: A statement of the form 'name X's public key is K', digitally signed by a certifying party using ITS private key. Anyone holding the certifier's public key can verify the signature and thereby trust the name→key binding.
Concept
Suppose Governor Jerry Brown is well-known and holds a private key. He can certify David Wagner's public key by signing a statement about it:
\[ \{\,\text{“David Wagner's public key is } \mathtt{0x092...3F}\text{”}\,\}_{SK_{\text{Jerry}}} \]
Anyone who knows Jerry's public key can verify this signature. If it checks out, they learn David's authentic key — vouched for by Jerry.
Concept
The crucial property: the certificate carries its own proof. Its integrity comes from the signature, not from how it was delivered.
Self-validating — A certificate can be obtained from ANY untrusted source over an INSECURE channel — Google it, read it off a whiteboard, get it from David himself — and still be trusted, because tampering would break Jerry's signature. The channel need not be secure.
So Alice no longer needs to contact a directory in real time. She needs only (1) Jerry's authentic public key and (2) trust that Jerry signs carefully.
Intuition
Think of a certificate like a notarized document. You don't care WHO hands you the notarized page or how it reached you — you check the notary's seal. A forged or altered page fails the seal.
Mallory can intercept and re-deliver the certificate all she likes; she cannot change the name or key inside without invalidating Jerry's signature, and she can't forge a new one without Jerry's private key (L30).
Ask yourself: this fixes the directory's 'online' problem — why? (The certifier signs ONCE, offline; Alice can verify anytime, from any source, without contacting anyone.)
Ranking
Put in order
Put the moves of §13.3 Alice verifies David's certificate into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. The source is untrusted and the channel insecure; that's fine, because the certificate is self-validating — integrity will come from the signature, not the channel.
Worked example
Alice obtains the certificate from any source — say she downloads it off David's homepage over plain HTTP
Why: The source is untrusted and the channel insecure; that's fine, because the certificate is self-validating — integrity will come from the signature, not the channel.
Alice already holds Jerry's authentic public key; she verifies Jerry's signature on the certificate
Why: Using Verify(PK_Jerry, statement, signature) from L30. If Mallory altered the name or key, the signature check fails.
\[ \mathrm{Verify}\big(PK_{\text{Jerry}},\ \text{“David's key is } \mathtt{0x092...3F}\text{”},\ S\big) = \text{true} \]
Verify: the signature is valid, so Alice accepts David's public key as 0x092...3F
Why: §13.3: she trusts the binding because (1) Jerry's signature is valid and (2) she trusts Jerry to certify carefully. No directory query, no secure channel — the certificate authenticated itself.
Notation
Annotate
From §13.3 Alice verifies David's certificate — read this one piece at a time. What is each part doing?
On: \( \mathrm{Verify}\big(PK_{\text{Jerry}},\ \text{“David's key is } \mathtt{0x092...3F}\text{”},\ S\big) = \text{true} \)
Trap
A student: 'I have to fetch David's certificate over TLS / a confidential channel, or an attacker could tamper with it.'
Insist on a secure, confidential channel to download the certificate
Why: Wrong. A certificate is SELF-VALIDATING: its integrity comes from the signature. Any tampering breaks the signature, so an insecure channel is perfectly safe. Confidentiality is irrelevant — the contents are public.
A student: what do you actually need to trust a certificate?
Just verify the signer's signature with the signer's authentic public key
Why: §13.3: integrity is enforced by the signature, not the channel. You may grab the certificate from a stranger, a whiteboard, or Google — only the certifier's authentic key and your trust in them matter.
Section
Part 3 · §13.4 the HTTPS trust model
Concept
Generalize 'Jerry' into a dedicated role: a certificate authority (CA) whose whole job is issuing certificates. If Alice trusts a CA and the CA signed Bob's certificate, Alice gets Bob's key.
Certificate authority (CA) — A trusted party that verifies identities and issues signed certificates binding names to public keys. The CA's own public key is hardcoded into applications and browsers, so clients can verify the certificates it signs.
Socratic
Discussion prompt
Generalize 'Jerry' into a dedicated role: a certificate authority (CA) whose whole job is issuing certificates. If Alice trusts a CA and the CA signed Bob's certificate, Alice gets Bob's key.
Suppose that were not true. What is the first thing in L31 · Certificates, PKI, Chains, Revocation & Web of Trust that would stop working?
Hint: Follow it one step downstream. The answer is whatever was quietly relying on it.
Answer:
Certificate authority (CA): A trusted party that verifies identities and issues signed certificates binding names to public keys. The CA's own public key is hardcoded into applications and browsers, so clients can verify the certificates it signs.
Concept
This is how the web works. A site buys a certificate from a CA binding its DOMAIN (e.g. www.amazon.com) to the site's public key.
Concept
Here's the dangerous part. A browser will accept a certificate for any domain signed by any of its ~88 trusted CAs. There is no rule that 'only amazon's CA may certify amazon.com.'
So if just ONE of those CAs is compromised or malicious, it can issue a perfectly valid certificate for amazon.com — and browsers will accept it. The more CAs you trust, the larger your attack surface.
Sorting
Sort into buckets
These are the pieces of L31 · Certificates, PKI, Chains, Revocation & Web of Trust, out of order. Put each one back under the part of the lesson it belongs to.
Intuition
Your security against a forged amazon.com certificate is NOT the strongest CA — it's the WEAKEST. You're vulnerable if ANY one of the ~88 fails.
It's like a building with 88 master keys held by 88 different companies. Adding a 89th company doesn't make the building safer — it adds one more way in.
Ask yourself: does trusting more CAs give users more 'choice' and safety? (No — each added CA is another single point of TOTAL failure for every domain.)
Ranking
Put in order
Put the moves of §13.4 A browser validates amazon.com into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. The site presents the certificate it bought; the browser must decide whether to trust it.
Worked example
Browser connects to www.amazon.com and receives a certificate signed by some CA
Why: The site presents the certificate it bought; the browser must decide whether to trust it.
Browser checks the signing CA is in its trusted list, then verifies the CA's signature
Why: It uses the CA's hardcoded public key. A valid signature means the certificate's contents weren't altered and the CA vouches for them.
Browser confirms the certificate's domain field equals www.amazon.com
Why: Domain matching stops a valid certificate for evil.com from being accepted for amazon.com — the name binding must match the site visited.
Verify: signature valid AND domain matches AND CA trusted → connect; otherwise warn the user
Why: §13.4: all three must hold. But note the gap — if ANY trusted CA (not just amazon's) signed this certificate for amazon.com, it passes. That's the weakest-link risk.
Blank canvas
Draw it
Draw what §13.4 A browser validates amazon.com just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Trusting 88 CAs is safer than trusting 5 — more authorities means more coverage and redundancy.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: ANY trusted CA can sign for ANY domain, so each CA is an independent single point of TOTAL failure.
A student: how does the size of the trust store affect risk?
Why: ANY trusted CA can sign for ANY domain, so each CA is an independent single point of TOTAL failure. More CAs = more parties who can forge a certificate for amazon.com. Trust here is a weakest-link, not a strongest-link, property.
Trap
A student: 'Trusting 88 CAs is safer than trusting 5 — more authorities means more coverage and redundancy.'
Add CAs to the trust store to increase 'coverage'
Why: Wrong. ANY trusted CA can sign for ANY domain, so each CA is an independent single point of TOTAL failure. More CAs = more parties who can forge a certificate for amazon.com. Trust here is a weakest-link, not a strongest-link, property.
A student: how does the size of the trust store affect risk?
Recognize the attack surface GROWS with each trusted CA
Why: §13.4: a browser accepts a certificate for any domain from any trusted CA, so one compromised CA among 88 can impersonate any site. Fewer, well-audited CAs (plus mechanisms like ⊕ Certificate Transparency) reduce the risk.
Section
Part 4 · §13.5 delegating trust
Concept
A single CA can't personally verify and sign 200,000+ keys. The fix: a hierarchy. A root CA certifies intermediate CAs, who certify others, in a tree.
Certificate chain — A sequence of certificates in which each one certifies the public key that signs the next. Trust is anchored at the ROOT (whose key is hardcoded) and flows down link by link to the leaf (the end entity's key).
Concept
A worked hierarchy from the textbook: Jerry (root) → certifies Napolitano (UC president) → certifies Dirks (UCB chancellor) → certifies Katz (EECS chair) → certifies a professor.
Each certificate authenticates the public key that signs the NEXT one down. This particular chain has length 4 — four certificates from the root to the professor's key.
Intuition
You only hardcode ONE key — Jerry's (the root). Everything else you learn by following signatures: Jerry's signature proves Napolitano's key, Napolitano's proves Dirks's, and so on down to the professor.
Like a chain of introductions: you trust the root; the root introduces the next person, who introduces the next. Each handoff is a verified signature, not a leap of faith.
Ask yourself: if any single signature in the chain doesn't verify, what happens? (The chain breaks there — you can't trust that link or anything below it.)
Socratic
Discussion prompt
Like a chain of introductions: you trust the root; the root introduces the next person, who introduces the next. Each handoff is a verified signature, not a leap of faith.
Suppose that were not true. What is the first thing in L31 · Certificates, PKI, Chains, Revocation & Web of Trust that would stop working?
Hint: Follow it one step downstream. The answer is whatever was quietly relying on it.
Ranking
Put in order
Put the moves of §13.5 Validate the chain, root → leaf into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. The root is the one key trusted a priori; every other key is earned by a verified signature from the level above.
Worked example
Start at the anchor: Alice has Jerry's (root) public key hardcoded and trusted
Why: The root is the one key trusted a priori; every other key is earned by a verified signature from the level above.
| link | certificate (signed by) | authenticates the key of |
|---|---|---|
| 1 | signed by Jerry (root) | Napolitano (UC) |
| 2 | signed by Napolitano | Dirks (UCB) |
| 3 | signed by Dirks | Katz (EECS) |
| 4 | signed by Katz | the professor (leaf) |
Verify each certificate's signature using the key established by the link above it
Why: Each Verify uses the public key just authenticated. A failure anywhere invalidates that link and everything below it.
Verify: all four signatures check out, so the professor's key is authenticated
Why: §13.5: trust anchored at the root flowed down through every link. Alice trusts the leaf key without the root ever having signed it directly — delegation is what makes PKI scale.
Comparison
Comparison matrix
From §13.5 Validate the chain, root → leaf: refill the certificate (signed by) column from what you know. The rest of the table is as it appeared.
| link | certificate (signed by) | authenticates the key of |
|---|---|---|
| 1 | signed by Jerry (root) | Napolitano (UC) |
| 2 | signed by Napolitano | Dirks (UCB) |
| 3 | signed by Dirks | Katz (EECS) |
| 4 | signed by Katz | the professor (leaf) |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'A chain is just a list of certificates, so I can drop in any certificate I find and the chain still works.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Each link must be VALIDLY SIGNED by the key authenticated in the link above it.
A student: what makes a chain a valid chain, not just a pile of certificates?
Why: Each link must be VALIDLY SIGNED by the key authenticated in the link above it. A certificate signed by some random party — not the previous link — doesn't connect; the chain is broken and trust never reaches the leaf.
Trap
A student: 'A chain is just a list of certificates, so I can drop in any certificate I find and the chain still works.'
Accept a certificate whose signer isn't the previous link's authenticated key
Why: Wrong. Each link must be VALIDLY SIGNED by the key authenticated in the link above it. A certificate signed by some random party — not the previous link — doesn't connect; the chain is broken and trust never reaches the leaf.
A student: what makes a chain a valid chain, not just a pile of certificates?
Each certificate must be signed by the key the PREVIOUS certificate authenticated, anchored at the trusted root
Why: §13.5: trust is delegated link by link from the root. You don't trust every party 'equally' or arbitrarily — you verify an unbroken signature path from the hardcoded root down to the leaf.
Section
Part 5 · §13.6 expiry and CRLs
Concept
A basic certificate, once issued, is valid forever. That's a disaster if it was issued in error or the private key was stolen — there's no built-in way to take it back.
Revocation — The act of invalidating a certificate before it would naturally stop being trusted. Basic certificates have NO revocation mechanism; revocation must be added on top, and every approach carries real tradeoffs.
Concept
Real case: Verisign mistakenly issued certificates labeled 'Microsoft Corporation' to an impostor. There was no way to revoke them.
Microsoft had to patch Windows with the bogus certificates hardcoded, so the OS would reject them. That only worked because Microsoft could push software updates to every machine — not a general solution.
Concept
Give every certificate an expiration date. After it expires, it's no longer trusted, so a bad certificate self-destructs eventually.
Validity period — An expiration date baked into the certificate. Short lifetimes give fast effective revocation but force frequent re-issuance (heavy load, reliability risk). Long lifetimes scale well but make a bad certificate linger.
Concept
The CA publishes a signed, dated list of certificates it has revoked. Clients download it periodically and reject anything on the list.
Certificate revocation list (CRL) — A list of revoked certificates, signed and dated by the CA. Clients fetch it regularly and check each certificate against it. Frequent downloads = fresher data but heavier load; a DoS on the CRL server forces a dilemma.
Socratic
Discussion prompt
The CA publishes a signed, dated list of certificates it has revoked. Clients download it periodically and reject anything on the list.
Suppose that were not true. What is the first thing in L31 · Certificates, PKI, Chains, Revocation & Web of Trust that would stop working?
Hint: Follow it one step downstream. The answer is whatever was quietly relying on it.
Answer:
Certificate revocation list (CRL): A list of revoked certificates, signed and dated by the CA. Clients fetch it regularly and check each certificate against it. Frequent downloads = fresher data but heavier load; a DoS on the CRL server forces a dilemma.
Intuition
CRLs create a nasty bind. Download often → always fresh, but huge load on the CRL server. Download rarely → light load, but there's a WINDOW where a revoked certificate still looks valid.
Worse, an attacker can DoS the CRL server. Now the client must choose: keep using the STALE list (an attacker window opens) or reject EVERYTHING (the attacker has DoSed every user offline). Neither is good.
Ask yourself: validity periods vs CRLs — which one needs the client to be online to revoke quickly? (CRLs — you must fetch the latest list; expiry needs no network but revokes slowly.)
Explain it
Discussion prompt
Explain §13.6 The freshness-vs-availability dilemma to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
CRLs create a nasty bind. Download often → always fresh, but huge load on the CRL server. Download rarely → light load, but there's a WINDOW where a revoked certificate still looks valid.
Pattern
Predict first
The table runs: how revocation happens | wait for expiry | add to CA's signed list · speed of revocation | slow (until expiry) | fast (next CRL fetch) · tradeoff knob | lifetime length | fetch frequency · short / frequent | fast revoke, heavy re-issue | fresh, heavy download load · long / infrequent | scales, slow to revoke | light load, stale window
In §13.6 Compare the two revocation tools, given the rows so far: what is the next one — the row where property is DoS exposure?
Correct: DoS exposure | low (no live server needed) | high (stale-vs-reject dilemma)
| property | validity period (expiry) | revocation list (CRL) |
|---|---|---|
| how revocation happens | wait for expiry | add to CA's signed list |
| speed of revocation | slow (until expiry) | fast (next CRL fetch) |
| tradeoff knob | lifetime length | fetch frequency |
| short / frequent | fast revoke, heavy re-issue | fresh, heavy download load |
| long / infrequent | scales, slow to revoke | light load, stale window |
| DoS exposure | low (no live server needed) | high (stale-vs-reject dilemma) |
Why: The relationship between the columns, not the individual numbers, is what generates the next row. The right choice depends on which tradeoff a deployment can tolerate; neither dominates.
Worked example
Lay out validity periods vs CRLs along the speed / load / availability axes
Why: The right choice depends on which tradeoff a deployment can tolerate; neither dominates.
| property | validity period (expiry) | revocation list (CRL) |
|---|---|---|
| how revocation happens | wait for expiry | add to CA's signed list |
| speed of revocation | slow (until expiry) | fast (next CRL fetch) |
| tradeoff knob | lifetime length | fetch frequency |
| short / frequent | fast revoke, heavy re-issue | fresh, heavy download load |
| long / infrequent | scales, slow to revoke | light load, stale window |
| DoS exposure | low (no live server needed) | high (stale-vs-reject dilemma) |
Verify: neither approach is free — each trades revocation speed against load and availability
Why: §13.6: short validity periods and frequent CRL fetches both buy freshness at the cost of load/reliability. Real systems mix them (and add ⊕ OCSP/stapling) to balance the dilemma.
Comparison
Comparison matrix
From §13.6 Compare the two revocation tools: refill the revocation list (CRL) column from what you know. The rest of the table is as it appeared.
| property | validity period (expiry) | revocation list (CRL) |
|---|---|---|
| how revocation happens | wait for expiry | add to CA's signed list |
| speed of revocation | slow (until expiry) | fast (next CRL fetch) |
| tradeoff knob | lifetime length | fetch frequency |
| short / frequent | fast revoke, heavy re-issue | fresh, heavy download load |
| long / infrequent | scales, slow to revoke | light load, stale window |
| DoS exposure | low (no live server needed) | high (stale-vs-reject dilemma) |
Concept
⊕ Supplemental — beyond §13.6. Real web PKI layers on more mechanisms to ease the CRL dilemma and catch mis-issuance:
Trap
A student: 'If a certificate is compromised, the CA just flips a switch and it's revoked everywhere immediately.'
Assume instant, universal revocation is built in
Why: Wrong. A basic certificate is valid FOREVER with no revocation at all (recall Verisign couldn't revoke the bogus Microsoft certificates). Revocation is an ADD-ON: validity periods revoke slowly; CRLs depend on clients fetching fresh lists and can be DoSed.
A student: what does revocation actually require, and what does it cost?
Recognize revocation is bolted on, with a speed-vs-load-vs-availability tradeoff
Why: §13.6: without an extra mechanism a certificate can't be undone; expiry is slow, CRLs need timely fetches and create the stale-vs-reject dilemma under DoS. 'Instant universal revocation' isn't free or automatic.
Section
Part 6 · §13.7–13.8 decentralized trust
Concept
PGP took a different route: abolish the central authority. In a web of trust, each person signs certificates for people they personally know, and trust propagates through chains of mutual acquaintances.
Web of trust — A decentralized PKI (used by PGP) with no central CA. Each user acts as their own certifier, signing keys for people they know; to trust a stranger's key, you find a chain of intermediaries you trust connecting you to them.
Concept
Trust between people doesn't behave like a clean math relation, which breaks the model in two ways:
These mismatches, plus poor usability, have badly hampered the web of trust's adoption.
Analogy
Discussion prompt
Explain §13.7 Two reasons the web of trust is hard by analogy to something with no Computer Security in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
Trust between people doesn't behave like a clean math relation, which breaks the model in two ways:
Concept
A third, pragmatic model — used by SSH. On the first connection you simply ACCEPT the server's key, remember it, and alert loudly if it ever changes later.
Leap-of-faith / TOFU — Trust On First Use: accept and pin a key on the first connection with no prior authentication, then warn if it ever changes. Vulnerable to a man-in-the-middle on that FIRST connection, but it stops passive eavesdroppers and any attacker who shows up later.
Intuition
TOFU trades a little security for a lot of usability. If you're not under attack at the exact moment of first connection (usually true), you're fine forever after — any later attacker triggers the 'key changed!' warning.
It exemplifies two CS 161 design principles: one mode, and it's secure (no confusing options) and users shouldn't need to understand crypto to be protected (callback to §1 usability).
Ask yourself: against which attacker is TOFU weakest? (An ACTIVE man-in-the-middle present on the very FIRST connection — there's no prior key to compare against.)
Counterexample
Discussion prompt
Ask yourself: against which attacker is TOFU weakest? (An ACTIVE man-in-the-middle present on the very FIRST connection — there's no prior key to compare against.)
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'SSH remembers the host key and warns on changes, so TOFU protects me against all man-in-the-middle attacks.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: On the FIRST connection there's no stored key to compare against, so a man-in-the-middle present right then can substitute its own key and you'd pin the ATTACKER's key.
A student: what exactly does TOFU protect against, and what's the gap?
Why: On the FIRST connection there's no stored key to compare against, so a man-in-the-middle present right then can substitute its own key and you'd pin the ATTACKER's key. TOFU is insecure to a first-connection MITM.
Trap
A student: 'SSH remembers the host key and warns on changes, so TOFU protects me against all man-in-the-middle attacks.'
Assume TOFU defends even the first connection
Why: Wrong. On the FIRST connection there's no stored key to compare against, so a man-in-the-middle present right then can substitute its own key and you'd pin the ATTACKER's key. TOFU is insecure to a first-connection MITM.
A student: what exactly does TOFU protect against, and what's the gap?
Trust on first use stops passive eavesdroppers and any LATER attacker — but not a first-connection MITM
Why: §13.8: once a key is pinned, any change triggers a warning, so later attackers are caught and passive snoops never had the key. The one window is an active attacker on the initial connection.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Alice trusts Bob, Bob trusts Carol, so the web of trust automatically makes Alice trust Carol's key.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Trust isn't transitive: trusting Bob to verify keys doesn't mean you endorse everyone BOB endorses.
A student: how should trust propagate through a web of trust?
Why: Trust isn't transitive: trusting Bob to verify keys doesn't mean you endorse everyone BOB endorses. Trust also isn't absolute — you may trust someone for one thing and not another. Blindly chaining trust is exactly the web of trust's weakness.
Trap
A student: 'Alice trusts Bob, Bob trusts Carol, so the web of trust automatically makes Alice trust Carol's key.'
Chain trust automatically through intermediaries
Why: Wrong. Trust isn't transitive: trusting Bob to verify keys doesn't mean you endorse everyone BOB endorses. Trust also isn't absolute — you may trust someone for one thing and not another. Blindly chaining trust is exactly the web of trust's weakness.
A student: how should trust propagate through a web of trust?
Treat each trust relationship as limited and non-automatic; decide deliberately how far to extend it
Why: §13.7: trust is neither transitive nor absolute. PGP lets users set how much they trust an introducer and how many endorsements a key needs — precisely because trust doesn't chain by itself.
Two truths and a lie
Sort into buckets
Some of these hold up and some are the exact mistakes this lesson is built to prevent. Sort them.
Constraint
Discussion prompt
Run The certificates & PKI playbook with this step confiscated:
PKI / CAs: browsers hardcode ~88 CAs; any trusted CA can certify any domain, so each added CA is a single point of total failure (§13.4).
Is it still possible? If it is, say what takes its place and what it costs you. If it is not, say exactly what that step was providing that nothing else does.
Hint: A step you can drop for free was never load-bearing. If you cannot drop it, name the thing that goes wrong the moment it is gone.
Answer:
Pattern
Edge cases
Discussion prompt
The certificates & PKI playbook works on the cases you have just seen. Push it to the edge: what is the most degenerate input it still handles — empty, zero, one item, everything equal — and what is the first case where it stops being true? Name the case, not just "it breaks".
Hint: Try the smallest legal input, then the largest, then the one where two things collide. Methods are specified at their edges; the middle takes care of itself.
Answer:
Elimination
Eliminate the wrong options
Which statement about this certificate and the web PKI is TRUE?
3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.
Survives elimination: C
Why: §13.3–13.6: a certificate is self-validating — its integrity comes from the CA's signature, so Alice can fetch it over any insecure channel and just verify the signature with the CA's hardcoded public key. But the web PKI's weakness is that a browser accepts a certificate for any domain from ANY of its ~88 trusted CAs, so one compromised CA can forge a valid certificate for bob.com (more CAs = more risk, not less). And a basic certificate is valid forever: revocation is an add-on (validity periods or CRLs) with real speed-vs-load-vs-availability tradeoffs, not an instant universal switch.
Check
Alice downloads Bob's certificate (a CA-signed binding of bob.com → Bob's public key) over plain HTTP from a random mirror. Think through what's true before you choose.
Check your understanding
Which statement about this certificate and the web PKI is TRUE?
Answer: C
Why: §13.3–13.6: a certificate is self-validating — its integrity comes from the CA's signature, so Alice can fetch it over any insecure channel and just verify the signature with the CA's hardcoded public key. But the web PKI's weakness is that a browser accepts a certificate for any domain from ANY of its ~88 trusted CAs, so one compromised CA can forge a valid certificate for bob.com (more CAs = more risk, not less). And a basic certificate is valid forever: revocation is an add-on (validity periods or CRLs) with real speed-vs-load-vs-availability tradeoffs, not an instant universal switch.
Concept
Concept
Concept
Connect it up
Draw it
One page, no notation unless you need it: draw how these connect — The Authenticity Problem & the Directory · Digital Certificates — Self-Validating Keys · PKI & Certificate Authorities · Certificate Chains & Hierarchical PKI · Revocation — Undoing a Certificate · Web of Trust & Leap-of-Faith. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.
Recap
You can now state the public-key authenticity problem and why a directory falls short, explain a certificate as a self-validating signed name→key binding, describe the CA / HTTPS model and why every trusted CA is a single point of failure, trace a certificate chain root→leaf, compare revocation by validity periods vs CRLs, and contrast the web of trust with leap-of-faith / TOFU.
| Idea | § | The one-line version |
|---|---|---|
| The problem | 13.1 | Get an authentic key over a channel Mallory controls |
| Trusted directory | 13.2 | Central name→key server; trust/scale/reliability/online/security costs |
| Certificate | 13.3 | Signed name→key binding; self-validating over any channel |
| PKI / CAs | 13.4 | ~88 CAs; any CA can sign any domain = weakest-link risk |
| Certificate chain | 13.5 | Root→leaf, each link signed by the previous; anchor at root |
| Revocation | 13.6 | Expiry (slow) or CRL (freshness-vs-availability, DoS dilemma) |
| Web of trust / TOFU | 13.7–13.8 | No CA (trust not transitive/absolute); TOFU safe except first connection |
Want this taught 1-on-1? Alexander tutors Computer Security — $55/session, free consultation.