Subject: Re: V5 signatures

From: [email-masked]
Date: Fri, 18 Jun 1999 17:47:54 -0700

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

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

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

Hal

---

From: Jon Callas <[email-masked]>
Date: Fri, 18 Jun 1999 19:17:10 -0700

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

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: "William H. Geiger III" <[email-masked]>
Date: Fri, 18 Jun 1999 22:06:55 -0500

In <v04003a03b390ad882d32@[10.5.63.113]>, on 06/18/99 

>signature packet is that it is a self-describing object with a tag and a

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: Jon Callas <[email-masked]>
Date: Sat, 19 Jun 1999 14:11:52 -0700

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