Mailing List Archive

Some suggestions
Hi,

After browsing through the latest draft I have some remarks:

1) The comment packets are gone.
Ooops. How can write code when the specification is changed at
will. I was lucky to find a solution for the moved comment packet
number from 14 to 16 - and now there is no comment packet at all.
So what shall I do? Go back to RFC1991 or stay with comment packet
of type 16?

Comment packets are very useful: I use them to store the factorization
of the ElGamal prime (in case someone wants to check it), store
a program version number to make debugging easier. Another use is
to transport additional informations to other programs in a pipeline.

*Please put the comment packets back into OpenPGP*

2) We need a new compression algorithm.
The ZIP algorithm with id 1 is not described in a RFC and
the support in zlib is not documented. I suggest a ZIP
algorithm with id 2 which complies to RFC1950.

3) 4 new signature classes 0x14 to 0x17
which are like 0x10..0x13 but do a hash over all preceding
user id packets. This has the advantage of keeping a public
key certificate small but a signator is still able to sign
more than one user-id.

4) A signature class which can used to sign the complete
public key certificate would be very nice - or is there
already one which can be used for this purpose?

All these enhancements may be OPTIONAL.


Werner
Re: Some suggestions [ In reply to ]
Bill Frantz <frantz@netcom.com> writes:

> The version of ZIP in Java 1.1.3 has memory leaks and isn't thread safe. I
> don't know about other implementations using zlib.

Is this zlib version 1.0.4, Jul 24th, 1996?
That one is thread safe - it was one of the goals:

zlib 1.0.4 is a general purpose data compression library. All the code
is reentrant (thread safe). The data format used by the zlib library
is described by RFCs (Request for Comments) 1950 to 1952 in the files

And _many_ tools link against this lib.


Werner
Re: Some suggestions [ In reply to ]
At 4:57 AM -0800 4/28/98, Werner Koch wrote:
> 2) We need a new compression algorithm.
> The ZIP algorithm with id 1 is not described in a RFC and
> the support in zlib is not documented. I suggest a ZIP
> algorithm with id 2 which complies to RFC1950.

The version of ZIP in Java 1.1.3 has memory leaks and isn't thread safe. I
don't know about other implementations using zlib.



-------------------------------------------------------------------------
Bill Frantz | If hate must be my prison | Periwinkle -- Consulting
(408)356-8506 | lock, then love must be | 16345 Englewood Ave.
frantz@netcom.com | the key. - Phil Ochs | Los Gatos, CA 95032, USA
Re: Some suggestions [ In reply to ]
At 02:57 PM 4/28/98 +0200, Werner Koch wrote:

1) The comment packets are gone.
Ooops. How can write code when the specification is changed at
will. I was lucky to find a solution for the moved comment packet
number from 14 to 16 - and now there is no comment packet at all.
So what shall I do? Go back to RFC1991 or stay with comment packet
of type 16?

Comment packets are very useful: I use them to store the factorization
of the ElGamal prime (in case someone wants to check it), store
a program version number to make debugging easier. Another use is
to transport additional informations to other programs in a pipeline.

*Please put the comment packets back into OpenPGP*

The comment packet is gone at the area director's request. The uses you
give for it are good ones, but other protocols with similar features have
also had them removed. However, if you want to carry meta-data in a
pipeline, there's no reason why you can't use packets 60-63 for this. They
are specifically reserved for private or experimental use.

3) 4 new signature classes 0x14 to 0x17
which are like 0x10..0x13 but do a hash over all preceding
user id packets. This has the advantage of keeping a public
key certificate small but a signator is still able to sign
more than one user-id.

4) A signature class which can used to sign the complete
public key certificate would be very nice - or is there
already one which can be used for this purpose?

These are both good features for post-V1. Presently, the packets in a
certificate can be re-ordered. Not arbitrarily, but sigs under a given user
id can be reordered, and the user names themselves can be reordered.
Because of this, there's no way to specify what it means for a user id to
be preceding, or what order to hash the whole thing. I think this is a
wonderful use for the extension mechanism -- you could write into an
extension (notation) the values of the other user names you wanted to sign.

Jon





-----
Jon Callas jon@pgp.com
CTO, Total Network Security 4200 Bohannon Drive
Network Associates, Inc. Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)