Subject: Preference Conformance

From: Jon Callas <[email-masked]>
Date: Wed, 21 Jul 1999 14:35:38 -0700

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