On Thu, 2 Apr 2015, Viktor Dukhovni wrote:
Just a question for ._encr and ._sign:
Do you really plan to store private keys in public DNS? Is it, what ._sign will
be used for? Isn?t this really a security issue?
No they are public keys in both cases. Some public keys are for
signing only, others are for encryption (which means that they can
receive encrypted content).
The idea that these need separate locations in DNS has not seen
much support on this list. In consumer deployments, I don't see
such separation as likely to take place.
In enterprise deployments, I expect implementations will publish
gateway keys that decrypt the email, apply various content policies,
and then sometimes deliver re-encrypted content to the end-user,
but using keys that the outside world does not see.
Also, the smime key attributes will tell if if they are usable for
signing and/or encrypting. So my preference is to not have another
place to indicate this so we avoid needing to deal with mismatches.
To be honest, I don't expect encrypted messages in the mailbox to
ever be very popular, encrypted storage is just too inconvenient
for most users.
Having run openpgpkey-milter and gotten all of my email encrypted
due to my own forwarder, I strongly agree with that it is completely
inconvenient right now. But it is a problem that we need to solve to
make it convenient. I'm hoping that encrypting more email will mean
more people will work on better MUA integration of it. We really
need to fix this problem.
End-to-end is good for live conversations, but
not so well suited to archived communication.
I personally would like my MUA to store email decrypted, replace the
encrypted email headers inside the body back into real email headers
and rely on full disk encryption. That way, I get the best of both
worlds.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
