ietf-openpgp
[Top] [All Lists]

Re: OpenPGP conformance : MUSTS found in RFC2440

1999-07-21 14:12:41
At 12:34 PM -0700 7/21/1999, Michael Elkins said:


   It seems like this wording could lead to sever interoperability problems.

Actually, though, that wording is there intentionally and carefully.

PGP has, since Day 1, compressed. It's also supported not compressing, but it was something you had to manually turn on.

It is desirable if the minimal PGP implementation could be built without putting in compression. Think pager.

Consequently, that's the reason for the wording you'll find there.

It's true (2.1) that PGP usually compresses. Always has, and arguably should in the vast majority of circumstances. (Although one could also argue that in some circumstances, like small messages, it's better not to compress. On the other other hand, you could also argue that compressing, even when the compressed data is bigger than uncompressed, has better security characteristics. But I'll bet you could also argue on the other other other hand that this is hooey.) This is really an issue for the developers, though.

I think that the wording in 2.3 (MAY) is correct. We don't want to say SHOULD, I don't think. It is usual, common practice, to compress messages. I personally encourage implementers to compress, but at something with a little less volume than SHOULD. Certainly, it is good practice to compress, and your user community will scream bloody murder if you don't. But is SHOULD the right word? It's always seemed a little too strong to me, because I want to allow my mythical encrypted pager network to not implement compression.

The SHOULD in 9.3 is perhaps a bit problematic. If you implement compression, ZIP is the algorithm to implement. Perhaps this really means that the MAY in 2.3 ought to be a SHOULD, and just be done with it. That's certainly the easiest change to make. The more I think about this as I write this note, I think that's the correct change to make -- MAY in 2.3 becomes SHOULD.

There's a related issue here, too, and that's dealing with the compression preference. If you *don't* implement compression, you have to start marking your certs with a compression preference that says you don't speak compression. If you don't, people will send you compressed messages that you can't uncompress. Should this be an implementation note?

        Jon