David M. Balenson | 14 Jun 21:17 1999

NDSS 2000 SUBMISSION DEADLINE EXTENDED TO JUNE 23RD


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

William H. Geiger III | 18 Jun 16:43 1999
Picon

PGP Keyserver Synchronization Protocol

pgpk-sync-00.txt
PGP Keyserver Synchronization Protocol -- Initial Proposal
William H. Geiger III
Geiger Consulting
whgiii <at> 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:

(Continue reading)

William H. Geiger III | 18 Jun 16:48 1999
Picon

Re: V5 signatures

In <19990528123701.A28938 <at> frodo.isil.d.shuttle.de>, on 05/28/99 
   at 05:37 AM, Werner Koch <wk <at> isil.d.shuttle.de> said:

>Werner Koch <wk <at> isil.d.shuttle.de> 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

(Continue reading)

William H. Geiger III | 18 Jun 17:05 1999
Picon

PGP Keyserver Synchronization Protocol (corrected)

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 <at> 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
(Continue reading)

Jon Callas | 19 Jun 02:06 1999

Re: V5 signatures

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

hal | 19 Jun 02:47 1999

Re: V5 signatures

Jon Callas, <jon <at> callas.org>, 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

Jon Callas | 19 Jun 04:17 1999

Re: V5 signatures

At 5:47 PM -0700 6/18/1999, hal <at> 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

William H. Geiger III | 19 Jun 05:06 1999
Picon

Re: V5 signatures

In <v04003a03b390ad882d32 <at> [10.5.63.113]>, on 06/18/99 
   at 07:17 PM, Jon Callas <jon <at> callas.org> said:

>At 5:47 PM -0700 6/18/1999, hal <at> 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 &
(Continue reading)

Jon Callas | 19 Jun 23:11 1999

Re: V5 signatures

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

Werner Koch | 21 Jun 13:20 1999
Picon

Re: Agree with PRZs MDC suggestion

Bodo Moeller <Bodo_Moeller <at> public.uni-hamburg.de> 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


Gmane