ietf-openpgp
[Top] [All Lists]

Re: PGP Keyserver Synchronization Protocol

1999-06-24 05:00:18
-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 23 Jun 1999, William H. Geiger III wrote:

In 
<Pine(_dot_)GSO(_dot_)4(_dot_)02A(_dot_)9906222239500(_dot_)23439-100000(_at_)hardees(_dot_)rutgers(_dot_)edu>,
 on
06/22/99 
   at 10:46 PM, Tony Mione <mione(_at_)hardees(_dot_)Rutgers(_dot_)EDU> said:

Overview:
...

I'm a bit confused here. List #2 contains all keys on the client that are
NOT on the server. How can the server send such a list? 

The server sends the entire hash list of all it's keys. The client, by
comparing the hash list it has generated locally, generates list #1, #2,
#3.


IF you meant list #3, how can you tell which keys from the server are
actually newer than the client keys. Just because they are different
does not mean that the server (rather than the requester) has the most
up-to-date copy of the key.

Yes, that text should have read: "all the keys in list #1 & #3"

There is no efficient way to determine who has the most up to date version
of a key. Hopefully, with periodic server synchronization, #3 should be a
small list.


This concerns me. It sounds non-deterministic. If that means that an older
copy of one of my keys may back-propagate to a server that has the correct
up-to-date copy, I would have a problem with this. I don't think it really
matters whether list 3 is large or small. You need to be correct about
which is the most recent copy of the key. This probably requires additional
thought (personally, I have always HATED dealing with database update
issues :)


generate a new hash table for his database and compair it to the hash
table he has from the server. He should now only have 2 lists:

   #1 All Keys on the client but not on the server
   #2 All Keys on the client & server but have different hashes

The client should then send the server all keys that are in the 2 lists.


Same comment about who really has the most up-to-date key.

Once the client has downloaded a key from the server and updated it's data
base, if the hashes are still different then the client must have the
"newer" data.


I'm being dense again, if the client has downloaded and updated it's
database, should not the hash now match (providing the hashing is done in a
defined order as you illustrate below?)

Calculating Hashes:

   It is important that when calculating the hash of a key that it be done
in a specific order as to guarentee that the identical key in two
different databases has the same hash. The following order of operation
for calculating the hash is:

   Primary Key
   SubKeys Sorted by KeyID
   Signatures Sorted by Signing KeyID
   UserID's Sorted Alphabeticaly

PhotoID's & X509 signatures are 2 issues that need to be looked into.
Unfortunatally the specs for neither of these packets have been released
by NAI. For right now I recomend that any propritary packets *not* be used
in the key hash calculations.


Does it really matter if you do not know the internal packet format as
long as you know where the packet ends? Hashing is simply mixing together
a stream of octets and so I do not believe the 'format' makes much of a
difference.

Well the problem of unknown and/or undocumented packet formats is that of
sorting. For two different systems to come up with the same hash for an
identical key, they must calculate the hash in the same manner. I have
outlined above how to do this with known OpenPGP packets. It is difficult
to set up similar procedures for packets who's format are unknown.


Sigh...
        Yeah, I see that. However, I agree it should be looked into. I
would like to know that adding a proprietary extension to a key block will
trigger an update at the next synchronization. If these are not included in
the hash, they keyblock will never propagate unless another (hashed) change
is made.



-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
...




Tony Mione, RUCS/TD, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
mione(_at_)noc(_dot_)rutgers(_dot_)edu                        W3: 
http://noc.rutgers.edu/~mione/
PGPFP:D4EEA987E870277C  24AAE6E9E6ABD088     ***** Important: Rom 10:9-11 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by mkpgp2.1, a Pine/PGP interface.

iQCVAwUBN3IeiQfNcGHdn+zRAQGVCAQAwCUHz2eFTo2q38KKe8rxOg4RGObSuDW2
REaMACGvY4uAQeJjBYYjOHv+vVx9J4YtSW+zyUy8vg85r4QjrX3568fUKzj1L7nk
JA8PZkJW8FgJLVzxYM4mQK1a1teLY0vAF/21uCfb8rST8e/WJNOEZf904GueJNKU
FzO2Ly0gUAk=
=D5Fv
-----END PGP SIGNATURE-----