[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgp-keyserver-folk
Subject:    Re: PGP Keyserver Synchronization Protocol
From:       Tony Mione <mione () noc ! rutgers ! edu>
Date:       1999-06-30 18:27:04
[Download RAW message or body]

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

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

> In <Pine.GSO.4.02A.9906240749020.12077-100000@hardees.rutgers.edu>, on
> 06/24/99 
>    at 08:03 AM, Tony Mione <mione@hardees.Rutgers.EDU> said:
> 
> >-----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 :)
> 
> This is not a problem because of the mechanism of how PGP handles keys.
> Nothing is ever removed from a PGP key it is only added to. If a key in #3
> is not the "newer" key it means that it has *less* packets than the key on
> the client with the "newer" key. When this "older" key is merged into the
> database nothing will change.
> 
> Example:
> 
> server #1 (server) has the following key:
> 
> KeyID  1111111111111111
> UserID John Doe
> Sig    John Doe
> 
> Hash   EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> 
> 
> server #2 (client) has the following key:
> 
> KeyID 1111111111111111
> UserID John Doe
> Sig    John Doe
> Sig    Jim Brown
> 
> Hash   FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> 
> 
> Now when the client compares the 2 hashes he knows that the key he has and
> the key the server has are different but he does not have anyway of
> knowing *why* they are different until he downloads the key. So the client
> does the following:
> 
> Download key from server #1
> Merge key to cleint data base
> 
> After merging the key in the client database we have:
> 
> KeyID 1111111111111111
> UserID John Doe
> Sig    John Doe
> Sig    Jim Brown
> 
> Hash   FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> 
> 
> Nothing has changed on the client machine as no new packets for the key
> were downloaded. The client can now assume that it has packets for the key
> that the server does not and uploades the his copy of the key back to the
> server.
>  
> 
> It is also important to note that it is possible for *both* server &
> client to have a "newer" key, ie each has packets on the key that the
> other does not have. Take the following example:
> 
> John Doe signs key #1 and uploads it to server #1
> Jim Brown signds key #1 and uploads it to server #2
> 
> Now server #1 & #2 both have packets for key #1 that the other does not
> have.
> 

OH, DUH!

So the hash is used to find candidates to be downloaded only. The actual
update operations is not a 'replace' but a 'merge'. This makes sense. Tnx.

> 
> >...
> 
> See my example above.

Got it.

> 
> >> >> Calculating Hashes:
> >> >> 
> >> >> 	It is important that when calculating the hash of a key that it be done
> >>...
> >>
> >> 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.
> 
> Well this is the problem of proprietary extensions. Not that I have a
> problem with different vendors adding things that are particular for their
> needs but they need to document them if they expect others to be able to
> process them. I think that both the X509 sigs & the PhotoID's can be
> accommodated without too much fuss, I have not had the time to dig into
> their formats yet. In any case the system need to have a mechanism of what
> to do if it encounters packets it does not understand. IMHO the best thing
> to do is to ignore the packets in the hash calculations until they can be
> analyzed and the code modified to accommodate them. 
> 

Hmmm.

Here's an idea for proprietary tags. To at least note the presence of a
tag, could we hash in the tag value and length only (not the contents of
the packet.) This way, if a proprietary packet type is added, it will hash
differently then an older copy of the key and cause the key do be
downloaded. If the value of the contents is changed, it is likely the
length will change and again produce a different hash.

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

iQCVAwUBN3phaAfNcGHdn+zRAQF7+AP9F78AlUQ0TPSMVmPGb//edVkzzPR2Z5dz
yd6YNZTlOhJFiZoSX10ZA1vPVTsXmUMBW2/ShnVmFbjVR+B+ADxj4UxqwVQCdn1t
isYe6XpzPcIpy6eEx0x4jyXUr2bpBBf2NYsihjGQur6aFXHXPAnKlUEqKfFpuIzX
rX7jUKv0Fuo=
=jzW5
-----END PGP SIGNATURE-----

[prev in list] [next in list] [prev in thread] [next in thread]