On Thu, Apr 2, 2015 at 2:40 PM, Paul Wouters <[email protected]> wrote: > On Thu, 2 Apr 2015, Osterweil, Eric wrote: > > 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. >> > > Well, this is SMIME and it uses PKIX, so the proper way to express any > kind of attributes is via EKU OIDs.
Part of the issue here is that we have large enterprise identity management systems that issue credentials for security functions, but independent of application. So while the EKU bits say that a CERT is useful for encryption, it does not say if that is for file encryption, disk encryption, or email encryption. Thus the EKU bits may not be enough to understand if the domain in question supports/allows encrypted email or not. DANE/SMIMEA offers the potential to clearly express / control key usage per service and at the domain level. Both of which are not controllable, and/or, are out of scope of the business processes and regulations that control the creation of the actual certificates. Enterprise identity management systems, business process, and the laws and policies that govern them are the long pole in the tent here. At least on the enterprise side, we are not talking about an individual getting a $5 CERT or running ssh-keygen. > > >>> 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. >> > > The MUA can implement either. But I can tell you that it is next to > impossible to search through old encrypted emails. I often search > through old email, so I have a clear preference for storing it in > decrypted form accessable to my MUA, all of it protected by whole > disk encryption. But that's all a MUA based local/user policy > decision and we don't have to indicate any of this in DNS. +1 Having seen the awkward and complex machinery that exists to allow users to recover their decade old encryption keys so as to read an old email in their inbox, I personally think the idea of storing encrypted email encrypted by the original key both useless and misguided / misleading. After delivery to the end user it offers no security service to the original sender as I could have done anything with the decrypted message. The only sane way to do this is to store in local encrypted file store that presumably is actively managed in terms of keying material. > > Paul dougm -- DougM at Work
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
