[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PGP Keyserver Synchronization Protocol



-----BEGIN PGP SIGNED MESSAGE-----

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

> In <Pine.GSO.4.02A.9906222239500.23439-100000@hardees.rutgers.edu>, on
> 06/22/99 
>    at 10:46 PM, Tony Mione <mione@hardees.Rutgers.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@noc.rutgers.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-----