From owner-ietf-open-pgp@imc.org Mon Jun 14 16:36:57 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22196 for ; Mon, 14 Jun 1999 16:36:57 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA22535 for ietf-open-pgp-bks; Mon, 14 Jun 1999 12:21:06 -0700 (PDT) Received: from relay.gw.tislabs.com (firewall-user@relay.gw.tislabs.com [192.94.214.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA22531 for ; Mon, 14 Jun 1999 12:21:04 -0700 (PDT) Received: by relay.gw.tislabs.com; id PAA23629; Mon, 14 Jun 1999 15:38:23 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by relay.gw.tislabs.com via smap (4.1) id xma023623; Mon, 14 Jun 99 15:38:23 -0400 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.1/8.9.1) id PAA24873 for ietf-open-pgp@imc.org; Mon, 14 Jun 1999 15:17:31 -0400 (EDT) Date: Mon, 14 Jun 1999 15:17:31 -0400 (EDT) From: "David M. Balenson" Message-Id: <199906141917.PAA24873@clipper.gw.tislabs.com> To: ietf-open-pgp@imc.org Subject: NDSS 2000 SUBMISSION DEADLINE EXTENDED TO JUNE 23RD Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 From owner-ietf-open-pgp@imc.org Fri Jun 18 11:48:37 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25141 for ; Fri, 18 Jun 1999 11:48:37 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA01867 for ietf-open-pgp-bks; Fri, 18 Jun 1999 07:53:22 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA01862 for ; Fri, 18 Jun 1999 07:53:21 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id KAA04509; Fri, 18 Jun 1999 10:55:46 -0400 Message-Id: <199906181455.KAA04509@domains.invweb.net> From: "William H. Geiger III" Date: Fri, 18 Jun 1999 09:43:36 -0500 To: whgiii@openpgp.net Cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 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 owner-ietf-open-pgp@imc.org Fri Jun 18 11:50:46 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25199 for ; Fri, 18 Jun 1999 11:50:45 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA01838 for ietf-open-pgp-bks; Fri, 18 Jun 1999 07:50:20 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA01834 for ; Fri, 18 Jun 1999 07:50:18 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id KAA04459; Fri, 18 Jun 1999 10:52:38 -0400 Message-Id: <199906181452.KAA04459@domains.invweb.net> From: "William H. Geiger III" Date: Fri, 18 Jun 1999 09:48:00 -0500 To: Werner Koch In-Reply-To: <19990528123701.A28938@frodo.isil.d.shuttle.de> Cc: ietf-open-pgp@imc.org Subject: Re: V5 signatures Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In <19990528123701.A28938@frodo.isil.d.shuttle.de>, on 05/28/99 at 05:37 AM, Werner Koch said: >Werner Koch 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. -- --------------------------------------------------------------- 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 owner-ietf-open-pgp@imc.org Fri Jun 18 11:57:04 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25294 for ; Fri, 18 Jun 1999 11:57:03 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02012 for ietf-open-pgp-bks; Fri, 18 Jun 1999 08:06:08 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02007 for ; Fri, 18 Jun 1999 08:06:06 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA04762; Fri, 18 Jun 1999 11:08:38 -0400 Message-Id: <199906181508.LAA04762@domains.invweb.net> From: "William H. Geiger III" Date: Fri, 18 Jun 1999 10:05:43 -0500 To: whgiii@openpgp.net Cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: PGP Keyserver Synchronization Protocol (corrected) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Sorry, I didn't run the spell checker over the previous post. 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 compare 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 compare 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 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: #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. 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: 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 synchronization 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/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: 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 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. -- --------------------------------------------------------------- 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 owner-ietf-open-pgp@imc.org Fri Jun 18 20:54:03 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02840 for ; Fri, 18 Jun 1999 20:54:03 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA09601 for ietf-open-pgp-bks; Fri, 18 Jun 1999 17:04:35 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA09597 for ; Fri, 18 Jun 1999 17:04:32 -0700 (PDT) Received: from [10.5.63.113] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Fri, 18 Jun 1999 16:07:04 -0800 X-Sender: jon@127.0.0.1 Message-Id: In-Reply-To: <199906181452.KAA04459@domains.invweb.net> References: <19990528123701.A28938@frodo.isil.d.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Jun 1999 17:06:27 -0700 To: "William H. Geiger III" , Werner Koch From: Jon Callas Subject: Re: V5 signatures Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 owner-ietf-open-pgp@imc.org Fri Jun 18 21:26:47 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02986 for ; Fri, 18 Jun 1999 21:26:47 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA10310 for ietf-open-pgp-bks; Fri, 18 Jun 1999 17:47:50 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA10305 for ; Fri, 18 Jun 1999 17:47:45 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id RAA17911; Fri, 18 Jun 1999 17:47:54 -0700 Date: Fri, 18 Jun 1999 17:47:54 -0700 Message-Id: <199906190047.RAA17911@finney.org> To: jon@callas.org, whgiii@openpgp.net, wk@isil.d.shuttle.de Subject: Re: V5 signatures Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas, , 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 From owner-ietf-open-pgp@imc.org Fri Jun 18 22:53:10 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05286 for ; Fri, 18 Jun 1999 22:53:09 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA15111 for ietf-open-pgp-bks; Fri, 18 Jun 1999 19:15:23 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA15107 for ; Fri, 18 Jun 1999 19:15:21 -0700 (PDT) Received: from [10.5.63.113] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Fri, 18 Jun 1999 18:17:56 -0800 X-Sender: jon@127.0.0.1 Message-Id: In-Reply-To: <199906190047.RAA17911@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Jun 1999 19:17:10 -0700 To: hal@finney.org, whgiii@openpgp.net, wk@isil.d.shuttle.de From: Jon Callas Subject: Re: V5 signatures Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 5:47 PM -0700 6/18/1999, hal@finney.org 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 owner-ietf-open-pgp@imc.org Sat Jun 19 10:49:00 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21350 for ; Sat, 19 Jun 1999 10:49:00 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA18758 for ietf-open-pgp-bks; Sat, 19 Jun 1999 07:07:57 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA18754 for ; Sat, 19 Jun 1999 07:07:56 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id KAA26618; Sat, 19 Jun 1999 10:10:15 -0400 Message-Id: <199906191410.KAA26618@domains.invweb.net> From: "William H. Geiger III" Date: Fri, 18 Jun 1999 22:06:55 -0500 To: Jon Callas In-Reply-To: Cc: hal@finney.org, wk@isil.d.shuttle.de, ietf-open-pgp@imc.org Subject: Re: V5 signatures Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In , on 06/18/99 at 07:17 PM, Jon Callas said: >At 5:47 PM -0700 6/18/1999, hal@finney.org 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. -- --------------------------------------------------------------- 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 owner-ietf-open-pgp@imc.org Sat Jun 19 18:11:20 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24125 for ; Sat, 19 Jun 1999 18:11:20 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20323 for ietf-open-pgp-bks; Sat, 19 Jun 1999 14:28:52 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20319 for ; Sat, 19 Jun 1999 14:28:49 -0700 (PDT) Received: from [10.5.63.113] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Sat, 19 Jun 1999 13:31:28 -0800 X-Sender: jon@127.0.0.1 Message-Id: In-Reply-To: <199906191410.KAA26618@domains.invweb.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 19 Jun 1999 14:11:52 -0700 To: "William H. Geiger III" From: Jon Callas Subject: Re: V5 signatures Cc: hal@finney.org, wk@isil.d.shuttle.de, ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 owner-ietf-open-pgp@imc.org Mon Jun 21 08:41:16 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03600 for ; Mon, 21 Jun 1999 08:41:14 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22158 for ietf-open-pgp-bks; Mon, 21 Jun 1999 04:44:12 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22154 for ; Mon, 21 Jun 1999 04:44:06 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id NAA26315 for ietf-open-pgp@imc.org; Mon, 21 Jun 1999 13:46:41 +0200 (MET DST) Received: from (frodo.isil.d.shuttle.de) [172.20.1.4] (mail) by beren.isil.d.shuttle.de with esmtp (Exim 1.92 #1 (Debian)) id 10w2B1-00087B-00; Mon, 21 Jun 1999 13:23:47 +0200 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10w289-000834-00; Mon, 21 Jun 1999 13:20:49 +0200 Date: Mon, 21 Jun 1999 13:20:49 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Agree with PRZs MDC suggestion Message-ID: <19990621132049.C30822@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <9905280526.AA23486@buoy.watson.ibm.com> <19990528212200.A3334@epsilon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <19990528212200.A3334@epsilon>; from Bodo Moeller on Fri, May 28, 1999 at 09:22:02PM +0200 X-URL: http://www.openit.de/wks Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Bodo Moeller 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? -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Mon Jun 21 19:59:41 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12624 for ; Mon, 21 Jun 1999 19:59:40 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA29919 for ietf-open-pgp-bks; Mon, 21 Jun 1999 16:13:38 -0700 (PDT) Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA29915 for ; Mon, 21 Jun 1999 16:13:33 -0700 (PDT) Received: from max1-010.public.uni-hamburg.de (max1-010.public.uni-hamburg.de [134.100.43.10]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id BAA79620 for ; Tue, 22 Jun 1999 01:16:19 +0200 Received: id ; Mon, 21 Jun 1999 23:32:49 +0200 (CEST) Message-Id: Date: Mon, 21 Jun 1999 23:32:49 +0200 (CEST) From: Bodo_Moeller@public.uni-hamburg.de (Bodo Moeller) To: ietf-open-pgp@imc.org Subject: Re: V5 signatures In-Reply-To: <199906181452.KAA04459@domains.invweb.net> References: <19990528123701.A28938@frodo.isil.d.shuttle.de> <199906181452.KAA04459@domains.invweb.net> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: "William H. Geiger III" : > 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. From owner-ietf-open-pgp@imc.org Tue Jun 22 23:31:50 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05230 for ; Tue, 22 Jun 1999 23:31:49 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA02405 for ietf-open-pgp-bks; Tue, 22 Jun 1999 19:44:16 -0700 (PDT) Received: from hardees.rutgers.edu (hardees.rutgers.edu [128.6.18.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA02368 for ; Tue, 22 Jun 1999 19:44:06 -0700 (PDT) Received: from localhost (mione@localhost) by hardees.rutgers.edu (8.8.8/8.8.8) with SMTP id WAA23678; Tue, 22 Jun 1999 22:46:44 -0400 (EDT) Date: Tue, 22 Jun 1999 22:46:44 -0400 (EDT) From: Tony Mione To: "William H. Geiger III" cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol In-Reply-To: <199906181455.KAA04509@domains.invweb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----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----- From owner-ietf-open-pgp@imc.org Wed Jun 23 05:12:39 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23181 for ; Wed, 23 Jun 1999 05:12:39 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA28657 for ietf-open-pgp-bks; Wed, 23 Jun 1999 01:18:31 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA28640 for ; Wed, 23 Jun 1999 01:18:26 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id KAA13696 for ietf-open-pgp@imc.org; Wed, 23 Jun 1999 10:21:21 +0200 (MET DST) Received: from (frodo.isil.d.shuttle.de) [172.20.1.4] (mail) by beren.isil.d.shuttle.de with esmtp (Exim 1.92 #1 (Debian)) id 10whvC-0000l2-00; Wed, 23 Jun 1999 09:58:14 +0200 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10whsj-00083F-00; Wed, 23 Jun 1999 09:55:41 +0200 Date: Wed, 23 Jun 1999 09:55:41 +0200 From: Werner Koch To: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Message-ID: <19990623095541.F30893@frodo.isil.d.shuttle.de> Mail-Followup-To: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org References: <199906181455.KAA04509@domains.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: ; from Tony Mione on Tue, Jun 22, 1999 at 10:46:44PM -0400 X-URL: http://www.openit.de/wks Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tony Mione writes: > 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. 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 owner-ietf-open-pgp@imc.org Wed Jun 23 12:26:05 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04470 for ; Wed, 23 Jun 1999 12:26:04 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16445 for ietf-open-pgp-bks; Wed, 23 Jun 1999 08:35:49 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16441 for ; Wed, 23 Jun 1999 08:35:46 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA07314; Wed, 23 Jun 1999 11:38:28 -0400 Message-Id: <199906231538.LAA07314@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 23 Jun 1999 10:28:49 -0500 To: Werner Koch In-Reply-To: <19990623095541.F30893@frodo.isil.d.shuttle.de> Cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In <19990623095541.F30893@frodo.isil.d.shuttle.de>, on 06/23/99 at 09:55 AM, Werner Koch said: >Tony Mione writes: >> 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. >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. 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. -- --------------------------------------------------------------- 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 owner-ietf-open-pgp@imc.org Wed Jun 23 12:27:53 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04559 for ; Wed, 23 Jun 1999 12:27:52 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16494 for ietf-open-pgp-bks; Wed, 23 Jun 1999 08:39:44 -0700 (PDT) Received: from mailnews.kub.nl (mailnews.kub.nl [137.56.0.220]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16490 for ; Wed, 23 Jun 1999 08:39:43 -0700 (PDT) Received: from drc1.kub.nl (drc1.kub.nl [137.56.248.50]) by mailnews.kub.nl (8.8.8/8.8.8) with ESMTP id RAA23477; Wed, 23 Jun 1999 17:42:08 +0200 (MET DST) Message-Id: <199906231542.RAA23477@mailnews.kub.nl> Received: from DRC_1/SpoolDir by drc1.kub.nl (Mercury 1.44); 23 Jun 99 17:42:08 MET Received: from SpoolDir by DRC_1 (Mercury 1.44); 23 Jun 99 17:42:00 MET From: "teun, Tilburg University" Organization: Tilburg University To: Tony Mione Date: Wed, 23 Jun 1999 17:41:51 MET MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: PGP Keyserver Synchronization Protocol CC: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org References: <199906181455.KAA04509@domains.invweb.net> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.01d) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Content-Transfer-Encoding: 7BIT 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 owner-ietf-open-pgp@imc.org Wed Jun 23 12:43:36 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05205 for ; Wed, 23 Jun 1999 12:43:35 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16653 for ietf-open-pgp-bks; Wed, 23 Jun 1999 08:51:07 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16646 for ; Wed, 23 Jun 1999 08:51:06 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA07587; Wed, 23 Jun 1999 11:53:59 -0400 Message-Id: <199906231553.LAA07587@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 23 Jun 1999 09:47:50 -0500 To: Tony Mione In-Reply-To: Cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In , on 06/22/99 at 10:46 PM, Tony Mione said: >> 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? 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. >> 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. >> 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. 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. -- --------------------------------------------------------------- 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 owner-ietf-open-pgp@imc.org Wed Jun 23 13:04:33 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05844 for ; Wed, 23 Jun 1999 13:04:32 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA16922 for ietf-open-pgp-bks; Wed, 23 Jun 1999 09:12:59 -0700 (PDT) Received: from scryer.mentat.com ([192.88.122.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA16918 for ; Wed, 23 Jun 1999 09:12:54 -0700 (PDT) Received: from acm.org (localhost [127.0.0.1]) by scryer.mentat.com (8.8.7/8.8.7) with ESMTP id JAA05661; Wed, 23 Jun 1999 09:16:31 -0700 Message-ID: <3771085E.3FE8906@acm.org> Date: Wed, 23 Jun 1999 09:16:30 -0700 From: Jim Gillogly Organization: Banzai Institute X-Mailer: Mozilla 4.07 [en] (X11; U; Linux 2.2.0 i686) MIME-Version: 1.0 To: "William H. Geiger III" , Werner Koch CC: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Content-Transfer-Encoding: 7bit William H. Geiger III wrote: > 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. 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 owner-ietf-open-pgp@imc.org Wed Jun 23 13:12:23 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06220 for ; Wed, 23 Jun 1999 13:12:23 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA17095 for ietf-open-pgp-bks; Wed, 23 Jun 1999 09:27:20 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17090 for ; Wed, 23 Jun 1999 09:27:18 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQguwg05441; Wed, 23 Jun 1999 16:30:09 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA26823; Wed, 23 Jun 99 12:29:08 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA11317; Wed, 23 Jun 1999 12:30:04 -0400 Date: Wed, 23 Jun 1999 12:30:04 -0400 Message-Id: <199906231630.MAA11317@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: whgiii@openpgp.net Cc: wk@isil.d.shuttle.de, pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol References: <19990623095541.F30893@frodo.isil.d.shuttle.de> <199906231538.LAA07314@domains.invweb.net> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Content-Transfer-Encoding: 7bit >>>>> "William" == William H Geiger 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 owner-ietf-open-pgp@imc.org Wed Jun 23 15:22:51 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10944 for ; Wed, 23 Jun 1999 15:22:49 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18670 for ietf-open-pgp-bks; Wed, 23 Jun 1999 11:29:20 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18666 for ; Wed, 23 Jun 1999 11:29:18 -0700 (PDT) Received: from [10.5.63.113] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 23 Jun 1999 10:32:15 -0800 X-Sender: jon@127.0.0.1 Message-Id: In-Reply-To: References: <199906181455.KAA04509@domains.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Jun 1999 11:23:33 -0700 To: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org From: Jon Callas Subject: Re: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 owner-ietf-open-pgp@imc.org Thu Jun 24 08:33:55 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12461 for ; Thu, 24 Jun 1999 08:33:54 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA01749 for ietf-open-pgp-bks; Thu, 24 Jun 1999 04:43:47 -0700 (PDT) Received: from hardees.rutgers.edu (hardees.rutgers.edu [128.6.18.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA01738 for ; Thu, 24 Jun 1999 04:43:42 -0700 (PDT) Received: from localhost (mione@localhost) by hardees.rutgers.edu (8.8.8/8.8.8) with SMTP id HAA12593; Thu, 24 Jun 1999 07:46:34 -0400 (EDT) Date: Thu, 24 Jun 1999 07:46:34 -0400 (EDT) From: Tony Mione To: Werner Koch cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol In-Reply-To: <19990623095541.F30893@frodo.isil.d.shuttle.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- On Wed, 23 Jun 1999, Werner Koch wrote: > Tony Mione writes: > > > 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. > > 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. > 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. > > -- > Werner Koch at guug.de www.gnupg.org keyid 621CC013 > > 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. iQCVAwUBN3IaiAfNcGHdn+zRAQH9oQQAg6lWFPtYsnh2yieC2BSmIa3cDnT9aRyV sDYdLKI1ups5mG0HpGRzDtpM/iKBwevenirK4uSfy2GMFOQo7FCn2FrFCqiyBe8V aKVMpjVN08p+OsC2ZzFP2qPLLfvNXgtFYCq56fzt2V6/9IQX283VskbJ5xZ1eHUU PxJqV4doIW0= =UOl7 -----END PGP SIGNATURE----- From owner-ietf-open-pgp@imc.org Thu Jun 24 08:58:36 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12767 for ; Thu, 24 Jun 1999 08:58:35 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA02205 for ietf-open-pgp-bks; Thu, 24 Jun 1999 05:00:18 -0700 (PDT) Received: from hardees.rutgers.edu (hardees.rutgers.edu [128.6.18.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA02201 for ; Thu, 24 Jun 1999 05:00:17 -0700 (PDT) Received: from localhost (mione@localhost) by hardees.rutgers.edu (8.8.8/8.8.8) with SMTP id IAA12975; Thu, 24 Jun 1999 08:03:36 -0400 (EDT) Date: Thu, 24 Jun 1999 08:03:35 -0400 (EDT) From: Tony Mione To: "William H. Geiger III" cc: Tony Mione , pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol In-Reply-To: <199906231553.LAA07587@domains.invweb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- On Wed, 23 Jun 1999, William H. Geiger III wrote: > In , on > 06/22/99 > at 10:46 PM, Tony Mione 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 :) > > >> 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 > >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. > 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. > > -- > --------------------------------------------------------------- > William H. Geiger III http://www.openpgp.net >... > > 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. iQCVAwUBN3IeiQfNcGHdn+zRAQGVCAQAwCUHz2eFTo2q38KKe8rxOg4RGObSuDW2 REaMACGvY4uAQeJjBYYjOHv+vVx9J4YtSW+zyUy8vg85r4QjrX3568fUKzj1L7nk JA8PZkJW8FgJLVzxYM4mQK1a1teLY0vAF/21uCfb8rST8e/WJNOEZf904GueJNKU FzO2Ly0gUAk= =D5Fv -----END PGP SIGNATURE----- From owner-ietf-open-pgp@imc.org Thu Jun 24 09:51:53 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13663 for ; Thu, 24 Jun 1999 09:51:51 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA02862 for ietf-open-pgp-bks; Thu, 24 Jun 1999 06:02:37 -0700 (PDT) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA02858 for ; Thu, 24 Jun 1999 06:02:36 -0700 (PDT) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id ; Thu, 24 Jun 1999 09:05:38 -0400 Message-ID: <41A8197B6ABCD2119C0600204804F0CC0F2354@rbmail101.chamb.disa.mil> From: "Gaon, David" To: "'William H. Geiger III'" , Tony Mione Cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: RE: PGP Keyserver Synchronization Protocol Date: Thu, 24 Jun 1999 09:08:39 -0400 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: William Geiger wrote: >>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. 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:whgiii@openpgp.net] Sent: Wednesday, June 23, 1999 10:48 AM To: Tony Mione Cc: pgp-keyserver-folk@flame.org; ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol In , on 06/22/99 at 10:46 PM, Tony Mione said: >> 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? 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. >> 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. >> 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. 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. -- --------------------------------------------------------------- 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 owner-ietf-open-pgp@imc.org Thu Jun 24 10:17:28 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14349 for ; Thu, 24 Jun 1999 10:17:26 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA03271 for ietf-open-pgp-bks; Thu, 24 Jun 1999 06:36:00 -0700 (PDT) Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA03267 for ; Thu, 24 Jun 1999 06:35:58 -0700 (PDT) Received: from komsys-pc-mw.ethz.ch (mwa@komsys-pc-mw [129.132.66.24]) by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id PAA07314; Thu, 24 Jun 1999 15:39:03 +0200 (MET DST) Received: (from mwa@localhost) by komsys-pc-mw.ethz.ch (8.9.3/8.8.8) id PAA04444; Thu, 24 Jun 1999 15:39:38 +0200 Date: Thu, 24 Jun 1999 15:39:38 +0200 From: Marcel Waldvogel To: "teun, Tilburg University" Cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Message-ID: <19990624153938.C4137@tik.ee.ethz.ch> References: <199906181455.KAA04509@domains.invweb.net> <199906231542.RAA23477@mailnews.kub.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199906231542.RAA23477@mailnews.kub.nl>; from Teun Nijssen on Wed, Jun 23, 1999 at 05:41:51PM +0100 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Wed, Jun 23, 1999 at 05:41:51PM +0100, "teun, Tilburg University" 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. > > 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. 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 owner-ietf-open-pgp@imc.org Thu Jun 24 13:47:12 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18383 for ; Thu, 24 Jun 1999 13:47:10 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA04723 for ietf-open-pgp-bks; Thu, 24 Jun 1999 09:07:55 -0700 (PDT) Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA04719 for ; Thu, 24 Jun 1999 09:07:52 -0700 (PDT) Received: from komsys-pc-mw.ethz.ch (mwa@komsys-pc-mw [129.132.66.24]) by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id SAA17835; Thu, 24 Jun 1999 18:10:57 +0200 (MET DST) Received: (from mwa@localhost) by komsys-pc-mw.ethz.ch (8.9.3/8.8.8) id SAA04891; Thu, 24 Jun 1999 18:11:32 +0200 Date: Thu, 24 Jun 1999 18:11:32 +0200 From: Marcel Waldvogel To: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Multicast Keyserver Synchronization Message-ID: <19990624181131.L4137@tik.ee.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 From owner-ietf-open-pgp@imc.org Fri Jun 25 10:40:03 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22759 for ; Fri, 25 Jun 1999 10:40:02 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA29016 for ietf-open-pgp-bks; Fri, 25 Jun 1999 06:35:18 -0700 (PDT) Received: from hamlin.cc.boun.edu.tr (hamlin.cc.boun.edu.tr [193.140.192.230]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA29011 for ; Fri, 25 Jun 1999 06:35:06 -0700 (PDT) Received: from boun.edu.tr (kolyoz.cmpe.boun.edu.tr [193.140.196.76]) by hamlin.cc.boun.edu.tr with ESMTP id QAA24109; Fri, 25 Jun 1999 16:25:20 +0300 (EET DST) Message-ID: <3773897B.7EF06397@boun.edu.tr> Date: Fri, 25 Jun 1999 16:51:55 +0300 From: Albert Levi Organization: Bogazici University X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Marcel Waldvogel CC: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: Multicast Keyserver Synchronization References: <19990624181131.L4137@tik.ee.ethz.ch> Content-Type: text/plain; charset=iso-8859-9 Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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 From owner-ietf-open-pgp@imc.org Fri Jun 25 11:33:02 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24232 for ; Fri, 25 Jun 1999 11:33:02 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA29775 for ietf-open-pgp-bks; Fri, 25 Jun 1999 07:37:25 -0700 (PDT) Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA29770 for ; Fri, 25 Jun 1999 07:37:23 -0700 (PDT) Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id QAA00381; Fri, 25 Jun 1999 16:40:29 +0200 (MET DST) Received: from localhost (weiler@localhost) by kom30.ethz.ch (8.8.8/8.8.8) with ESMTP id QAA05230; Fri, 25 Jun 1999 16:40:29 +0200 (MET DST) X-Authentication-Warning: kom30.ethz.ch: weiler owned process doing -bs Date: Fri, 25 Jun 1999 16:40:23 +0200 (MET DST) From: Nathalie Weiler To: Albert Levi cc: Marcel Waldvogel , pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: Multicast Keyserver Synchronization In-Reply-To: <3773897B.7EF06397@boun.edu.tr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----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 PGP encrypted mail welcome -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBN3OU23t/dBlS0cqxAQFEZgQAigBO9jZyYk1E/eiZa4XspyId7IwFWpDD mkKY18zVhb7GOLZPMFneLoP7HjiOSaHW2ONP4bwblpqH3+hOexdWrChiEjo0y6vK eNuT07Cipn1OUjPHcQwMo7pfHsbBeZRm4LWZWHdx4fMaRFOHbLdov5Sc9nFdsBoX KUW2qAybVlc= =97dj -----END PGP SIGNATURE----- From owner-ietf-open-pgp@imc.org Fri Jun 25 11:53:08 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25020 for ; Fri, 25 Jun 1999 11:53:06 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA29814 for ietf-open-pgp-bks; Fri, 25 Jun 1999 07:39:40 -0700 (PDT) Received: from chi6-1.relay.mail.uu.net (chi6-1.relay.mail.uu.net [199.171.54.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA29809 for ; Fri, 25 Jun 1999 07:39:39 -0700 (PDT) Received: from xedia.com by chi6sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgvdi21362; Fri, 25 Jun 1999 14:42:23 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA24328; Fri, 25 Jun 99 10:41:21 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA22583; Fri, 25 Jun 1999 10:42:21 -0400 Date: Fri, 25 Jun 1999 10:42:21 -0400 Message-Id: <199906251442.KAA22583@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: levi@boun.edu.tr Cc: mwa@tik.ee.ethz.ch, pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: Multicast Keyserver Synchronization References: <19990624181131.L4137@tik.ee.ethz.ch> <3773897B.7EF06397@boun.edu.tr> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Content-Transfer-Encoding: 7bit >>>>> "Albert" == Albert Levi 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 From owner-ietf-open-pgp@imc.org Fri Jun 25 12:06:33 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25328 for ; Fri, 25 Jun 1999 12:06:32 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA29874 for ietf-open-pgp-bks; Fri, 25 Jun 1999 07:46:54 -0700 (PDT) Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA29870 for ; Fri, 25 Jun 1999 07:46:52 -0700 (PDT) Received: from komsys-pc-mw.ethz.ch (mwa@komsys-pc-mw [129.132.66.24]) by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id QAA01092; Fri, 25 Jun 1999 16:50:03 +0200 (MET DST) Received: (from mwa@localhost) by komsys-pc-mw.ethz.ch (8.9.3/8.8.8) id QAA07418; Fri, 25 Jun 1999 16:50:36 +0200 Date: Fri, 25 Jun 1999 16:50:35 +0200 From: Marcel Waldvogel To: Paul Koning Cc: levi@boun.edu.tr, pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: Multicast Keyserver Synchronization Message-ID: <19990625165034.U4137@tik.ee.ethz.ch> References: <19990624181131.L4137@tik.ee.ethz.ch> <3773897B.7EF06397@boun.edu.tr> <199906251442.KAA22583@tonga.xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199906251442.KAA22583@tonga.xedia.com>; from Paul Koning on Fri, Jun 25, 1999 at 10:42:21AM -0400 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, Jun 25, 1999 at 10:42:21AM -0400, Paul Koning 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 From owner-ietf-open-pgp@imc.org Fri Jun 25 12:13:59 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25501 for ; Fri, 25 Jun 1999 12:13:58 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA00178 for ietf-open-pgp-bks; Fri, 25 Jun 1999 08:03:13 -0700 (PDT) Received: from chi6-1.relay.mail.uu.net (chi6-1.relay.mail.uu.net [199.171.54.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00174 for ; Fri, 25 Jun 1999 08:03:11 -0700 (PDT) Received: from xedia.com by chi6sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgvdk17511; Fri, 25 Jun 1999 15:06:19 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA24751; Fri, 25 Jun 99 11:05:17 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA22593; Fri, 25 Jun 1999 11:06:18 -0400 Date: Fri, 25 Jun 1999 11:06:18 -0400 Message-Id: <199906251506.LAA22593@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mwa@tik.ee.ethz.ch Cc: levi@boun.edu.tr, pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: Multicast Keyserver Synchronization References: <19990624181131.L4137@tik.ee.ethz.ch> <3773897B.7EF06397@boun.edu.tr> <199906251442.KAA22583@tonga.xedia.com> <19990625165034.U4137@tik.ee.ethz.ch> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Content-Transfer-Encoding: 7bit >>>>> "Marcel" == Marcel Waldvogel writes: Marcel> On Fri, Jun 25, 1999 at 10:42:21AM -0400, Paul Koning Marcel> 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 (radia@bcn.East.Sun.COM). >> (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 From owner-ietf-open-pgp@imc.org Fri Jun 25 12:17:29 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25601 for ; Fri, 25 Jun 1999 12:17:28 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA00380 for ietf-open-pgp-bks; Fri, 25 Jun 1999 08:21:01 -0700 (PDT) Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00375 for ; Fri, 25 Jun 1999 08:20:58 -0700 (PDT) Received: from komsys-pc-mw.ethz.ch (mwa@komsys-pc-mw [129.132.66.24]) by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id RAA07748; Fri, 25 Jun 1999 17:24:06 +0200 (MET DST) Received: (from mwa@localhost) by komsys-pc-mw.ethz.ch (8.9.3/8.8.8) id RAA07526; Fri, 25 Jun 1999 17:24:39 +0200 Date: Fri, 25 Jun 1999 17:24:38 +0200 From: Marcel Waldvogel To: Paul Koning Cc: levi@boun.edu.tr, pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: Multicast Keyserver Synchronization Message-ID: <19990625172438.Z4137@tik.ee.ethz.ch> References: <19990624181131.L4137@tik.ee.ethz.ch> <3773897B.7EF06397@boun.edu.tr> <199906251442.KAA22583@tonga.xedia.com> <19990625165034.U4137@tik.ee.ethz.ch> <199906251507.LAA22599@tonga.xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199906251507.LAA22599@tonga.xedia.com>; from Paul Koning on Fri, Jun 25, 1999 at 11:07:07AM -0400 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, Jun 25, 1999 at 11:07:07AM -0400, Paul Koning 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 From owner-ietf-open-pgp@imc.org Fri Jun 25 19:20:49 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07558 for ; Fri, 25 Jun 1999 19:20:48 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA04915 for ietf-open-pgp-bks; Fri, 25 Jun 1999 15:46:32 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA04911 for ; Fri, 25 Jun 1999 15:46:25 -0700 (PDT) Received: (qmail 9462 invoked by uid 1001); 25 Jun 1999 22:48:34 -0000 Date: 25 Jun 1999 22:48:34 -0000 Message-ID: <19990625224834.5240.qmail@cr.yp.to> From: "D. J. Bernstein" To: ietf-open-pgp@imc.org, pgp-keyserver-folk@flame.org Subject: Re: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Paul Koning writes: > 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. 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 From owner-ietf-open-pgp@imc.org Wed Jun 30 12:48:58 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20917 for ; Wed, 30 Jun 1999 12:48:57 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA13674 for ietf-open-pgp-bks; Wed, 30 Jun 1999 08:32:36 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13670 for ; Wed, 30 Jun 1999 08:32:34 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA28200; Wed, 30 Jun 1999 11:36:01 -0400 Message-Id: <199906301536.LAA28200@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 30 Jun 1999 09:59:30 -0500 To: Marcel Waldvogel In-Reply-To: <19990624153938.C4137@tik.ee.ethz.ch> Cc: "teun,Tilburg University" , pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In <19990624153938.C4137@tik.ee.ethz.ch>, on 06/24/99 at 03:39 PM, Marcel Waldvogel said: >On Wed, Jun 23, 1999 at 05:41:51PM +0100, "teun, Tilburg University" > 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. > >> 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. >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. 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. -- --------------------------------------------------------------- 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 owner-ietf-open-pgp@imc.org Wed Jun 30 12:49:02 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20928 for ; Wed, 30 Jun 1999 12:49:01 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA13929 for ietf-open-pgp-bks; Wed, 30 Jun 1999 08:56:06 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13925 for ; Wed, 30 Jun 1999 08:56:05 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA28530; Wed, 30 Jun 1999 11:59:24 -0400 Message-Id: <199906301559.LAA28530@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 30 Jun 1999 10:39:25 -0500 To: Tony Mione In-Reply-To: Cc: Tony Mione , pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In , on 06/24/99 at 08:03 AM, Tony Mione said: >-----BEGIN PGP SIGNED MESSAGE----- >On Wed, 23 Jun 1999, William H. Geiger III wrote: >> In , on >> 06/22/99 >> at 10:46 PM, Tony Mione 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. >> >> >> 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?) See my example above. >> >> 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. >> >> 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. -- --------------------------------------------------------------- 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 owner-ietf-open-pgp@imc.org Wed Jun 30 12:50:09 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20958 for ; Wed, 30 Jun 1999 12:50:08 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA13733 for ietf-open-pgp-bks; Wed, 30 Jun 1999 08:36:38 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13729 for ; Wed, 30 Jun 1999 08:36:36 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA28239; Wed, 30 Jun 1999 11:38:37 -0400 Message-Id: <199906301538.LAA28239@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 30 Jun 1999 10:36:32 -0500 To: "Gaon, David" In-Reply-To: <41A8197B6ABCD2119C0600204804F0CC0F2354@rbmail101.chamb.disa.mil> Cc: Tony Mione , pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: RE: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In <41A8197B6ABCD2119C0600204804F0CC0F2354@rbmail101.chamb.disa.mil>, on 06/24/99 at 09:08 AM, "Gaon, David" said: >William Geiger wrote: >>>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. >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. -- --------------------------------------------------------------- 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 owner-ietf-open-pgp@imc.org Wed Jun 30 14:56:45 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24298 for ; Wed, 30 Jun 1999 14:56:42 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA14929 for ietf-open-pgp-bks; Wed, 30 Jun 1999 11:04:50 -0700 (PDT) Received: from kingcrab.informix.com (dns3.informix.com [192.147.112.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14924 for ; Wed, 30 Jun 1999 11:04:49 -0700 (PDT) Received: from parrot.informix.com (parrot.informix.com [158.58.8.22]) by kingcrab.informix.com (8.8.5/8.7.3) with ESMTP id LAA23905; Wed, 30 Jun 1999 11:08:25 -0700 (PDT) Received: from mp-jackr (repenning.mp.informix.com [158.58.9.204]) by parrot.informix.com (8.8.8+Sun/8.8.8) with ESMTP id LAA19302; Wed, 30 Jun 1999 11:07:54 -0700 (PDT) Message-Id: <4.2.0.56.19990630104605.00a59100@parrot> X-Sender: jackr@parrot X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Wed, 30 Jun 1999 11:04:54 -0700 To: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org From: Jack Repenning Subject: Re: PGP Keyserver Synchronization Protocol In-Reply-To: <199906301536.LAA28200@domains.invweb.net> References: <19990624153938.C4137@tik.ee.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 jackr@informix.com 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 owner-ietf-open-pgp@imc.org Wed Jun 30 15:23:09 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25203 for ; Wed, 30 Jun 1999 15:23:06 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA15129 for ietf-open-pgp-bks; Wed, 30 Jun 1999 11:23:34 -0700 (PDT) Received: from hardees.rutgers.edu (hardees.rutgers.edu [165.230.165.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA15125 for ; Wed, 30 Jun 1999 11:23:25 -0700 (PDT) Received: from localhost (mione@localhost) by hardees.rutgers.edu (8.8.8/8.8.8) with SMTP id OAA22840; Wed, 30 Jun 1999 14:27:04 -0400 (EDT) Date: Wed, 30 Jun 1999 14:27:04 -0400 (EDT) From: Tony Mione To: "William H. Geiger III" cc: Tony Mione , pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol In-Reply-To: <199906301559.LAA28530@domains.invweb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- On Wed, 30 Jun 1999, William H. Geiger III wrote: > In , on > 06/24/99 > at 08:03 AM, Tony Mione said: > > >-----BEGIN PGP SIGNED MESSAGE----- > > >On Wed, 23 Jun 1999, William H. Geiger III wrote: > > >> In , on > >> 06/22/99 > >> at 10:46 PM, Tony Mione 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----- From owner-ietf-open-pgp@imc.org Wed Jun 30 19:36:40 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02270 for ; Wed, 30 Jun 1999 19:36:39 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18726 for ietf-open-pgp-bks; Wed, 30 Jun 1999 15:50:53 -0700 (PDT) Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18722 for ; Wed, 30 Jun 1999 15:50:51 -0700 (PDT) Received: (from mwa@localhost) by tik2.ethz.ch (8.8.8/8.8.8) id AAA12836; Thu, 1 Jul 1999 00:54:22 +0200 (MET DST) From: Marcel Waldvogel Message-Id: <199906302254.AAA12836@tik2.ethz.ch> Subject: Re: PGP Keyserver Synchronization Protocol To: whgiii@openpgp.net (William H. Geiger III) Date: Thu, 1 Jul 1999 00:54:22 +2600 (MET DST) Cc: mwa@tik.ee.ethz.ch, Teun.Nijssen@kub.nl, pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org In-Reply-To: <199906301536.LAA28200@domains.invweb.net> from "William H. Geiger III" at Jun 30, 99 09:59:30 am X-Mailer: ELM [version 2.4 PL25 PGP8] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > >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. > > 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. 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18726 for ietf-open-pgp-bks; Wed, 30 Jun 1999 15:50:53 -0700 (PDT) Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18722 for ; Wed, 30 Jun 1999 15:50:51 -0700 (PDT) Received: (from mwa@localhost) by tik2.ethz.ch (8.8.8/8.8.8) id AAA12836; Thu, 1 Jul 1999 00:54:22 +0200 (MET DST) From: Marcel Waldvogel Message-Id: <199906302254.AAA12836@tik2.ethz.ch> Subject: Re: PGP Keyserver Synchronization Protocol To: whgiii@openpgp.net (William H. Geiger III) Date: Thu, 1 Jul 1999 00:54:22 +2600 (MET DST) Cc: mwa@tik.ee.ethz.ch, Teun.Nijssen@kub.nl, pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org In-Reply-To: <199906301536.LAA28200@domains.invweb.net> from "William H. Geiger III" at Jun 30, 99 09:59:30 am X-Mailer: ELM [version 2.4 PL25 PGP8] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > >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. > > 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. 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA15129 for ietf-open-pgp-bks; Wed, 30 Jun 1999 11:23:34 -0700 (PDT) Received: from hardees.rutgers.edu (hardees.rutgers.edu [165.230.165.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA15125 for ; Wed, 30 Jun 1999 11:23:25 -0700 (PDT) Received: from localhost (mione@localhost) by hardees.rutgers.edu (8.8.8/8.8.8) with SMTP id OAA22840; Wed, 30 Jun 1999 14:27:04 -0400 (EDT) Date: Wed, 30 Jun 1999 14:27:04 -0400 (EDT) From: Tony Mione To: "William H. Geiger III" cc: Tony Mione , pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol In-Reply-To: <199906301559.LAA28530@domains.invweb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- On Wed, 30 Jun 1999, William H. Geiger III wrote: > In , on > 06/24/99 > at 08:03 AM, Tony Mione said: > > >-----BEGIN PGP SIGNED MESSAGE----- > > >On Wed, 23 Jun 1999, William H. Geiger III wrote: > > >> In , on > >> 06/22/99 > >> at 10:46 PM, Tony Mione 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----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA14929 for ietf-open-pgp-bks; Wed, 30 Jun 1999 11:04:50 -0700 (PDT) Received: from kingcrab.informix.com (dns3.informix.com [192.147.112.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14924 for ; Wed, 30 Jun 1999 11:04:49 -0700 (PDT) Received: from parrot.informix.com (parrot.informix.com [158.58.8.22]) by kingcrab.informix.com (8.8.5/8.7.3) with ESMTP id LAA23905; Wed, 30 Jun 1999 11:08:25 -0700 (PDT) Received: from mp-jackr (repenning.mp.informix.com [158.58.9.204]) by parrot.informix.com (8.8.8+Sun/8.8.8) with ESMTP id LAA19302; Wed, 30 Jun 1999 11:07:54 -0700 (PDT) Message-Id: <4.2.0.56.19990630104605.00a59100@parrot> X-Sender: jackr@parrot X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Wed, 30 Jun 1999 11:04:54 -0700 To: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org From: Jack Repenning Subject: Re: PGP Keyserver Synchronization Protocol In-Reply-To: <199906301536.LAA28200@domains.invweb.net> References: <19990624153938.C4137@tik.ee.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 jackr@informix.com 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA13929 for ietf-open-pgp-bks; Wed, 30 Jun 1999 08:56:06 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13925 for ; Wed, 30 Jun 1999 08:56:05 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA28530; Wed, 30 Jun 1999 11:59:24 -0400 Message-Id: <199906301559.LAA28530@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 30 Jun 1999 10:39:25 -0500 To: Tony Mione In-Reply-To: Cc: Tony Mione , pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In , on 06/24/99 at 08:03 AM, Tony Mione said: >-----BEGIN PGP SIGNED MESSAGE----- >On Wed, 23 Jun 1999, William H. Geiger III wrote: >> In , on >> 06/22/99 >> at 10:46 PM, Tony Mione 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. >> >> >> 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?) See my example above. >> >> 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. >> >> 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. -- --------------------------------------------------------------- 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!! :) --------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA13733 for ietf-open-pgp-bks; Wed, 30 Jun 1999 08:36:38 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13729 for ; Wed, 30 Jun 1999 08:36:36 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA28239; Wed, 30 Jun 1999 11:38:37 -0400 Message-Id: <199906301538.LAA28239@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 30 Jun 1999 10:36:32 -0500 To: "Gaon, David" In-Reply-To: <41A8197B6ABCD2119C0600204804F0CC0F2354@rbmail101.chamb.disa.mil> Cc: Tony Mione , pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: RE: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In <41A8197B6ABCD2119C0600204804F0CC0F2354@rbmail101.chamb.disa.mil>, on 06/24/99 at 09:08 AM, "Gaon, David" said: >William Geiger wrote: >>>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. >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. -- --------------------------------------------------------------- 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!! :) --------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA13674 for ietf-open-pgp-bks; Wed, 30 Jun 1999 08:32:36 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13670 for ; Wed, 30 Jun 1999 08:32:34 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA28200; Wed, 30 Jun 1999 11:36:01 -0400 Message-Id: <199906301536.LAA28200@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 30 Jun 1999 09:59:30 -0500 To: Marcel Waldvogel In-Reply-To: <19990624153938.C4137@tik.ee.ethz.ch> Cc: "teun,Tilburg University" , pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In <19990624153938.C4137@tik.ee.ethz.ch>, on 06/24/99 at 03:39 PM, Marcel Waldvogel said: >On Wed, Jun 23, 1999 at 05:41:51PM +0100, "teun, Tilburg University" > 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. > >> 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. >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. 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. -- --------------------------------------------------------------- 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!! :) --------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA04915 for ietf-open-pgp-bks; Fri, 25 Jun 1999 15:46:32 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA04911 for ; Fri, 25 Jun 1999 15:46:25 -0700 (PDT) Received: (qmail 9462 invoked by uid 1001); 25 Jun 1999 22:48:34 -0000 Date: 25 Jun 1999 22:48:34 -0000 Message-ID: <19990625224834.5240.qmail@cr.yp.to> From: "D. J. Bernstein" To: ietf-open-pgp@imc.org, pgp-keyserver-folk@flame.org Subject: Re: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Paul Koning writes: > 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. 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA00380 for ietf-open-pgp-bks; Fri, 25 Jun 1999 08:21:01 -0700 (PDT) Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00375 for ; Fri, 25 Jun 1999 08:20:58 -0700 (PDT) Received: from komsys-pc-mw.ethz.ch (mwa@komsys-pc-mw [129.132.66.24]) by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id RAA07748; Fri, 25 Jun 1999 17:24:06 +0200 (MET DST) Received: (from mwa@localhost) by komsys-pc-mw.ethz.ch (8.9.3/8.8.8) id RAA07526; Fri, 25 Jun 1999 17:24:39 +0200 Date: Fri, 25 Jun 1999 17:24:38 +0200 From: Marcel Waldvogel To: Paul Koning Cc: levi@boun.edu.tr, pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: Multicast Keyserver Synchronization Message-ID: <19990625172438.Z4137@tik.ee.ethz.ch> References: <19990624181131.L4137@tik.ee.ethz.ch> <3773897B.7EF06397@boun.edu.tr> <199906251442.KAA22583@tonga.xedia.com> <19990625165034.U4137@tik.ee.ethz.ch> <199906251507.LAA22599@tonga.xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199906251507.LAA22599@tonga.xedia.com>; from Paul Koning on Fri, Jun 25, 1999 at 11:07:07AM -0400 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, Jun 25, 1999 at 11:07:07AM -0400, Paul Koning 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA00178 for ietf-open-pgp-bks; Fri, 25 Jun 1999 08:03:13 -0700 (PDT) Received: from chi6-1.relay.mail.uu.net (chi6-1.relay.mail.uu.net [199.171.54.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00174 for ; Fri, 25 Jun 1999 08:03:11 -0700 (PDT) Received: from xedia.com by chi6sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgvdk17511; Fri, 25 Jun 1999 15:06:19 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA24751; Fri, 25 Jun 99 11:05:17 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA22593; Fri, 25 Jun 1999 11:06:18 -0400 Date: Fri, 25 Jun 1999 11:06:18 -0400 Message-Id: <199906251506.LAA22593@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mwa@tik.ee.ethz.ch Cc: levi@boun.edu.tr, pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: Multicast Keyserver Synchronization References: <19990624181131.L4137@tik.ee.ethz.ch> <3773897B.7EF06397@boun.edu.tr> <199906251442.KAA22583@tonga.xedia.com> <19990625165034.U4137@tik.ee.ethz.ch> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >>>>> "Marcel" == Marcel Waldvogel writes: Marcel> On Fri, Jun 25, 1999 at 10:42:21AM -0400, Paul Koning Marcel> 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 (radia@bcn.East.Sun.COM). >> (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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA29874 for ietf-open-pgp-bks; Fri, 25 Jun 1999 07:46:54 -0700 (PDT) Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA29870 for ; Fri, 25 Jun 1999 07:46:52 -0700 (PDT) Received: from komsys-pc-mw.ethz.ch (mwa@komsys-pc-mw [129.132.66.24]) by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id QAA01092; Fri, 25 Jun 1999 16:50:03 +0200 (MET DST) Received: (from mwa@localhost) by komsys-pc-mw.ethz.ch (8.9.3/8.8.8) id QAA07418; Fri, 25 Jun 1999 16:50:36 +0200 Date: Fri, 25 Jun 1999 16:50:35 +0200 From: Marcel Waldvogel To: Paul Koning Cc: levi@boun.edu.tr, pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: Multicast Keyserver Synchronization Message-ID: <19990625165034.U4137@tik.ee.ethz.ch> References: <19990624181131.L4137@tik.ee.ethz.ch> <3773897B.7EF06397@boun.edu.tr> <199906251442.KAA22583@tonga.xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199906251442.KAA22583@tonga.xedia.com>; from Paul Koning on Fri, Jun 25, 1999 at 10:42:21AM -0400 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, Jun 25, 1999 at 10:42:21AM -0400, Paul Koning 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA29814 for ietf-open-pgp-bks; Fri, 25 Jun 1999 07:39:40 -0700 (PDT) Received: from chi6-1.relay.mail.uu.net (chi6-1.relay.mail.uu.net [199.171.54.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA29809 for ; Fri, 25 Jun 1999 07:39:39 -0700 (PDT) Received: from xedia.com by chi6sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgvdi21362; Fri, 25 Jun 1999 14:42:23 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA24328; Fri, 25 Jun 99 10:41:21 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA22583; Fri, 25 Jun 1999 10:42:21 -0400 Date: Fri, 25 Jun 1999 10:42:21 -0400 Message-Id: <199906251442.KAA22583@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: levi@boun.edu.tr Cc: mwa@tik.ee.ethz.ch, pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: Multicast Keyserver Synchronization References: <19990624181131.L4137@tik.ee.ethz.ch> <3773897B.7EF06397@boun.edu.tr> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >>>>> "Albert" == Albert Levi 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA29775 for ietf-open-pgp-bks; Fri, 25 Jun 1999 07:37:25 -0700 (PDT) Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA29770 for ; Fri, 25 Jun 1999 07:37:23 -0700 (PDT) Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id QAA00381; Fri, 25 Jun 1999 16:40:29 +0200 (MET DST) Received: from localhost (weiler@localhost) by kom30.ethz.ch (8.8.8/8.8.8) with ESMTP id QAA05230; Fri, 25 Jun 1999 16:40:29 +0200 (MET DST) X-Authentication-Warning: kom30.ethz.ch: weiler owned process doing -bs Date: Fri, 25 Jun 1999 16:40:23 +0200 (MET DST) From: Nathalie Weiler To: Albert Levi cc: Marcel Waldvogel , pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: Multicast Keyserver Synchronization In-Reply-To: <3773897B.7EF06397@boun.edu.tr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----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 PGP encrypted mail welcome -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBN3OU23t/dBlS0cqxAQFEZgQAigBO9jZyYk1E/eiZa4XspyId7IwFWpDD mkKY18zVhb7GOLZPMFneLoP7HjiOSaHW2ONP4bwblpqH3+hOexdWrChiEjo0y6vK eNuT07Cipn1OUjPHcQwMo7pfHsbBeZRm4LWZWHdx4fMaRFOHbLdov5Sc9nFdsBoX KUW2qAybVlc= =97dj -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA29016 for ietf-open-pgp-bks; Fri, 25 Jun 1999 06:35:18 -0700 (PDT) Received: from hamlin.cc.boun.edu.tr (hamlin.cc.boun.edu.tr [193.140.192.230]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA29011 for ; Fri, 25 Jun 1999 06:35:06 -0700 (PDT) Received: from boun.edu.tr (kolyoz.cmpe.boun.edu.tr [193.140.196.76]) by hamlin.cc.boun.edu.tr with ESMTP id QAA24109; Fri, 25 Jun 1999 16:25:20 +0300 (EET DST) Message-ID: <3773897B.7EF06397@boun.edu.tr> Date: Fri, 25 Jun 1999 16:51:55 +0300 From: Albert Levi Organization: Bogazici University X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Marcel Waldvogel CC: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: Multicast Keyserver Synchronization References: <19990624181131.L4137@tik.ee.ethz.ch> Content-Type: text/plain; charset=iso-8859-9 Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA04723 for ietf-open-pgp-bks; Thu, 24 Jun 1999 09:07:55 -0700 (PDT) Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA04719 for ; Thu, 24 Jun 1999 09:07:52 -0700 (PDT) Received: from komsys-pc-mw.ethz.ch (mwa@komsys-pc-mw [129.132.66.24]) by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id SAA17835; Thu, 24 Jun 1999 18:10:57 +0200 (MET DST) Received: (from mwa@localhost) by komsys-pc-mw.ethz.ch (8.9.3/8.8.8) id SAA04891; Thu, 24 Jun 1999 18:11:32 +0200 Date: Thu, 24 Jun 1999 18:11:32 +0200 From: Marcel Waldvogel To: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Multicast Keyserver Synchronization Message-ID: <19990624181131.L4137@tik.ee.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA03271 for ietf-open-pgp-bks; Thu, 24 Jun 1999 06:36:00 -0700 (PDT) Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA03267 for ; Thu, 24 Jun 1999 06:35:58 -0700 (PDT) Received: from komsys-pc-mw.ethz.ch (mwa@komsys-pc-mw [129.132.66.24]) by tik2.ethz.ch (8.8.8/8.8.8) with ESMTP id PAA07314; Thu, 24 Jun 1999 15:39:03 +0200 (MET DST) Received: (from mwa@localhost) by komsys-pc-mw.ethz.ch (8.9.3/8.8.8) id PAA04444; Thu, 24 Jun 1999 15:39:38 +0200 Date: Thu, 24 Jun 1999 15:39:38 +0200 From: Marcel Waldvogel To: "teun, Tilburg University" Cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Message-ID: <19990624153938.C4137@tik.ee.ethz.ch> References: <199906181455.KAA04509@domains.invweb.net> <199906231542.RAA23477@mailnews.kub.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199906231542.RAA23477@mailnews.kub.nl>; from Teun Nijssen on Wed, Jun 23, 1999 at 05:41:51PM +0100 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Wed, Jun 23, 1999 at 05:41:51PM +0100, "teun, Tilburg University" 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. > > 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. 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA02862 for ietf-open-pgp-bks; Thu, 24 Jun 1999 06:02:37 -0700 (PDT) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA02858 for ; Thu, 24 Jun 1999 06:02:36 -0700 (PDT) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id ; Thu, 24 Jun 1999 09:05:38 -0400 Message-ID: <41A8197B6ABCD2119C0600204804F0CC0F2354@rbmail101.chamb.disa.mil> From: "Gaon, David" To: "'William H. Geiger III'" , Tony Mione Cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: RE: PGP Keyserver Synchronization Protocol Date: Thu, 24 Jun 1999 09:08:39 -0400 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: William Geiger wrote: >>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. 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:whgiii@openpgp.net] Sent: Wednesday, June 23, 1999 10:48 AM To: Tony Mione Cc: pgp-keyserver-folk@flame.org; ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol In , on 06/22/99 at 10:46 PM, Tony Mione said: >> 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? 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. >> 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. >> 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. 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. -- --------------------------------------------------------------- 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!! :) --------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA02205 for ietf-open-pgp-bks; Thu, 24 Jun 1999 05:00:18 -0700 (PDT) Received: from hardees.rutgers.edu (hardees.rutgers.edu [128.6.18.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA02201 for ; Thu, 24 Jun 1999 05:00:17 -0700 (PDT) Received: from localhost (mione@localhost) by hardees.rutgers.edu (8.8.8/8.8.8) with SMTP id IAA12975; Thu, 24 Jun 1999 08:03:36 -0400 (EDT) Date: Thu, 24 Jun 1999 08:03:35 -0400 (EDT) From: Tony Mione To: "William H. Geiger III" cc: Tony Mione , pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol In-Reply-To: <199906231553.LAA07587@domains.invweb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- On Wed, 23 Jun 1999, William H. Geiger III wrote: > In , on > 06/22/99 > at 10:46 PM, Tony Mione 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 :) > > >> 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 > >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. > 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. > > -- > --------------------------------------------------------------- > William H. Geiger III http://www.openpgp.net >... > > 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. iQCVAwUBN3IeiQfNcGHdn+zRAQGVCAQAwCUHz2eFTo2q38KKe8rxOg4RGObSuDW2 REaMACGvY4uAQeJjBYYjOHv+vVx9J4YtSW+zyUy8vg85r4QjrX3568fUKzj1L7nk JA8PZkJW8FgJLVzxYM4mQK1a1teLY0vAF/21uCfb8rST8e/WJNOEZf904GueJNKU FzO2Ly0gUAk= =D5Fv -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA01749 for ietf-open-pgp-bks; Thu, 24 Jun 1999 04:43:47 -0700 (PDT) Received: from hardees.rutgers.edu (hardees.rutgers.edu [128.6.18.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA01738 for ; Thu, 24 Jun 1999 04:43:42 -0700 (PDT) Received: from localhost (mione@localhost) by hardees.rutgers.edu (8.8.8/8.8.8) with SMTP id HAA12593; Thu, 24 Jun 1999 07:46:34 -0400 (EDT) Date: Thu, 24 Jun 1999 07:46:34 -0400 (EDT) From: Tony Mione To: Werner Koch cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol In-Reply-To: <19990623095541.F30893@frodo.isil.d.shuttle.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- On Wed, 23 Jun 1999, Werner Koch wrote: > Tony Mione writes: > > > 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. > > 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. > 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. > > -- > Werner Koch at guug.de www.gnupg.org keyid 621CC013 > > 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. iQCVAwUBN3IaiAfNcGHdn+zRAQH9oQQAg6lWFPtYsnh2yieC2BSmIa3cDnT9aRyV sDYdLKI1ups5mG0HpGRzDtpM/iKBwevenirK4uSfy2GMFOQo7FCn2FrFCqiyBe8V aKVMpjVN08p+OsC2ZzFP2qPLLfvNXgtFYCq56fzt2V6/9IQX283VskbJ5xZ1eHUU PxJqV4doIW0= =UOl7 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18670 for ietf-open-pgp-bks; Wed, 23 Jun 1999 11:29:20 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18666 for ; Wed, 23 Jun 1999 11:29:18 -0700 (PDT) Received: from [10.5.63.113] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 23 Jun 1999 10:32:15 -0800 X-Sender: jon@127.0.0.1 Message-Id: In-Reply-To: References: <199906181455.KAA04509@domains.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Jun 1999 11:23:33 -0700 To: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org From: Jon Callas Subject: Re: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA17095 for ietf-open-pgp-bks; Wed, 23 Jun 1999 09:27:20 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17090 for ; Wed, 23 Jun 1999 09:27:18 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQguwg05441; Wed, 23 Jun 1999 16:30:09 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA26823; Wed, 23 Jun 99 12:29:08 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA11317; Wed, 23 Jun 1999 12:30:04 -0400 Date: Wed, 23 Jun 1999 12:30:04 -0400 Message-Id: <199906231630.MAA11317@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: whgiii@openpgp.net Cc: wk@isil.d.shuttle.de, pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol References: <19990623095541.F30893@frodo.isil.d.shuttle.de> <199906231538.LAA07314@domains.invweb.net> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >>>>> "William" == William H Geiger 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA16922 for ietf-open-pgp-bks; Wed, 23 Jun 1999 09:12:59 -0700 (PDT) Received: from scryer.mentat.com ([192.88.122.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA16918 for ; Wed, 23 Jun 1999 09:12:54 -0700 (PDT) Received: from acm.org (localhost [127.0.0.1]) by scryer.mentat.com (8.8.7/8.8.7) with ESMTP id JAA05661; Wed, 23 Jun 1999 09:16:31 -0700 Message-ID: <3771085E.3FE8906@acm.org> Date: Wed, 23 Jun 1999 09:16:30 -0700 From: Jim Gillogly Organization: Banzai Institute X-Mailer: Mozilla 4.07 [en] (X11; U; Linux 2.2.0 i686) MIME-Version: 1.0 To: "William H. Geiger III" , Werner Koch CC: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: William H. Geiger III wrote: > 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. 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16653 for ietf-open-pgp-bks; Wed, 23 Jun 1999 08:51:07 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16646 for ; Wed, 23 Jun 1999 08:51:06 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA07587; Wed, 23 Jun 1999 11:53:59 -0400 Message-Id: <199906231553.LAA07587@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 23 Jun 1999 09:47:50 -0500 To: Tony Mione In-Reply-To: Cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In , on 06/22/99 at 10:46 PM, Tony Mione said: >> 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? 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. >> 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. >> 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. 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. -- --------------------------------------------------------------- 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!! :) --------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16494 for ietf-open-pgp-bks; Wed, 23 Jun 1999 08:39:44 -0700 (PDT) Received: from mailnews.kub.nl (mailnews.kub.nl [137.56.0.220]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16490 for ; Wed, 23 Jun 1999 08:39:43 -0700 (PDT) Received: from drc1.kub.nl (drc1.kub.nl [137.56.248.50]) by mailnews.kub.nl (8.8.8/8.8.8) with ESMTP id RAA23477; Wed, 23 Jun 1999 17:42:08 +0200 (MET DST) Message-Id: <199906231542.RAA23477@mailnews.kub.nl> Received: from DRC_1/SpoolDir by drc1.kub.nl (Mercury 1.44); 23 Jun 99 17:42:08 MET Received: from SpoolDir by DRC_1 (Mercury 1.44); 23 Jun 99 17:42:00 MET From: "teun, Tilburg University" Organization: Tilburg University To: Tony Mione Date: Wed, 23 Jun 1999 17:41:51 MET MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: PGP Keyserver Synchronization Protocol CC: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org References: <199906181455.KAA04509@domains.invweb.net> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.01d) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16445 for ietf-open-pgp-bks; Wed, 23 Jun 1999 08:35:49 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16441 for ; Wed, 23 Jun 1999 08:35:46 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA07314; Wed, 23 Jun 1999 11:38:28 -0400 Message-Id: <199906231538.LAA07314@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 23 Jun 1999 10:28:49 -0500 To: Werner Koch In-Reply-To: <19990623095541.F30893@frodo.isil.d.shuttle.de> Cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In <19990623095541.F30893@frodo.isil.d.shuttle.de>, on 06/23/99 at 09:55 AM, Werner Koch said: >Tony Mione writes: >> 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. >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. 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. -- --------------------------------------------------------------- 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!! :) --------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA28657 for ietf-open-pgp-bks; Wed, 23 Jun 1999 01:18:31 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA28640 for ; Wed, 23 Jun 1999 01:18:26 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id KAA13696 for ietf-open-pgp@imc.org; Wed, 23 Jun 1999 10:21:21 +0200 (MET DST) Received: from (frodo.isil.d.shuttle.de) [172.20.1.4] (mail) by beren.isil.d.shuttle.de with esmtp (Exim 1.92 #1 (Debian)) id 10whvC-0000l2-00; Wed, 23 Jun 1999 09:58:14 +0200 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10whsj-00083F-00; Wed, 23 Jun 1999 09:55:41 +0200 Date: Wed, 23 Jun 1999 09:55:41 +0200 From: Werner Koch To: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol Message-ID: <19990623095541.F30893@frodo.isil.d.shuttle.de> Mail-Followup-To: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org References: <199906181455.KAA04509@domains.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: ; from Tony Mione on Tue, Jun 22, 1999 at 10:46:44PM -0400 X-URL: http://www.openit.de/wks Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tony Mione writes: > 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. 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA02405 for ietf-open-pgp-bks; Tue, 22 Jun 1999 19:44:16 -0700 (PDT) Received: from hardees.rutgers.edu (hardees.rutgers.edu [128.6.18.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA02368 for ; Tue, 22 Jun 1999 19:44:06 -0700 (PDT) Received: from localhost (mione@localhost) by hardees.rutgers.edu (8.8.8/8.8.8) with SMTP id WAA23678; Tue, 22 Jun 1999 22:46:44 -0400 (EDT) Date: Tue, 22 Jun 1999 22:46:44 -0400 (EDT) From: Tony Mione To: "William H. Geiger III" cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: Re: PGP Keyserver Synchronization Protocol In-Reply-To: <199906181455.KAA04509@domains.invweb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----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----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA29919 for ietf-open-pgp-bks; Mon, 21 Jun 1999 16:13:38 -0700 (PDT) Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA29915 for ; Mon, 21 Jun 1999 16:13:33 -0700 (PDT) Received: from max1-010.public.uni-hamburg.de (max1-010.public.uni-hamburg.de [134.100.43.10]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id BAA79620 for ; Tue, 22 Jun 1999 01:16:19 +0200 Received: id ; Mon, 21 Jun 1999 23:32:49 +0200 (CEST) Message-Id: Date: Mon, 21 Jun 1999 23:32:49 +0200 (CEST) From: Bodo_Moeller@public.uni-hamburg.de (Bodo Moeller) To: ietf-open-pgp@imc.org Subject: Re: V5 signatures In-Reply-To: <199906181452.KAA04459@domains.invweb.net> References: <19990528123701.A28938@frodo.isil.d.shuttle.de> <199906181452.KAA04459@domains.invweb.net> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: "William H. Geiger III" : > 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22158 for ietf-open-pgp-bks; Mon, 21 Jun 1999 04:44:12 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22154 for ; Mon, 21 Jun 1999 04:44:06 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id NAA26315 for ietf-open-pgp@imc.org; Mon, 21 Jun 1999 13:46:41 +0200 (MET DST) Received: from (frodo.isil.d.shuttle.de) [172.20.1.4] (mail) by beren.isil.d.shuttle.de with esmtp (Exim 1.92 #1 (Debian)) id 10w2B1-00087B-00; Mon, 21 Jun 1999 13:23:47 +0200 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10w289-000834-00; Mon, 21 Jun 1999 13:20:49 +0200 Date: Mon, 21 Jun 1999 13:20:49 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Agree with PRZs MDC suggestion Message-ID: <19990621132049.C30822@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <9905280526.AA23486@buoy.watson.ibm.com> <19990528212200.A3334@epsilon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <19990528212200.A3334@epsilon>; from Bodo Moeller on Fri, May 28, 1999 at 09:22:02PM +0200 X-URL: http://www.openit.de/wks Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Bodo Moeller 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? -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20323 for ietf-open-pgp-bks; Sat, 19 Jun 1999 14:28:52 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20319 for ; Sat, 19 Jun 1999 14:28:49 -0700 (PDT) Received: from [10.5.63.113] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Sat, 19 Jun 1999 13:31:28 -0800 X-Sender: jon@127.0.0.1 Message-Id: In-Reply-To: <199906191410.KAA26618@domains.invweb.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 19 Jun 1999 14:11:52 -0700 To: "William H. Geiger III" From: Jon Callas Subject: Re: V5 signatures Cc: hal@finney.org, wk@isil.d.shuttle.de, ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA18758 for ietf-open-pgp-bks; Sat, 19 Jun 1999 07:07:57 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA18754 for ; Sat, 19 Jun 1999 07:07:56 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id KAA26618; Sat, 19 Jun 1999 10:10:15 -0400 Message-Id: <199906191410.KAA26618@domains.invweb.net> From: "William H. Geiger III" Date: Fri, 18 Jun 1999 22:06:55 -0500 To: Jon Callas In-Reply-To: Cc: hal@finney.org, wk@isil.d.shuttle.de, ietf-open-pgp@imc.org Subject: Re: V5 signatures Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In , on 06/18/99 at 07:17 PM, Jon Callas said: >At 5:47 PM -0700 6/18/1999, hal@finney.org 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. -- --------------------------------------------------------------- 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!! :) --------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA15111 for ietf-open-pgp-bks; Fri, 18 Jun 1999 19:15:23 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA15107 for ; Fri, 18 Jun 1999 19:15:21 -0700 (PDT) Received: from [10.5.63.113] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Fri, 18 Jun 1999 18:17:56 -0800 X-Sender: jon@127.0.0.1 Message-Id: In-Reply-To: <199906190047.RAA17911@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Jun 1999 19:17:10 -0700 To: hal@finney.org, whgiii@openpgp.net, wk@isil.d.shuttle.de From: Jon Callas Subject: Re: V5 signatures Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 5:47 PM -0700 6/18/1999, hal@finney.org 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA10310 for ietf-open-pgp-bks; Fri, 18 Jun 1999 17:47:50 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA10305 for ; Fri, 18 Jun 1999 17:47:45 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id RAA17911; Fri, 18 Jun 1999 17:47:54 -0700 Date: Fri, 18 Jun 1999 17:47:54 -0700 Message-Id: <199906190047.RAA17911@finney.org> To: jon@callas.org, whgiii@openpgp.net, wk@isil.d.shuttle.de Subject: Re: V5 signatures Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas, , 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA09601 for ietf-open-pgp-bks; Fri, 18 Jun 1999 17:04:35 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA09597 for ; Fri, 18 Jun 1999 17:04:32 -0700 (PDT) Received: from [10.5.63.113] (38.232.7.4) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Fri, 18 Jun 1999 16:07:04 -0800 X-Sender: jon@127.0.0.1 Message-Id: In-Reply-To: <199906181452.KAA04459@domains.invweb.net> References: <19990528123701.A28938@frodo.isil.d.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Jun 1999 17:06:27 -0700 To: "William H. Geiger III" , Werner Koch From: Jon Callas Subject: Re: V5 signatures Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02012 for ietf-open-pgp-bks; Fri, 18 Jun 1999 08:06:08 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02007 for ; Fri, 18 Jun 1999 08:06:06 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA04762; Fri, 18 Jun 1999 11:08:38 -0400 Message-Id: <199906181508.LAA04762@domains.invweb.net> From: "William H. Geiger III" Date: Fri, 18 Jun 1999 10:05:43 -0500 To: whgiii@openpgp.net Cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: PGP Keyserver Synchronization Protocol (corrected) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Sorry, I didn't run the spell checker over the previous post. 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 compare 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 compare 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 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: #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. 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: 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 synchronization 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/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: 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 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. -- --------------------------------------------------------------- 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!! :) --------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA01867 for ietf-open-pgp-bks; Fri, 18 Jun 1999 07:53:22 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA01862 for ; Fri, 18 Jun 1999 07:53:21 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id KAA04509; Fri, 18 Jun 1999 10:55:46 -0400 Message-Id: <199906181455.KAA04509@domains.invweb.net> From: "William H. Geiger III" Date: Fri, 18 Jun 1999 09:43:36 -0500 To: whgiii@openpgp.net Cc: pgp-keyserver-folk@flame.org, ietf-open-pgp@imc.org Subject: PGP Keyserver Synchronization Protocol Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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 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!! :) --------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA01838 for ietf-open-pgp-bks; Fri, 18 Jun 1999 07:50:20 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA01834 for ; Fri, 18 Jun 1999 07:50:18 -0700 (PDT) Received: from whgiii (IDENT:root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id KAA04459; Fri, 18 Jun 1999 10:52:38 -0400 Message-Id: <199906181452.KAA04459@domains.invweb.net> From: "William H. Geiger III" Date: Fri, 18 Jun 1999 09:48:00 -0500 To: Werner Koch In-Reply-To: <19990528123701.A28938@frodo.isil.d.shuttle.de> Cc: ietf-open-pgp@imc.org Subject: Re: V5 signatures Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In <19990528123701.A28938@frodo.isil.d.shuttle.de>, on 05/28/99 at 05:37 AM, Werner Koch said: >Werner Koch 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. -- --------------------------------------------------------------- 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!! :) --------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA22535 for ietf-open-pgp-bks; Mon, 14 Jun 1999 12:21:06 -0700 (PDT) Received: from relay.gw.tislabs.com (firewall-user@relay.gw.tislabs.com [192.94.214.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA22531 for ; Mon, 14 Jun 1999 12:21:04 -0700 (PDT) Received: by relay.gw.tislabs.com; id PAA23629; Mon, 14 Jun 1999 15:38:23 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by relay.gw.tislabs.com via smap (4.1) id xma023623; Mon, 14 Jun 99 15:38:23 -0400 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.1/8.9.1) id PAA24873 for ietf-open-pgp@imc.org; Mon, 14 Jun 1999 15:17:31 -0400 (EDT) Date: Mon, 14 Jun 1999 15:17:31 -0400 (EDT) From: "David M. Balenson" Message-Id: <199906141917.PAA24873@clipper.gw.tislabs.com> To: ietf-open-pgp@imc.org Subject: NDSS 2000 SUBMISSION DEADLINE EXTENDED TO JUNE 23RD Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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