scope of standard authority (was: Re: How to "activate" gpg.conf entries?)

[David Shaw]

On Jul 11, 2012, at 11:09 AM, Hauke Laging wrote:

> Am Mi 11.07.2012, 16:54:27 schrieb Kristian Fiskerstrand:
> 
>> Note that as per RFC4880 this will still not remove SHA1[0: 13.3.2.]
>> or 3DES[0: 13.2.], as these are appended tacitly to be able to ensure
>> a matching set between implementations.
> 
> Does it make sense that a standard overrides a user's decision to prefer 
> security over compatibility (sure, you can still check afterwards what has 
> happened but that can be difficult especially if gpg is not used directly but 
> called by a MUA e.g.)? As someone stated here recently, he would rather not 
> make a signature at all than one which he considers unsafe.

The standard specifies how algorithms are chosen and ensures that communication can always take place (eg. "if all else fails, pick 3DES").  It does not mandate that the message must be sent.

It is obviously legal for a client to say "I settled on 3DES, but you don't permit 3DES, so I give up - I'm not able to continue".  The standard controls how messages are generated, and if the client gives up before generating the message, the standard is not involved.  It is not legal for the client to say "I settled on 3DES, but you don't permit 3DES, so I'm going to use AES instead".

It's important to differentiate between signing and encryption here.  For encryption, 3DES is the fallback algorithm, and the standard is very clear - it's an explicit MUST NOT to use any algorithm that isn't in the preference list.  For signing, it's not as simple - for example, there is no explicit recipient (and therefore no preference list) when signing without encrypting, such as is done on a mailing list.  The standard acknowledges this and leaves it up to the signer to pick an algorithm, with the obvious caveat that the signer can make a message that can't be verified.

David