Re: New proposal from Ronald J. Fitzherbert

[Kent Crispin <kent@songbird.com>]

Perry E. Metzger allegedly said:
> Simon Higgs writes:
> > I've never heard PGP-signed NTP stamps described as "idiotically
> > trivial" before.
> 
> I wouldn't recommend PGP signed NTP timestamps. They are trivial to
> forge. All they prove is that you claim that something happened at a
> particular time -- they don't prove that it actually happened at that
> time. If one really wants an unforgeable timestamping protocol, there
> is one, due to Haber and someone who's name I forget, but it requires
> a central third party, at which point one must ask why not just use a
> database since its simpler. (The timestamping protocol *is* pretty
> neat -- it involves a "widely witnessed event" in the form of a series
> of published hashes to demonstrate the ordering of events without
> anyone involved being able to deny the ordering -- but it really isn't
> any better than just using Oracle or something similar for this.)

Haber and Stornetta.  Total overkill for this application (as is 
Oracle).  Their algorithm, as I understand it, dealt with the problem 
of extremely fine-grain time resolution, where the time spent going 
to a central server for the time would be of the same order as the 
desired time resolution, which *is* a tricky problem.


But not the problem at hand.  Here the problem is at a much coarser 
level of resolution (if not, then a central database would be useless 
as well.)

Let me run through the algorithm, just to be sure we are on the same
page: Customer Erasmus Q.  Tinkerput comes into a remote registry R,
and requests "foo.tld".  R puts the string "Erasmus Q.  Tinkerput
wants foo.tld" in a file, and signs the file using R's private key.  R
then transmits the file to the Neutral Third Party, which appends the
date and time to the end of the file, signs it with the NTP's private
key, and sends it back.  (Perhaps NTP has an atomic clock, but the
time really doesn't need to be accurate, just monotonic).

Now R has a signed file demonstrating the date and time which his
customer requested the domain.  Now a copy of this signed document
goes into the 30 day waiting queue.  At the end of the 30 day period R
scans the queue for any competing claims to "foo.tld".  If there are 
none, or any that are there have later dates, then Mr. Tinkerput gets
foo.tld.  Note that the 30 day wait is not really necessary for the 
algorithm.

Please don't be put off by the informal presentation, and all the 
human involvement -- I am just presenting the algorithm, and in 
practice it would all be automated except, perhaps, the collection 
and verification of the contact data.

This really is a trivial protocol.  I believe it works, and can be
implemented in a day -- perhaps I will do it this weekend, just for
grins.

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com,kc@llnl.gov		the thief he kindly spoke...
PGP fingerprint:   5A 16 DA 04 31 33 40 1E  87 DA 29 02 97 A3 46 2F