Efficient Fault-Tolerant
Certificate Revocation
Rebecca Wright AT&T Labs
Patrick Lincoln SRI International
Jonathan Millen 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
Certificate Forwarding - Web of
Trust
Owner
User
User
Certificate
Server
User
User
User
User
User
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
Revocation Notice
Owner
?
Server
?
User
?
?
First problem: remember to whom the certificate was sent
Non-Redundant Depender Graph
Owner
User
User
Revocation Notice
Server
User
- Just like forwarding graph
- But what if a node fails?
User
User
User
User
Temporary Failure
Owner
User
User
Revocation Notice
Server
User
- Some users are not notified
- Solution: redundant paths
User
User
User
k-Redundant Depender Graph (k-RDG)
k parents per body node
Example, k = 2
User
User
Owner
ROOT NODE
Server
User
User
User
User
User
Theorem: k -1 node failures cannot
disconnect any body node
Flooding protocol: send revocations to all dependers
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
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
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