Chapter 7 — Identity and access foundations | Technologist Quantum and post-quantum security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 7 — Identity and access foundations

Lesson map

Lesson 07 published. Map, example, EX013.

flowchart TD
  N0["Learning outcomes"]
  N1["7.1 Where signatures authenticate"]
  N2["7.2 Chains and trust stores"]
  N3["7.3 Order of changes"]
  N4["7.5 Practical activity"]
  N5["7.7 SSH host and user keys"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX013"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["7.1 Where signatures authenticate"]
  N2["7.2 Chains and trust stores"]
  N3["7.3 Order of changes"]
  N4["7.5 Practical activity"]
  N5["7.7 SSH host and user keys"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX013"]

[Learning outcomes]
    |
    v
[7.1 Where signatures authenticate]
    |
    v
[7.2 Chains and trust stores]
    |
    v
[7.3 Order of changes]
    |
    v
[7.5 Practical activity]
    |
    v
[7.7 SSH host and user keys]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX013]

Learning outcomes

You will (1) distinguish authentication from authorization in services; (2) explain certificates, chains and trust stores; (3) identify quantum-relevant signatures in SSO, mTLS, SSH and code signing; and (4) plan the order of post-quantum identity changes.

7.1 Where signatures authenticate

Users log in through SSO whose tokens are signed (RSA or ECDSA); services authenticate each other with mutual TLS certificates; administrators use SSH keys; CI pipelines sign artefacts; devices hold certificates for enrolment. Authorization (roles, policies) is not threatened by quantum computers; the signatures behind authentication are.

At KLS that list maps to concrete keys: the SSO provider's RS256 token key, the internal CA's ECDSA P-256 issuing key, administrators' Ed25519 SSH keys, the RSA-3072 release-signing key and the device-enrolment certificates on the scanners. Each gets a row with algorithm, lifetime and the system that verifies it, because the verifier usually limits migration more than the signer does.

7.2 Chains and trust stores

A certificate is trusted if it chains to a root in the verifier's trust store. Introducing a post-quantum root means updating every trust store first — operating systems, language runtimes, appliances, partner systems. Internal PKI is the best place to start post-quantum certificates because KLS controls both issuers and verifiers.

Partner systems are the slowest stores to change because KLS cannot push updates to them; any mTLS link to a partner needs the new root shipped and confirmed months ahead. Inside KLS, the container base-image CA bundle and the Java truststores in services are the stores most often missed, since they are built into artefacts rather than managed on hosts.

7.3 Order of changes

Start with items where forge-later risk is high and control is high: internal root and intermediates, code signing for long-lived artefacts. Leave short-lived tokens for later; their keys can rotate quickly once libraries support ML-DSA (FIPS 204). Public web certificates follow public CA and browser support.

The ordering has a practical benefit too. Internal roots and signing keys are few, owned by one team and changed in planned ceremonies, so they make good first projects. Thousands of leaf certificates and tokens follow automatically once issuers and verifiers support ML-DSA, so effort spent there early is mostly wasted waiting for libraries.

7.4 Worked example

KLS's identity inventory: SSO tokens RS256 (1-hour lifetime); service mTLS from internal CA (ECDSA P-256, 90-day leaves, 15-year root); SSH user keys Ed25519; release signing RSA-3072. Priority: internal root (long-lived, controlled), release signing (artefacts verified for years), then mTLS leaves, SSH and tokens.

The list also shows where KLS can prepare without new algorithms. Release signing can add a second signature slot to the artefact format now, so adding ML-DSA later is a pipeline change. SSH can move to certificates from a central authority so user keys rotate centrally. Neither step requires post-quantum support, and both shorten migration time later.

7.5 Practical activity

Draw KLS's internal PKI with root, intermediates and leaf types, and list every trust store that must accept a new root.

The drawing should show the 15-year root offline, at least one issuing intermediate, and leaf types for mesh services, ingress, monitoring agents and devices. Then list trust stores per relying party: host OS bundles, container image bundles, Java truststores, mesh sidecar trust bundles, monitoring agents, CI runners and any partner that verifies KLS certificates in mTLS. Mark which stores KLS updates by configuration and which only by rebuilding or by asking the partner. The longest of those paths sets the earliest safe date for issuing post-quantum leaves.

7.6 Common errors and limits

Issuing post-quantum leaves before trust stores accept the root.
Treating authorization data as quantum-vulnerable.
Forgetting partner trust stores.

In KLS's lab the first error produced exactly the expected result: a test leaf signed by an ML-DSA intermediate failed validation in every Java service, because their truststores had not received the new root. Spending effort on role mappings or authorization policies is the second error, since those are not cryptographic. The third is the slowest to fix: a partner that pins KLS's current root will reject a new chain until its own operators update it.

7.7 SSH host and user keys

SSH illustrates the split between key exchange and identity. Hybrid key exchange in OpenSSH protects session confidentiality now, while host keys and user keys remain classical signatures. Rotating host keys is operationally cheap if clients use certificates or managed known-hosts files, and expensive if every user has pinned individual keys. Moving administrators to SSH certificates issued by a central authority is therefore a useful agility step even before any post-quantum host-key algorithm is deployed.

KLS administrators currently trust host keys through individual known_hosts entries, so a host-key change produces warnings across the team. Moving to host certificates means one CA key in each client's configuration, and a later move to a post-quantum host-key algorithm becomes a CA change.

Exercises

EX013 — Prioritise. Order KLS's five identity items in this chapter's worked example by migration priority and justify. Rubric: 3 = order consistent with lifetime and control.
EX014 — Trust stores. List five trust stores KLS must update for a new internal root. Rubric: 3 = five plausible stores.

Synthesis

Signatures underpin authentication in SSO, mTLS, SSH and code signing. Post-quantum identity starts with internal roots and long-lived signing, after trust stores are prepared.

Continue studying — chapter 07 of 30

← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →