From: p2p-hackers@zgp.org (Lucas Gonze)
Replying To: Brad Neuberg <p2p-hackers@zgp.org>
Date: Mon Jul 1 18:35:01 2002
Subject: [p2p-hackers] Distributed Timestamping Service

On Sun, 7 Jul 2002, Brad Neuberg wrote:
> Interesting idea.  I'm still trying to "grok" it.  I should have brought 
> up that this distributed timing service is living above a very 
> unreliable network; i.e. nodes pop into and out of existence quite often 
> (probably on the range that every hour over half the nodes are replaced).

I think that we can establish alternate routes along the directed graph, 
given luck.   So it comes down to how much churn and how long the timestamp 
chains need to be.

> In a sense it sounds like your idea is to create very long certificate 
> chains.  As time "clicks" on and the directed graph of nodes signing 
> nodes grows, won't it get longer and longer to "authenticate" that time, 
> or do I have a misunderstanding?

A signs B's key, B signs C's key.   There's an authenticated chain of 
events where A's key is known to exist before B's, and B's is known to 
exist before C's.  

The more you have to authenticate, the more of the network you have to 
traverse.   That doesn't mean that any one signature has to include all of 
the prior signatures.  Just like with a chain, a link only has to touch 
its nearest neighbors.  


> >Constantly establishing keys doesn't make sense.  The algorithm works 
> >just as well if there is a third bit of data, a use-once token.  Can that 
> >work?  Don't know.
> >  
> >
> What do you mean?

The older a key is, the less chronological data it provides.   For example 
if A's key is five minutes old, and it is used to sign B's key, then B's 
key is known to be no older than five minutes.  If A's key is a year old, 
the signature on B's key gives less exact information about when the 
signature on B's key happened.  So you need to keep generating keys to 
keep clock ticks reasonably fine grained.  

Generating keys is expensive.  Is there a cheat to reduce the expense? 

> Once 
> you have a crytographicly secure distributed time service you can use it 
> to create first come, first served bindings between pieces of data, such 
> as username to public key, or web site name to IP address. 

I wonder how much of this niche SPKI already fills?  Maybe that is a good 
place to start cannibalizing. 

- Lucas