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

Re: PGP Keyserver Synchronization Protocol



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


See comments below.

On Fri, 18 Jun 1999, William H. Geiger III wrote:

> pgpk-sync-00.txt
> PGP Keyserver Synchronization Protocol -- Initial Proposal
> William H. Geiger III
> Geiger Consulting
> whgiii@openpgp.net
> http://www.openpgp.net
> 01 June 1999
> 
> 
> 
> 	This protocol is designed to allow the synchronization of 2 PGP Keyserver
> Databases with the minimal of overhead and network traffic. It will allow
> 2 servers to detect exactly which keys in their databases are different or
> missing and only exchange those keys. This protocol can also be used by
> PGP clients to communicate with the servers to compair keys in their local
> keyring with those on the server and receive updates to their keys.
> 
> 
> Overview:
> 
> 	The synchronization process involves several steps:
> 
> 	Generation of Hash Tables
> 	Exchange of Hash Tables
> 	Comparison of Hash Tables
> 	Exchange of Keys
> 
> In this process one database is initiating the synchronization (client)
> while the other is the receiver of a synchronization request (server). To
> start the process the client will create a hash table of his database then
> he will request a hash table from the server. When the client receives the
> server's hash table he will compair it with his own and generate 3 lists:
> 
> 	#1 All Keys that are on the server but not on the client
> 	#2 All Keys that are on the client but not the server
> 	#3 All Keys that are on both client & server but have different hashes
> 
> The client will then request from the server all the keys in list #1 & #2
> and add thoses keys to it's database. Once this is done the client will

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? 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.

> 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.

> Now both servers should be synchronized.
> 
> Excultion lists:
> 
> 	It is common pratice among some PGP Keyserver operators to exclude some
> keys from their databases (a pratice I do not agree with). When doing the
> key exchange one may want to take into account the exclusion lists of the
> server and not send keys that the client has that matches this list.
> 
> FTP of Hash Tables:
> 
> 	A server may wish to periodically create a hash table (once a day) and
> store it on his FTP server. This way a client can download the hash table
> and do his syncronization without any action on the part of the server. A
> more practical approach may be for the servers to maintain a hash table in
> "real time" updating it every time keys are added or updated in the
> database.
> 
> 	Another approach would be for the servers to create a hash table once a
> week and then create daily hash tables that only contain the keys that
> have been added/uptated for that day.
> 
> 	I am rather flexable on this area and some testing in the field should
> provide the best mechanism for when the hash tables should be generate.
> 
> 
> Hash Table:
> 
> 	A hash table is a sorted index by keyID of all the keys contained in a
> PGP Database. The index contains only 2 fields; the 64bit keyID & 128bit
> MD5 hash of the key:
> 

Any reason for MD5? I understand the SHA-1 is longer. However, it is
thought to be a stronger hash the MD5 at this time. 

> 
>         	0000000000000000 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> 		0000000000000001 ABABABABABABABABABABABABABABABAB
> 		0000000000000002 CDCDCDCFCDCDCFCDCDCDCDCFCDCDCFCD
> 		0000000000000003 EDEDEDEDEDEDFEDEEDEDEDEDEDEDFEDE
> 
> 
> 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.

> 
> -- 
> ---------------------------------------------------------------
> William H. Geiger III  http://www.openpgp.net
> Geiger Consulting    Cooking With Warp 4.0
>....
> 

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.

iQCVAwUBN3BKewfNcGHdn+zRAQGQuAP/THOhi19z7MvYXhoueMG3gJz0S7xd8FLW
WZemwJLfImqhB/8xik7/AChUe+FOv96XEFPz/hbVHTrfoghvEe9Ls8Zk2Q1+4MKV
TLvTmdXB1af8lO0iyGiNOnRTgG0VuIaU4DcOSaQegQ+pFB/Mgc/PkldqPuWkVe/H
fSTGKh15COQ=
=f9Xf
-----END PGP SIGNATURE-----