[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.email@example.com>, on
> 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,
> >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
> >> 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
> 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.
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
> William H. Geiger III http://www.openpgp.net
Tony Mione, RUCS/TD, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
firstname.lastname@example.org 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-----
Comment: Processed by mkpgp2.1, a Pine/PGP interface.
-----END PGP SIGNATURE-----