Efficient Fault-Tolerant Certificate Revocation Rebecca Wright Patrick Lincoln Jonathan Millen AT&T Labs SRI International

Public Key Certificate Revocation Reasons for revocation: Key compromise or loss Change of employment or status Revocation certificate or notice - single ID of invalid certificate Signed by owner or introducer Available in PGP for web of trust Certificate revocation list (CRL) - multiple List of serial numbers of revoked certificates Signed by CA that authorized the certificates Either one must be distributed to relying parties

Owner ServerUser Certificate Owner User Certificate Forwarding - Web of Trust

Depender Graph Model Graph: nodes and directed edges One depender graph for each certificate Graph nodes are certificate holders Graph edges are communication links on which certificates are forwarded Owner of certificate is the graph root Graph is acyclic node edge

Parents and Dependers A B A is a parent of B B is a depender on A

Forwarding Revocation Notices Owner ServerUser Revocation Notice ? ? ? ? First problem: remember to whom the certificate was sent

Non-Redundant Depender Graph Owner ServerUser Revocation Notice - Just like forwarding graph - But what if a node fails? User

Temporary Failure Owner ServerUser Revocation Notice - Some users are not notified - Solution: redundant paths User

Owner ServerUser Theorem: k -1 node failures cannot disconnect any body node Flooding protocol: send revocations to all dependers k parents per body node Example, k = 2 ROOT NODE User k-Redundant Depender Graph (k-RDG)

Depender Graph Construction Construct k-RDG by adding nodes one at a time, starting with root and its dependers Assume each new node can support k dependers More is possible but not required New node added in relation to existing node Nodes have neighbor addresses only k parents must be found... how?

Finding Parents Definition: a node is “available” if its maximum number of dependers has not been allocated Theorem: any k available nodes can be used as the parents of a new node (A poor choice cannot prevent future nodes from being added) Theorem: there are k available nodes below any set of k nodes

Given start set of k nodes If each has an available slot, we are done Else one node has k dependers - use them as new start set recursively Procedure must terminate in finite acyclic graph Proof: Existence of k Available Nodes This is the basis of a protocol for parent search Start set: parents of attachment node Better: use highest available nodes to minimize average path length for forwarding

Finding k Parents 1. Identify attachment node 2. Start with its parents 3. Find available nodes below them

Example: “Triangular” Graph For k = 3

Reconfiguration After Permanent Failure After permanent failures Neighbor (parent, depender) information in each node is duplicated in one parent (or child?) Role of failed node is taken over by one of: last node added next node added a depender (recursive call to replace depender) But how is a failure detected? Unnecessary replacement is OK, restore node as new

Other Issues Protocol design issues Minimization of path length Updating revived nodes Reconfiguration around failed nodes Structure sharing over multiple certificates Multiple root (revocation) authority (in case of lost key, failure of owner, or higher authority) Realistic use of servers Edge failures Underlying network failures may disable many edges Other applications Certificate updates, re-keying, reliable multicast