On Apr 2, 2015, at 1:24 PM, Paul Wouters <[email protected]> wrote: > 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.
I think this was better described by Doug M before, and you and I spoke about this at the interim meeting, but to rehash: my certs may be used for any number of actions (like the USG PIV cards), but I may not want them to be used arbitrarily for different services (like all manner of email). I may also have a cert that I want to no longer use for email, but I do _not_ want to revoke it. I may want to use a cert (whose attributes are very permissive) for just email signing. I can codify my wishes by not listing it as an encryption key in DNS. > >> 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. I’m aware of a lot of enterprise interest in encrypted email at rest. >> 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. I actually favor the encrypted email for the afore mentioned reasons. At the very least, it seems fair to consider giving the user the option. Eric _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
