[Top] [All Lists]

Preference Conformance

1999-07-21 14:42:24
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.


<Prev in Thread] Current Thread [Next in Thread>
  • Preference Conformance, Jon Callas <=