notes: research/papers/where-trust-bottoms-out

This data as json

path title type status classification words body
research/papers/where-trust-bottoms-out Where Trust Bottoms Out: X.509, Certificate Transparency, and KERI's DPKI Architecture summary v0.1 — 2026-10-14: drafted by Claude from the web page (full text); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only partner 530 # Where Trust Bottoms Out: X.509, Certificate Transparency, and KERI's DPKI Architecture **Abstract.** A paper by Daniel Hardman comparing Public Key Infrastructure (PKI) with Certificate Transparency (CT) and the Key Event Receipt Infrastructure (KERI) as a decentralized PKI. It sets out what CT and KERI share, where their roots of trust differ, KERI's own tradeoffs, and how each would handle the transition to post-quantum cryptography. For practitioners who know X.509 and want to place KERI against it. ## Summary The paper opens from the claim that the internet has no native identity layer. Public Key Infrastructure (PKI) fills the gap administratively: Certificate Authorities (CAs) vouch for the binding between keys and entities. Section 1 describes the limits of that model, citing CA failures such as DigiNotar, Symantec, TrustCor and Entrust, and argues that mandatory certificate validity periods and shrinking lifetimes make identity evidence expire when nothing about the entity has changed. Section 2 treats Certificate Transparency (CT), the requirement that CAs publish issued certificates to append-only, verifiable logs, as a real improvement that detects misissuance but does not prevent it. It notes the window before logging, the risk of split views, weak revocation, and that CT redistributes administrative trust across log operators, monitors, browser root programs and the CA/Browser Forum. Section 3 lists what CT and KERI (Key Event Receipt Infrastructure) share: hash-linked append-only records, multi-party receipts, detection rather than prevention, and observer layers that someone must run. Section 4 describes KERI's different root of trust: self-certifying autonomic identifiers (AIDs), key event logs (KELs), pre-rotation, weighted multisignature, witnesses coordinated by KAWA (KERI's Algorithm for Witness Agreement), and watchers that detect duplicity. Section 5 states KERI's tradeoffs: thin formal analysis, the possibility of a malicious controller forking its own history, the cost of catastrophic key loss, and the dependence on disciplined witness and watcher operation. Section 6 compares the post-quantum transition: a global migration for PKI against per-identifier rotation for KERI, while noting KERI's immature tooling and legal recognition. The conclusion holds that "Both systems make fraud provable rather than impossible" (section 7): CT offers administrative accountability for an existing ecosystem, KERI cryptographic accountability for one still being built. ## Key terms PKI, Certificate Authority, Certificate Transparency, autonomic identifier (AID), key event log (KEL), pre-rotation, witnesses, watchers, KAWA, duplicity, DPKI ## Claims and their evidence - Certificate Transparency detects CA misissuance but does not prevent it, and redistributes rather than removes administrative trust [informative] - KERI identifiers need no authority to verify the key binding, because the identifier is derived from its initial key material [informative] - KERI's formal analysis is thin and its watcher practice is immature (stated by the author as a tradeoff) [informative] - The post-quantum transition costs PKI a coordinated global migration but KERI only per-identifier rotations [informative] - Several named CA failures (DigiNotar, Symantec, TrustCor, Entrust) illustrate the limits of administrative trust [informative] ## Related - Why X.509 Certs are Problematic (keri.one title; the paper 'Why X509 Certs Should Be Secondary Evidence of Org Identity') - Why Anchored Signatures? - KERI white paper ## Provenance Drafted by Claude on 2026-10-14 from the web page at dhh1128.github.io, read in full as text. Not yet read by Mark.

Links from other tables