Subject: Re: Adding in BZ2 compression?

From: "Hal Finney" <[email-masked]>
Date: Thu, 3 Jul 2003 19:05:16 -0700

Jon Callas writes:
> I have a request for an algorithm number for bz2 compression. The
> implementer in question has promised on a stack of holy books only to use it
> along with compression prefs. Anyone object strongly?

I don't see a need to add another compression algorithm unless there is
something wrong with the ones we already have.  Adding a new one can only
hurt interoperability in the long run.  What is the reason for adding it?

Hal Finney

---

From: David Shaw <[email-masked]>
Date: Fri, 4 Jul 2003 00:21:50 -0400

On Thu, Jul 03, 2003 at 07:05:16PM -0700, Hal Finney wrote:
> > implementer in question has promised on a stack of holy books only
> > to use it along with compression prefs. Anyone object strongly?
> 

I don't have strong feelings for or against adding bz2, but your
comment about interoperability raises a related issue.  In theory, the
preference system would prevent the use of bz2 except when it can be
properly handled by the recipient so there should be no
interoperability issues.

Of course, that's theory.  The preference system works quite well on
paper, but unfortunately fails in the case where a key is generated in
an implementation that can use bz2 and the public key is distributed.
Later, the user changes their implementation to one that cannot use
bz2.  Anyone sending a message to that public key has the belief that
bz2 can be safely used, and may well use it, causing a problem since
the user's new implementation cannot handle bz2 (even though their key
claims they can).

I have already seen a few examples of this problem (a PGP-generated
key with an IDEA pref being used on GnuPG, and a GnuPG-generated key
with a ZLIB pref being used on PGP).

I don't think the answer here is to restrict the use of new
algorithms.  2440 has this to say, which pretty much eliminates the
problem in the design:

   Since a self-signature contains important information about the
   key's use, an implementation SHOULD allow the user to rewrite the
   self-signature, and important information in it, such as
   preferences and key expiration.

I don't advocate making any severe changes in the preference system,
but perhaps the language here could be made a bit stronger?  Something
like "Note that without the ability to rewrite a self-signature,
interoperability issues may occur when the same key is used in more
than one implementation." would be great.

David

---

From: Bill Frantz <[email-masked]>
Date: Mon, 7 Jul 2003 11:58:57 -0700

At 9:21 PM -0700 7/3/03, David Shaw wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>...

I realize this suggestion is getting into UI issues, but...

Perhaps implementations should also warn the user if the user's public key
includes features that are not supported by the implementation, and offer
to generate a new self-signature that does not include those features.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz           | "A Jobless Recovery is | Periwinkle -- Consulting
(408)356-8506         | like a Breadless Sand- | 16345 Englewood Ave.
[email-masked] | wich." -- Steve Schear | Los Gatos, CA 95032, USA

---

From: David Shaw <[email-masked]>
Date: Mon, 7 Jul 2003 23:54:51 -0400

On Mon, Jul 07, 2003 at 11:58:57AM -0700, Bill Frantz wrote:

> Perhaps implementations should also warn the user if the user's
> public key includes features that are not supported by the
> implementation, and offer to generate a new self-signature that does
> not include those features.

It's a good idea, and in fact has been on my todo list for GnuPG for a
little while now.  It's one of those things that sounds easy, but is
actually pretty fussy to do (What if there is more than one self-sig?
What if the user later removes a self-sig with safe permissions,
leaving a self-sig with unsafe permissions?  Etc).  Nothing
unsolvable, but there are a lot of corner cases.

That said, should such a thing be mentioned in 2440bis?  I'm not sure.
I certainly wouldn't be against something like "Implementations MAY
wish to warn the user when importing a key that has preferences that
contradict the capabilities of the implementation".

David