There are also some conformance issues with all the preferences. An
implementation SHOULD implement the preferences, but even if they
don't, there is expected behavior.
A compliant application has to do some right thing with all the preferences.
The biggest one is the symmetric algorithm preferences. An
application has to pick an algorithm from the recipient(s) collective
allowable algorithms. Since 3DES is MUST-implement, it's the fallback
algorithm. I know that some implementations don't do this; they pick
one of the sender's preferred algorithms. I can think of a few cases
that need to be tested:
(1) Make a key that supports "only" (say) Blowfish. Verify that an
implementation uses either Blowfish or 3DES (since 3DES is always
implicitly permissible -- this is why I put "only" in quotes. You
can't have a key that literally only supports Blowfish, but you know
what I mean for these testing purposes). Do the same with 3DES, and
verify that they use 3DES.
(2) Verify that the implementation treats no preference packet as a
preference for 3DES.
(3) Create a key that supports only CAST. Encrypt a message to both
it and the above key that supports only Blowfish. Verify that the
implementation uses 3DES.
Note that the minimal implementation doesn't implement this
preference, and only implements 3DES. It passes all the above tests
by always using 3DES.
There's some similar testing that needs to be done for compression.
Verify that a key with a no-compress preference doesn't get
compressed to. Verify that the implementation doesn't use ZLIB unless
it's in the recipient's preference allows it.
This preference is different from the others in that if it is NOT
present, it means you speak ZIP. As I said in the previous message, a
minimal implementation that does not implement compression has to
implement the preference.
Sigh. I'm thinking more about this. MUST all implementations do the
compression pref at least to the point of recognizing when not to
compress? It looks like it to me.
No testing needs to be done for preferred hash algorithms. Typically,
a signer doesn't know who is going to verify a signature. This
preference is there so that a protocol built on top of OpenPGP can
say useful things to its partner.
Similarly, there's not much testing that we can do for key server
preferences in 2440 conformance. The implementations SHOULD allow a
user to set them up. The key server itself, though, acts on the
preferences.
Jon