-----BEGIN PGP SIGNED MESSAGE-----
On Wed, 30 Jun 1999, William H. Geiger III wrote:
In
<Pine(_dot_)GSO(_dot_)4(_dot_)02A(_dot_)9906240749020(_dot_)12077-100000(_at_)hardees(_dot_)rutgers(_dot_)edu>,
on
06/24/99
at 08:03 AM, Tony Mione <mione(_at_)hardees(_dot_)Rutgers(_dot_)EDU> said:
-----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 :)
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(_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.
iQCVAwUBN3phaAfNcGHdn+zRAQF7+AP9F78AlUQ0TPSMVmPGb//edVkzzPR2Z5dz
yd6YNZTlOhJFiZoSX10ZA1vPVTsXmUMBW2/ShnVmFbjVR+B+ADxj4UxqwVQCdn1t
isYe6XpzPcIpy6eEx0x4jyXUr2bpBBf2NYsihjGQur6aFXHXPAnKlUEqKfFpuIzX
rX7jUKv0Fuo=
=jzW5
-----END PGP SIGNATURE-----