Part III · 1 — Trust and PKI

draft

The primitives guarantee that a message came from whoever holds a certain key. But how do you know that key really belongs to your bank, and not to an impostor? That is the trust problem — what the protocols resolve before any byte travels.

1.1 The problem still to solve

Part II showed how two strangers combine a secret (ECDHE) and prove authorship (signatures). But there is a hole: when Alice receives a public key saying "I am the bank", nothing in the math guarantees it is true. A man-in-the-middle attacker can deliver their own key.

Exchanging keys securely is solved; binding a key to an identity is what is missing. There are two historical answers:

  • Hierarchical (PKI) — trusted authorities attest who owns which

    key. It is the web's model.

  • Web of trust — users themselves sign each other's

    keys (PGP). More decentralized, but hard to scale.

1.2 Forward secrecy: why ephemeral keys

Before identity, a property of the key agreement itself: the exchange must use ephemeral keys (ECDHE — the final "E"), discarded after the session.

The reason is forward secrecy: if the server's long-term private key leaks tomorrow, all the traffic recorded in the past stays unreadable — because the session key that encrypted it no longer exists and cannot be re-derived. Without ephemerality (the old RSA key transport), a future leak opens the entire history. That is why TLS 1.3 only allows ephemeral exchange.

1.3 Certificates: a signed identity

A certificate is a document that says "this public key belongs to koder.dev" — signed by the private key of an authority. It is just a digital signature (Part II) applied to (identity + public key + validity).

If you trust the authority's public key, you can verify the signature and then trust the binding. Trust is delegated.

1.4 The chain of trust

Nobody trusts a single authority for everything. PKI forms a chain:

The chain of trust: root CA → intermediate → site certificate

  1. Root CA — a root authority whose certificate is self-signed and comes

    pre-installed in the operating system / browser (the trust store). It is the anchor.

  2. Intermediate CA — signed by the root; it is what actually issues day to

    day (the root stays offline, protected).

  3. Leaf certificate — the site's (koder.dev), signed by the intermediate.

On connecting, the server sends leaf + intermediate; the client validates the chain up to a root it trusts, checking signature, validity, revocation, and whether the name matches (SAN). A break in any link ⇒ the padlock does not close.

Where Koder fits in: Koder operates its own DNS and issuance (Koder Herald) and the identity plane (Koder ID). All communication is HTTPS only with a 301 redirect (policies/security.kmd) — the web's chain of trust is a prerequisite, not optional.

1.5 Revocation: when trust expires early

Certificates have a validity period, but sometimes a key leaks before it expires. Revocation mechanisms:

  • CRL (Certificate Revocation List) — lists of revoked certificates; heavy.
  • OCSP — online status query; with stapling, the server attaches the fresh

    proof, avoiding leaking to the validator which site you visit.

  • Short validity — the modern trend (certificates of ~90 days, ACME/

    Let's Encrypt) makes revocation almost unnecessary: the problem expires soon.

Dense reference: the validation chain, OCSP/CRL, and the history of compromised CAs are in 07-protocols. Next: TLS — where the key exchange, the symmetric cipher, the signature, and PKI come together in a single handshake.