Implications of a common private keys directory in 2.1

Carola Grunwald caro at
Wed Nov 23 18:26:28 CET 2016

Peter Lebbing <peter at> wrote:

>On 23/11/16 10:53, Andrew Gallagher wrote:
>> If the message is being automatically decrypted at the MTA then it
>> provides no more security than TLS.
>I could concur with this statement if we amend it a little: when two
>MTA's are explicitly configured as TLS peers. They have to abort the
>mail exchange when TLS can't be negotiated and when the certificate is
>not as expected. "Expected" can mean: DN checking, issuer checking,
>fingerprint checking, perhaps CRL checking.
>There are many problems preventing succesful TLS on SMTP. It's trivial
>to downgrade, and certificates are only checked whether they are valid
>in the general sense, not even the DN is checked. I could MITM a
>connection to, present a valid certificate for
>, and the peer would accept it even though it
>isn't valid *for*. Basically, it only works for passive
>But since the OpenPGP-protected mail payload would also require explicit
>configuration, I don't think it is actually a disadvantage of TLS in
>this case...
>I'm not completely sure the "explicitly configured TLS" doesn't have a
>snag somewhere that complicates stuff more, though... I vaguely remember
>something like that from a presentation...

Pardon me when I disgress too much from the original problem, but my
system carries a TLS certificate database of all external servers it
ever contacted, and, based on the certificate's fingerprint, you can
choose from that list which host connections you allow.

Kind regards


More information about the Gnupg-users mailing list