Efficient Fault-Tolerant Certificate Revocation

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

2. 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

3. Certificate Forwarding - Web of Trust Owner Owner Certificate User Server User User User User User User

4. 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 edge node

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

6. Forwarding Revocation Notices Owner Revocation Notice ? Server User ? ? ? First problem: remember to whom the certificate was sent

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

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

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

10. 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?

11. 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

12. Proof: Existence of k Available 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 • 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

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

14. Example: “Triangular” Graph For k = 3

15. 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

16. 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