Re: [Endymail] spam versus cleartext

[Viktor Dukhovni <[e-mail]>]

On Sun, Sep 07, 2014 at 07:06:54PM -0400, John R Levine wrote:

> Take current implementations of S/MIME and adjust them to allow
> self-signed certificates in addition to (or instead of) ones signed by
> a list of CAs configured into the MUA.

Apple's desktop Mail.app allows one (via Keychain) to bind a
particular (self-signed or not) key to a particular sender.  With
Outlook the only choice is to trust the issuing CA for all addresses.

As for what the IETF can do, maybe address sign-then-encrypt vs.
encrypt-then-sign in S/MIME unless I missed the memo and this is
no longer an issue.

The SMIMEA draft is not yet published, I don't recall seeing a
mechanism there to explicitly publish domain (gateway) keys, in
addition to or instead of keys for each user.  Perhaps wildcard
DNS entries can simulate gateway keys.

When SMIMEA records supply only the hash of a trust anchor, or of
a user certificate, rather than the key, then the relevant public
keys would have to be conveyed in band.  For example via a reply
from the user as suggested by Phillip Hallam-Baker.  Thus SMIMEA
is compatible with various more detailed models of key distribution.

SMIMEA might not directly expose the actual public keys of individual
users or even their hashes, rather it could simply publish a fixed
certification authority that issues X.509 email certificates to
the users of a domain.  This can make the initial contact leaf of
faith more secure.

It might be useful to define message headers that an MSA or border
outbound MTA should use to infer e2e encryption policy, for example
by sending mail only when a suitable encryption key is available
for a recipient.  Gateways could send signed, but unencrypted
contact requests to such users requesting a signed response (which
could be verified via SMIMEA).  Receiving user agents could respond
directly with a signed message, or insert similar headers to have
the recipient's gateway provide the requisite signature and public
key certs.

So mostly what's missing is new MUA code to support new key management
models.  Implementations may unearth the need for new headers or
other relevant standards that enable the new feature set, but my
guess is that for now what is missing is new code more than new
standards.  Perhaps this list will produce something unexpected
that will lead the way to new implementations, but my guess is 
that it will be other way around.

-- 
	Viktor.