Subject: PGP Keyserver Synchronization Protocol

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 18 Jun 1999 09:43:36 -0500

pgpk-sync-00.txt
PGP Keyserver Synchronization Protocol -- Initial Proposal
William H. Geiger III
Geiger Consulting
[email-masked]
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
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.

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:

        	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.

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

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)
---------------------------------------------------------------

---

From: Tony Mione <[email-masked]>
Date: Tue, 22 Jun 1999 22:46:44 -0400 (EDT)

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

See comments below.

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

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

> PGP Database. The index contains only 2 fields; the 64bit keyID & 128bit

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. 

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

>....

Tony Mione, RUCS/TD, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[email-masked]                        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

---

From: Werner Koch <[email-masked]>
Date: Wed, 23 Jun 1999 09:55:41 +0200

> thought to be a stronger hash the MD5 at this time. 

Yes it is longer and therefore increasing the amount of bytes to
exchange.  I can't see a reason for a cryptographic strong hash algorithm
here - it is merely used as a checksum.  MD5 is good enough for this.

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

---

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 23 Jun 1999 10:28:49 -0500

In <[email-masked]>, on 06/23/99 

>here - it is merely used as a checksum.  MD5 is good enough for this.

Actually MD5 seems too large for this but I don't know a good replacement
that would be smaller than MD5 but still large enough to be collision
resistant.

Hi Jeff!! :)

---

From: "teun, Tilburg University" <[email-masked]>
Date: Wed, 23 Jun 1999 17:41:51 MET

Hi Tony,

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

It doesn't know to be a cryptographically strong hash here.

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

depending on the order in which a server received signatures in the past, a 
key may look quite different on different servers, although with sorted
sigs it is the same.

cheers,

teun

---

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 23 Jun 1999 09:47:50 -0500

In <[email-masked]>, on
06/22/99 

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

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

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

Hi Jeff!! :)

---

From: Paul Koning <[email-masked]>
Date: Wed, 23 Jun 1999 12:30:04 -0400

>>>>> "William" == William H Geiger <[email-masked]> writes:

 William> Actually MD5 seems too large for this but I don't know a
 William> good replacement that would be smaller than MD5 but still
 William> large enough to be collision resistant.

Too large in what sense?  If you want shorter, just truncate it.
That's what IPSEC does.  If you want faster, how collision resistant
does it have to be?  If you don't need a secure hash, how about CRC?
There's CRC-32 of course, nice and fast.  If you need longer, there's
CRC-64, don't know a good polynomial for that but I know there is one.

	paul

---

From: Jon Callas <[email-masked]>
Date: Wed, 23 Jun 1999 11:23:33 -0700

I recommend using SHA-1 anyway, and as Paul Koning says, truncate it if you
are running on such a slow line that the extra four bytes will degrade your
performance.

The reason is that OpenPGP mandates SHA-1. It's a good idea from an
engineering aspect to reuse an existing algorithm if it's good enough,
because that means that the minimal implementation can be that much smaller.

	Jon

---

From: Tony Mione <[email-masked]>
Date: Thu, 24 Jun 1999 07:46:34 -0400 (EDT)

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

> here - it is merely used as a checksum.  MD5 is good enough for this.

Ok,

	It just seems that normal CRCs are more likely to have collisions
(since they are generally much smaller (32 bits, etc). If you are going
through the trouble of putting in MD5, the 4 extra bytes for SHA-1 should
not be a tremendous burdon. If you are working with a keyserver holding
100,000 keys, you add 400K which is hardly more than a fraction of a second
to transfer with today's network technologies.

---

From: Tony Mione <[email-masked]>
Date: Thu, 24 Jun 1999 08:03:35 -0400 (EDT)

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

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

> >> ...

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 :)

> base, if the hashes are still different then the client must have the

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

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

>...

---

From: Marcel Waldvogel <[email-masked]>
Date: Thu, 24 Jun 1999 15:39:38 +0200

> key may look quite different on different servers, although with sorted

The bad thing is that merging the keys may not produce the same result,
so that each time the key would be re-requested. E.g., there are many
keys floating around that have been revoked on multiple occasions, i.e.
the merged key would need to contain multiple revocation certificates,
to provide the same checksum, which does not conform to RFC 2440.

Also, I am not thrilled by the idea to exchange 28*600,000 bytes
(8 bytes keyID+16..20 bytes of hash times the number of keys currently
on my server) with a dozen or so sites (>200MB) every day or so just to
find out whether I'm still in sync. This is not too far from just grabbing
the entire keyring (some 650MB) from some other site.

-Marcel

---

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 30 Jun 1999 09:59:30 -0500

In <[email-masked]>, on 06/24/99 
   at 03:39 PM, Marcel Waldvogel <[email-masked]> said:

>On Wed, Jun 23, 1999 at 05:41:51PM +0100, "teun, Tilburg University"
><[email-masked]> wrote: > /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. > 

>the merged key would need to contain multiple revocation certificates, to
>provide the same checksum, which does not conform to RFC 2440.

Well this was the point of sorting the key before calculating the hash. So
long as everyone is using the same sort order for the different packets in
the key they should generate the same hash for the same key. 

I am not sure what you mean by "revoked on multiple occasions"? Are you
saying that there are public keys on the servers that have different
revocation signatures for the same key on different servers?? This does
not make sense. If this is true how does the current servers address this
when it merges two keys that have different revocation sigs? I really
don't see any other solution than to include all the revocation signatures
when merging the keys. RFC 2440 may not have addressed this, but I doubt
anyone anticipated this.

>Also, I am not thrilled by the idea to exchange 28*600,000 bytes (8 bytes
>keyID+16..20 bytes of hash times the number of keys currently on my
>server) with a dozen or so sites (>200MB) every day or so just to find
>out whether I'm still in sync. This is not too far from just grabbing the
>entire keyring (some 650MB) from some other site.

I guess I should have clarified this better. It was not my intent for the
servers to conduct a synchronization on a daily basis. As far as I can
tell the current mechanism of incrementals is working well for the
propagation of keys (though it does seem to be taking up much more
bandwidth than needed). This was only intended to be a mechanism for
servers to periodically check with each other to make sure that they are
in synch (once a month seems like a good time frame).

Just grabing the keyring from another site is only a partial solution as
it only guarantees that you have the same keys that the other server has.
It does nothing for the others servers that you are "connected" to, nor
does it address any keys that your server may have that the other server
does not.

To provide the same level of synchronization as this method does by
pulling the entire keyring you are looking at downloading the entire
keyring for 12 servers (7800MB), merging them into your database (a time
consuming process), doing a keyring dump, and then uploading your keyring
back to those same 12 servers (7800MB) for a total of 15600MB!!!

There is no reason why a server could not generate a complete hash table
once a month, and then produce a "changes" hash table on a daily or weekly
basis that only contained the new/updated keys since the last complete
hash table was created.

In a previous post I outlined a mechanism using key hashes for doing the
daily incrementals that would greatly reduce the overhead in bandwidth &
processing over the current method.

Hi Jeff!! :)

---

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 30 Jun 1999 10:39:25 -0500

In <[email-masked]>, on
06/24/99 

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

>database, should not the hash now match (providing the hashing is done in
>a defined order as you illustrate below?)

See my example above.

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

Hi Jeff!! :)

---

From: Jack Repenning <[email-masked]>
Date: Wed, 30 Jun 1999 11:04:54 -0700

After working over Baumer's paper a bit, I don't understand the fault 
handling bits of the protocol, in chapter 4.  (Wording quoted here are all 
from section 4.1, the overview):

	- "When a keyserver detects a gap in the sequence number, it sends a 
_request_ message to another keyserver, ..."  When is the gap checked 
for?  Upon receipt of an update, no doubt; what about upon receipt of "a 
_request_ message"?

	- "... the sequence number ..."  Is that the number of the last contiguous 
known event, the first missing, the last missing, or the first received 
noncontiguous?  In general, there may be missing gaps, not merely single 
events (indeed, this seems more likely to me).  ("The oldest  missing 
sequence number" seems like a good choice, with the implication that this 
one and all subsequent known events be transmitted.)

	- "Then the Nearest Neighbour sends the information..."  What if the NN is 
also missing the requested info?  Mention of deadlock elsewhere suggests 
the NN might in turn requery its NN at this point, but this is nowhere 
explicit.

	- During this period (while a _request_ is pending from the NN), what is 
the behavior of the server with respect to the request itself?  Does it 
retry its request periodically, and/or after a timeout?  Should the server 
crash in the interregnum, is it obligated to restore itself in some state 
that will accept (or re-request) this info?  Or does it wait until yet one 
more event arrives from the originator?  Does it continue to accept and 
apply new server-server updates from this originator?  From other originators?

	- During this period, does it continue to serve uploads and requests from 
users?  Does it attempt to apply the updates?  (Note that some events, from 
beyond the gap, from other servers, or from users, may not be possible to 
apply, without the missing data - a new user ID added but lost, for 
example, means a subsequent signature on that ID can not be applied - and 
may not come even from the same originating server, so the potential 
extends over all updates.)

	- How does the distributed database detect and communicate the case where 
a request to an NN is for some sequence number that in fact does not exist?

I'm particularly thinking of a potential global denial-of-service attack, 
by sending a nonsensically-high sequence number into the mbone.  All 
keyservers then query their NN, but none know the answer.  There is no 
algorithm apparent here to recover (not to say it couldn't exist, but I 
don't find it here).

Informix Software, Inc.        Jack Repenning
Config/Release Mgmt            [email-masked]
4100 Bohannon Drive            M/S: 4100/2
Menlo Park, CA 94025           FAX: 650/926-6571
VOICE: 650/926-1044               PAGE: 800/781-6182
PGP/RSA: D24B E2C2 9AFB 7C24 : 7E59 7885 525D 644E
PGP/DSS: 955C 44AD 8FCE 77D4 9494 \
           : 4AB2 51F1 3EED 3B82 E870

---

From: Tony Mione <[email-masked]>
Date: Wed, 30 Jun 1999 14:27:04 -0400 (EDT)

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

> Now server #1 & #2 both have packets for key #1 that the other does not

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.

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

---

From: Marcel Waldvogel <[email-masked]>
Date: Thu, 1 Jul 1999 00:54:22 +2600 (MET DST)

> the key they should generate the same hash for the same key. 

William,

this was said thinking about duplicate signatures or revocation certificates
or other stuff:

- Many key owners seem to revoke their keys more than once, so many
  keys on different servers have different revocation certificates.
  (Importing Peter Wan's keyring into my database gives some hundred of
  these).
- Many users sign the same UserID more than once. The current pksd
  prunes them to all but one. Currently, pksd does this by taking the one
  with the newest time stamp. Other keyservers may have a different policy.
- If keyservers are put into place which really check the validity of the
  revocations/signatures before either adding them or allowing them to
  replace other revocations or signatures, there may be even more differences.

Unless all keyservers follow exactly the same policies and these policies
do not depend on the order in which the PGP packets are received, the
number of unresolved or unresolvable differences will increase. And I
am not really sure which policy is the "right" one.

-Marcel

From: Marcel Waldvogel <[email-masked]>
Subject: Re: PGP Keyserver Synchronization Protocol
To: [email-masked] (William H. Geiger III)
Date: Thu, 1 Jul 1999 00:54:22 +2600 (MET DST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> the key they should generate the same hash for the same key. 

William,

this was said thinking about duplicate signatures or revocation certificates
or other stuff:

- Many key owners seem to revoke their keys more than once, so many
  keys on different servers have different revocation certificates.
  (Importing Peter Wan's keyring into my database gives some hundred of
  these).
- Many users sign the same UserID more than once. The current pksd
  prunes them to all but one. Currently, pksd does this by taking the one
  with the newest time stamp. Other keyservers may have a different policy.
- If keyservers are put into place which really check the validity of the
  revocations/signatures before either adding them or allowing them to
  replace other revocations or signatures, there may be even more differences.

Unless all keyservers follow exactly the same policies and these policies
do not depend on the order in which the PGP packets are received, the
number of unresolved or unresolvable differences will increase. And I
am not really sure which policy is the "right" one.

-Marcel

Date: Wed, 30 Jun 1999 14:27:04 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
cc: Tony Mione <[email-masked]>, [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

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

OH, DUH!

Got it.

Hmmm.

Date: Wed, 30 Jun 1999 11:04:54 -0700
To: [email-masked], [email-masked]
From: Jack Repenning <[email-masked]>
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 30 Jun 1999 10:39:25 -0500
To: Tony Mione <[email-masked]>
Cc: Tony Mione <[email-masked]>, [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

Example:

KeyID  1111111111111111
UserID John Doe
Sig    John Doe

KeyID 1111111111111111
UserID John Doe
Sig    John Doe
Sig    Jim Brown

KeyID 1111111111111111
UserID John Doe
Sig    John Doe
Sig    Jim Brown

See my example above.

Hi Jeff!! :)

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 30 Jun 1999 10:36:32 -0500
To: "Gaon, David" <[email-masked]>
Cc: Tony Mione <[email-masked]>, [email-masked], [email-masked]
Subject: RE: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

In <[email-masked]>, on
06/24/99 
   at 09:08 AM, "Gaon, David" <[email-masked]> said:

>William Geiger wrote:

>Where did the client get the ""newer data"" from ??
>Is not the client updating  himself from a master database that should
>have the latest info ??

No. The "client" receives updates from 2 sources:

Individual users uploading new/updated keys.

Other servers sending "incermentals" which are the new/updated keys that
they have received from individual users or other servers.

Hi Jeff!! :)

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 30 Jun 1999 09:59:30 -0500
To: Marcel Waldvogel <[email-masked]>
Cc: "teun,Tilburg University" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

Hi Jeff!! :)

Date: 25 Jun 1999 22:48:34 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

> CRC-64, don't know a good polynomial for that but I know there is one.

One possibility is x^64+x^11+x^2+x+1. However, hash127, which Jim
already mentioned, is faster in software than a heavily optimized
CRC-64, and has better error-detecting guarantees than a CRC-127.

---Dan

Date: Fri, 25 Jun 1999 17:24:38 +0200
From: Marcel Waldvogel <[email-masked]>
To: Paul Koning <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Multicast Keyserver Synchronization
Sender: [email-masked]

On Fri, Jun 25, 1999 at 11:07:07AM -0400, Paul Koning <[email-masked]> wrote:
>  >> (By the way, a timestamp may be better than a sequence number.)
>  Marcel> I don't see the advantages of a timestamp.  The advantage of
>  Marcel> a sequence number is that you immediately know about holes,
>  Marcel> updates which you have missed. As long as entries are
>  Marcel> superseding each other, a timestamp is just fine, but if it
>  Marcel> is only additive (as with PGP), I feel that seqnos are more
>  Marcel> appropriate.
> Good point, but make them bigger than 32 bits so you can avoid
> worrying about wrapping (which is a problem, see Rosen).  And you may
> still want a timestamp, indicating when the counter was initialized,
> so you can recover from loss of the counter state.

Paul,

thanks for the references. In our design, we have been using (compressable)
IPv6 addresses and 64 bit counters, although we believe that 32 bit is
more than enough. Even if 32 bits should be exhausted, by adding an additional
IP address (kludge alert), another 2^32 sequence numbers could be allocated.

I see the advantage of the time stamp, but our idea was to recover the
counter state from a query to the local DB at start-up. And if the DB
should have crashed, rebuilding it according to the information received
from the other keyservers will also re-establish counter state.

-Marcel

Date: Fri, 25 Jun 1999 11:06:18 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Multicast Keyserver Synchronization
Sender: [email-masked]

>>>>> "Marcel" == Marcel Waldvogel <[email-masked]> writes:

 Marcel> On Fri, Jun 25, 1999 at 10:42:21AM -0400, Paul Koning
 Marcel> <[email-masked]> wrote:
 >> Hm, this sounds like IS-IS or OSPF or similar routing update
 >> distribution protocols.  Given that this is a long-studied area in
 >> layer 3, it's probably a good idea to examine that literature.
 >> There are plenty of pitfalls to be avoided, and at this point it
 >> is known how to do so.

 Marcel> Paul,

 Marcel> would you happen to have pointers to good literature around?

"Interconnections", Radia Perlman (Addison-Wesley, 0-201-56332-0)

The IS-IS spec (ISO 10589, also RFC 1142).

The OSPF spec (RFC 2328)

I can't find citations for the papers by Eric Rosen or for the various 
ones on routing update protocols by Radia Perlman.  You might ask her
([email-masked]). 

 >> (By the way, a timestamp may be better than a sequence number.)

 Marcel> I don't see the advantages of a timestamp.  The advantage of
 Marcel> a sequence number is that you immediately know about holes,
 Marcel> updates which you have missed. As long as entries are
 Marcel> superseding each other, a timestamp is just fine, but if it
 Marcel> is only additive (as with PGP), I feel that seqnos are more
 Marcel> appropriate.

Good point, but make them bigger than 32 bits so you can avoid
worrying about wrapping (which is a problem, see Rosen).  And you may
still want a timestamp, indicating when the counter was initialized,
so you can recover from loss of the counter state.

	paul

Date: Fri, 25 Jun 1999 16:50:35 +0200
From: Marcel Waldvogel <[email-masked]>
To: Paul Koning <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Multicast Keyserver Synchronization
Sender: [email-masked]

On Fri, Jun 25, 1999 at 10:42:21AM -0400, Paul Koning <[email-masked]> wrote:
> Hm, this sounds like IS-IS or OSPF or similar routing update
> distribution protocols.  Given that this is a long-studied area in
> layer 3, it's probably a good idea to examine that literature.  There
> are plenty of pitfalls to be avoided, and at this point it is known
> how to do so.

Paul,

would you happen to have pointers to good literature around?

> (By the way, a timestamp may be better than a sequence number.)

I don't see the advantages of a timestamp.
The advantage of a sequence number is that you immediately know about
holes, updates which you have missed. As long as entries are superseding
each other, a timestamp is just fine, but if it is only additive (as with
PGP), I feel that seqnos are more appropriate.

-Marcel

Date: Fri, 25 Jun 1999 10:42:21 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Multicast Keyserver Synchronization
Sender: [email-masked]

>>>>> "Albert" == Albert Levi <[email-masked]> writes:

 Albert> Marcel Waldvogel wrote:

 >> Instead of using the "push" semantics using mail, our proposal is
 >> to use a combined "push-pull" semantics using IP multicast (and
 >> designated unicast tunnels for sites not connected to the MBone).

Hm, this sounds like IS-IS or OSPF or similar routing update
distribution protocols.  Given that this is a long-studied area in
layer 3, it's probably a good idea to examine that literature.  There
are plenty of pitfalls to be avoided, and at this point it is known
how to do so.

 >> * Sender: - it tags that packet with a world-wide unique sequence
 >> number, consisting of its host ID to make everything unique, and
 >> the next number of its private sequence number space - it
 >> multicasts the tuple (host ID, sequence number, OpenPGP packet) to
 >> the multicast group (together with an identification of the
 >> enclosing UID and public key packet.

For example, sequence numbers raise the issue of how you deal with the 
bounded number of bits.  There's an obvious way to do this which is
wrong (see paper by Eric Rosen et al. from around 1980) and a right
way which is now used in routing protocols.

 Albert> where does a server get its worldwide unique sequence number?
 Albert> don't we need a central authority here?

No...  Marcel said "consisting of its host ID... and the next number
of its private sequence number space".  That's a standard solution: to 
get globally unique IDs (often known as UUIDs, you'll find them in
Microsoft stuff but the originated in OSF RPC if not earlier) you use
a MAC address or similar number for spatial uniqueness, and a (locally 
managed) time stamp for local temporal uniqueness, plus a sequence
number if needed to cope with low resolution clocks.  These field
taken together give you what's needed.  (By the way, a timestamp may
be better than a sequence number.)

	paul

Date: Fri, 25 Jun 1999 16:40:23 +0200 (MET DST)
From: Nathalie Weiler <[email-masked]>
To: Albert Levi <[email-masked]>
cc: Marcel Waldvogel <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Multicast Keyserver Synchronization
Sender: [email-masked]

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

On Fri, 25 Jun 1999, Albert Levi wrote:

>where does a server get its worldwide unique sequence number? don't we
>need a central authority here? If so, I believe that this is incongruous
>to the soul of PGP.

No, we do not need a central authority, since we can pretty well
coordinate this "getting" of this unique sequence number by a distributed
approach.

Nathalie 
- ---
PGP-KeyID: 52D1CAB1 <[email-masked]>
PGP encrypted mail welcome

Date: Fri, 25 Jun 1999 16:51:55 +0300
From: Albert Levi <[email-masked]>
Organization: Bogazici University
To: Marcel Waldvogel <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Multicast Keyserver Synchronization
Sender: [email-masked]

Marcel Waldvogel wrote:

> Last summer, Michael Baumer has been working out and implementing a
> protocol for efficient key server synchronization (with input from
> Nathalie Weiler, Patrick Feisthammel, and myself). The semester thesis
> report can be found at
> http://www.tik.ee.ethz.ch/tik/education/sadas/SASS1998-33/thesis.ps.gz
> Unfortunately, lack of time have prevented us from developing this
> further than a prototype implementation based on pks-0.9.3.
>
> In the following, I'll present the main goals.
>
> 1. Reduce the load for basic keyserver synchronization
> 2. Insure synchronization with very little network traffic
> 3. Allow the operation of cache/partial keyservers
>
> Status:
>
> Currently, each keyserver has a list of neighbors (syncsites), which
> it sends new keys and signatures ("incrementals") to by mail. This
> results in flooding each message along the keyserver network. Each of
> the hosts receives the message potentionally from each of its
> syncsites. To achieve high reliability, the degree of the syncsite
> graph has to be relatively high, resulting in many redundant mails for
> a single incremental.
>
> The flooding approach is not well-suited for the mail system, which
> results in regular overloads at sites (too many processes), and lost
> incrementals. Although, if a destination is down for some time, the
> mail queue at its syncsites quickly grows without bound, requiring
> manual intervention.
>
> Solution:
>
> Instead of using the "push" semantics using mail, our proposal is to
> use a combined "push-pull" semantics using IP multicast (and
> designated unicast tunnels for sites not connected to the MBone).
> Whenever a keyserver learns of a new packet to any key from an
> "old-style" source, the following steps are performed:
>
> * Sender:
> - it tags that packet with a world-wide unique sequence number,
>   consisting of its host ID to make everything unique, and the
>   next number of its private sequence number space
> - it multicasts the tuple (host ID, sequence number, OpenPGP packet)
>   to the multicast group (together with an identification of the
>   enclosing UID and public key packet.
>
> * Receivers:
> - add the packet together with its sequence number to their database
> - make sure that the sequence number from this host is exactly one
>   higher than the previous number. If not, they ask for retransmission
>   of missing packets
>
> On a regular basis, keyservers heartbeat the list of their known (host
> ID, highest sequence number) pairs, to tell the others what their
> belief of maximum sequence number is. This packet's size is
> proportional to the number of sequence-number creating keyservers, and
> not influenced by the number of "listening" keyservers or the number
> of keys in the database. When any host thus learns of a higher
> sequence number, it starts requesting the missing packets from either
> a closeby host or the originator.
>
> In our experiments, the network traffic generated was much less than
> it is with the current e-mail-based synchronization. Also, the load
> was lower. To insure against malicious sending of packets, it is
> possible to get (possibly signed) *incremental* digests from the
> originator. We also believe, that this is better than sending out
> hashes of all keys.
>
> -Marcel

where does a server get its worldwide unique sequence number? don't we
need a central authority here? If so, I believe that this is incongruous
to the soul of PGP.

Albert

Date: Thu, 24 Jun 1999 18:11:32 +0200
From: Marcel Waldvogel <[email-masked]>
To: [email-masked], [email-masked]
Subject: Multicast Keyserver Synchronization
Sender: [email-masked]

Last summer, Michael Baumer has been working out and implementing a
protocol for efficient key server synchronization (with input from
Nathalie Weiler, Patrick Feisthammel, and myself). The semester thesis
report can be found at
http://www.tik.ee.ethz.ch/tik/education/sadas/SASS1998-33/thesis.ps.gz
Unfortunately, lack of time have prevented us from developing this
further than a prototype implementation based on pks-0.9.3.

In the following, I'll present the main goals.

1. Reduce the load for basic keyserver synchronization
2. Insure synchronization with very little network traffic
3. Allow the operation of cache/partial keyservers

Status:

Currently, each keyserver has a list of neighbors (syncsites), which
it sends new keys and signatures ("incrementals") to by mail. This
results in flooding each message along the keyserver network. Each of
the hosts receives the message potentionally from each of its
syncsites. To achieve high reliability, the degree of the syncsite
graph has to be relatively high, resulting in many redundant mails for
a single incremental.

The flooding approach is not well-suited for the mail system, which
results in regular overloads at sites (too many processes), and lost
incrementals. Although, if a destination is down for some time, the
mail queue at its syncsites quickly grows without bound, requiring
manual intervention.

Solution:

Instead of using the "push" semantics using mail, our proposal is to
use a combined "push-pull" semantics using IP multicast (and
designated unicast tunnels for sites not connected to the MBone).
Whenever a keyserver learns of a new packet to any key from an
"old-style" source, the following steps are performed:

* Sender:
- it tags that packet with a world-wide unique sequence number,
  consisting of its host ID to make everything unique, and the
  next number of its private sequence number space
- it multicasts the tuple (host ID, sequence number, OpenPGP packet)
  to the multicast group (together with an identification of the
  enclosing UID and public key packet.

* Receivers:
- add the packet together with its sequence number to their database
- make sure that the sequence number from this host is exactly one
  higher than the previous number. If not, they ask for retransmission
  of missing packets

On a regular basis, keyservers heartbeat the list of their known (host
ID, highest sequence number) pairs, to tell the others what their
belief of maximum sequence number is. This packet's size is
proportional to the number of sequence-number creating keyservers, and
not influenced by the number of "listening" keyservers or the number
of keys in the database. When any host thus learns of a higher
sequence number, it starts requesting the missing packets from either
a closeby host or the originator.

In our experiments, the network traffic generated was much less than
it is with the current e-mail-based synchronization. Also, the load
was lower. To insure against malicious sending of packets, it is
possible to get (possibly signed) *incremental* digests from the
originator. We also believe, that this is better than sending out
hashes of all keys.

-Marcel

Date: Thu, 24 Jun 1999 15:39:38 +0200
From: Marcel Waldvogel <[email-masked]>
To: "teun, Tilburg University" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

-Marcel

From: "Gaon, David" <[email-masked]>
To: "'William H. Geiger III'" <[email-masked]>, Tony Mione <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: PGP Keyserver Synchronization Protocol
Date: Thu, 24 Jun 1999 09:08:39 -0400
Importance: low
Sender: [email-masked]

>>base, if the hashes are still different then the client must have the

Where did the client get the ""newer data"" from ??
Is not the client updating  himself from a master database that should have
the latest info ??

David Gaon

-----Original Message-----
From: William H. Geiger III [mailto:[email-masked]]
Sent: Wednesday, June 23, 1999 10:48 AM
To: Tony Mione
Cc: [email-masked]; [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol

Hi Jeff!! :)

Date: Thu, 24 Jun 1999 08:03:35 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
cc: Tony Mione <[email-masked]>, [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

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

Sigh...

Date: Thu, 24 Jun 1999 07:46:34 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: Werner Koch <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

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

Ok,

Date: Wed, 23 Jun 1999 11:23:33 -0700
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

	Jon

Date: Wed, 23 Jun 1999 12:30:04 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

	paul

Date: Wed, 23 Jun 1999 09:16:30 -0700
From: Jim Gillogly <[email-masked]>
Organization: Banzai Institute
To: "William H. Geiger III" <[email-masked]>, Werner Koch <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

> that would be smaller than MD5 but still large enough to be collision

Would Bernstein's hash127 (somewhat faster than MD5) be suitable for
this application?  It's at ftp://koobera.math.uic.edu/www/hash127.html .
-- 
	Jim Gillogly
	Sterday, 2 Lithe S.R. 1999, 16:13
	12.19.6.5.8, 12 Lamat 16 Zotz, Ninth Lord of Night

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 23 Jun 1999 09:47:50 -0500
To: Tony Mione <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

Hi Jeff!! :)

From: "teun, Tilburg University" <[email-masked]>
Organization: Tilburg University
To: Tony Mione <[email-masked]>
Date: Wed, 23 Jun 1999 17:41:51 MET
Subject: Re: PGP Keyserver Synchronization Protocol
CC: [email-masked], [email-masked]
Sender: [email-masked]

Hi Tony,

cheers,

teun

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 23 Jun 1999 10:28:49 -0500
To: Werner Koch <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

Hi Jeff!! :)

Date: Wed, 23 Jun 1999 09:55:41 +0200
From: Werner Koch <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

Date: Tue, 22 Jun 1999 22:46:44 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: "William H. Geiger III" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

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

See comments below.

Date: Mon, 21 Jun 1999 23:32:49 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: V5 signatures
Sender: [email-masked]

"William H. Geiger III" <[email-masked]>:

> IMNSHO it is brain dead to stuff data into signature packets. It is not
> where it belongs. PGP has a very nice and simple signature format: A hash
> of the data encrypted with the signer's public key. [...]

You mean "private key", obviously, but in any case that phrase should
be eliminated from discussions on digital signatures.  Signatures are
not about encrypting; it's just that in the scheme abstractly
described by Diffie and Hellman and made practically by Rivest, Shamir
and Adleman, signing and decryption are done in the same way.  This is
not true in general, and particularly not for ElGamal and DSA
signatures.

Date: Mon, 21 Jun 1999 13:20:49 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Agree with PRZs MDC suggestion
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Bodo Moeller <[email-masked]> writes:

> Then why not dump plain ElGamal encryption in favor of DHAES (see
> http://www.cse.ucsd.edu/users/mihir/papers/pke.html), DHAES being used
> on whole messages, not just session keys?  (DHAES is basically ElGamal

We can't do this because the OpenPGP design allows for more than one
recipient and therefore we need a session key.

It seems that the whole MDC thread has come to an end and we drop it
completely? 

Date: Sat, 19 Jun 1999 14:11:52 -0700
To: "William H. Geiger III" <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: V5 signatures
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Bill, the only difference between a V4 sig and a V5 sig is changing the
length field. The only place that really needs these is standalone
signatures, (and arguably not even them -- you are after all making that
very argument).

There are a class of applications that want to have a self-describing
structure, rather than have a chunk of data and sign it. Doing it this way
simplifies parsing, for example. You can quickly look at the object and
conclude its one of these critters rather having to grovel over the data
looking for a sig. Yup, you can do it the other way. For some people, this
is desirable. We have people who want to do this.

There's also another other way for these people get their desired behavior
-- use X.509. If I'm being testy, it's because I'm reading in your
objections a desire for these people to go away and use X.509, which I
don't think you intend. I don't want someone to make an architectural
decision not to use OpenPGP, because there's a stupid length limitation.

	Jon

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 18 Jun 1999 22:06:55 -0500
To: Jon Callas <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: V5 signatures
Sender: [email-masked]

In <v04003a03b390ad882d32@[10.5.63.113]>, on 06/18/99 
   at 07:17 PM, Jon Callas <[email-masked]> said:

>At 5:47 PM -0700 6/18/1999, [email-masked] said:

>   Couldn't this be done though by simply defining a data packet format
>   as for any other protocol, then signing the data packet?  I don't see
>   any inherent reason why all authenticated data must go in sig packets.
>   Sigs authenticate the data packets they sign, so anything in those
>data
>   packets is as strongly authenticated as the contents of the sig
>packets.

>Sure. It can be done that way, too. The advantage of doing it in a
>signature packet is that it is a self-describing object with a tag and a
>length. It's useful.

I really don't see it as any more useful than doing it as hal describes
but things like pgp ticket are not my concern as they fit within current
restraints of V4 signatures (which IMHO are overly complex). My concern is
when the legal depts get the bright idea to add several pages of legalese
to every signature to let the world know that their signatures are really
worthless (al la S/MIME). If we design a V5 signature format that can
accommodate 1Mb of data to be stuffed into a signature, you can bet some
idiot will start generating 1Mb signatures.

IMHO we should keep the signatures nice and simple (and most importantly
small) and leave the data in the literal packets where it belongs. I think
that we, as protocol developers must always stay vigilant against feature
creep. PGP started out as a simple, rather elegant, program to encrypt &
sign e-mail message. Both the OpenPGP protocol and NAI's corresponding
application have dramatically increased in size and complexity, yet
surprisingly (or less surprising for the more cynical of us) it does
relatively little more than the original program and protocol did. 

Hi Jeff!! :)

Date: Fri, 18 Jun 1999 19:17:10 -0700
To: [email-masked], [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: V5 signatures
Cc: [email-masked]
Sender: [email-masked]

At 5:47 PM -0700 6/18/1999, [email-masked] said:

   Couldn't this be done though by simply defining a data packet format
   as for any other protocol, then signing the data packet?  I don't see
   any inherent reason why all authenticated data must go in sig packets.
   Sigs authenticate the data packets they sign, so anything in those data
   packets is as strongly authenticated as the contents of the sig packets.

Sure. It can be done that way, too. The advantage of doing it in a
signature packet is that it is a self-describing object with a tag and a
length. It's useful.

	Jon

From: [email-masked]
Date: Fri, 18 Jun 1999 17:47:54 -0700
To: [email-masked], [email-masked], [email-masked]
Subject: Re: V5 signatures
Cc: [email-masked]
Sender: [email-masked]

Jon Callas, <[email-masked]>, writes, regarding data in sig packets:

> The reason I want it there is so that someone, if they wanted to, could
> make a "bloated" signature. An example of why you might want to do this is
> PGPticket. These are very light weight authorization certificates. Vinnie
> has a great example of using this. He has a file-server extension that
> accepts tickets and can allow you access to the server simply by writing
> you an appropriate ticket. It's very cool, and works really nicely.

Couldn't this be done though by simply defining a data packet format
as for any other protocol, then signing the data packet?  I don't see
any inherent reason why all authenticated data must go in sig packets.
Sigs authenticate the data packets they sign, so anything in those data
packets is as strongly authenticated as the contents of the sig packets.

Hal

Date: Fri, 18 Jun 1999 17:06:27 -0700
To: "William H. Geiger III" <[email-masked]>, Werner Koch <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: V5 signatures
Cc: [email-masked]
Sender: [email-masked]

At 7:48 AM -0700 6/18/1999, William H. Geiger III said:

   IMNSHO it is brain dead to stuff data into signature packets. It is not
   where it belongs. PGP has a very nice and simple signature format: A hash
   of the data encrypted with the signer's public key. That's all that needs
   to be there, no need to start bloating out the signatures.

So don't do that.

The reason I want it there is so that someone, if they wanted to, could
make a "bloated" signature. An example of why you might want to do this is
PGPticket. These are very light weight authorization certificates. Vinnie
has a great example of using this. He has a file-server extension that
accepts tickets and can allow you access to the server simply by writing
you an appropriate ticket. It's very cool, and works really nicely.

I cannot conceive of why you would need more than 8383 bytes in a ticket
(or 64K), either, but all my years of design have taught me that you never
regret making a length field idiotically big. The gods punish hubris, and
in protocol design, two-byte lengths are hubris.

	Jon

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 18 Jun 1999 10:05:43 -0500
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: PGP Keyserver Synchronization Protocol (corrected)
Sender: [email-masked]

Sorry, I didn't run the spell checker over the previous post.

pgpk-sync-00.txt

PGP clients to communicate with the servers to compare keys in their local

Overview:

server's hash table he will compare it with his own and generate 3 lists:

The client will then request from the server all the keys in list #1 & #2
and add those keys to it's database. Once this is done the client will
generate a new hash table for his database and compare it to the hash
table he has from the server. He should now only have 2 lists:

Exclusion lists:

	It is common practice among some PGP Keyserver operators to exclude some
keys from their databases (a practice 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:

and do his synchronization without any action on the part of the server. A

	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/updated for that day.

	I am rather flexible on this area and some testing in the field should
provide the best mechanism for when the hash tables should be generate.

Hash Table:

Calculating Hashes:

	It is important that when calculating the hash of a key that it be done
in a specific order as to guarantee 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 Alphabetically

PhotoID's & X509 signatures are 2 issues that need to be looked into.
Unfortunately the specs for neither of these packets have been released by
NAI. For right now I recommend that any proprietary packets *not* be used
in the key hash calculations.

Hi Jeff!! :)

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 18 Jun 1999 09:43:36 -0500
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

pgpk-sync-00.txt

Overview:

Excultion lists:

FTP of Hash Tables:

Hash Table:

Calculating Hashes:

	Primary Key
	SubKeys Sorted by KeyID

Hi Jeff!! :)

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 18 Jun 1999 09:48:00 -0500
To: Werner Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: V5 signatures
Sender: [email-masked]

In <[email-masked]>, on 05/28/99 
   at 05:37 AM, Werner Koch <[email-masked]> said:

>Werner Koch <[email-masked]> writes:

>> However, the octet count for the [un]hashed subpackets is limited to
>> 65535.

>It just came to my mind, that large signature packets (currently they
>have a limit of about 128k) do impose a problem:

>It will then not be possible to keep the complete signature packet in
>memory.  Signatures may be (theoretical) very large - up to 4 Gigs and
>due to this they have to be handled like plaintext.

>Doess it really make sense to build a protocol - based on OpenPGP - 
>which puts all it's dat into a signature packet?  Such data should go
>into a literal text packet or some new packet type.
> 

IMNSHO it is brain dead to stuff data into signature packets. It is not
where it belongs. PGP has a very nice and simple signature format: A hash
of the data encrypted with the signer's public key. That's all that needs
to be there, no need to start bloating out the signatures.

Hi Jeff!! :)

Date: Mon, 14 Jun 1999 15:17:31 -0400 (EDT)
From: "David M. Balenson" <[email-masked]>
To: [email-masked]
Subject: NDSS 2000 SUBMISSION DEADLINE EXTENDED TO JUNE 23RD
Sender: [email-masked]

The Internet Society's Year 2000 Network and Distributed System
Security Symposium (NDSS 2000) deadline for submissions of technical
paper and panel proposals has been EXTENDED TO JUNE 23RD due to
the large number of requests for an extension and the desire to
accomodate people.

The complete Call for Papers (CFP) is available at
http://www.isoc.org/ndss2000/.

Submissions are being accepted electronically at http://www.isi.edu/~ndss00.

-David Balenson, NDSS 2000 Publicity Chair