On Sun, Nov 16, 2014 at 11:49 PM, Viktor Dukhovni <[email protected]> wrote: > On Mon, Nov 17, 2014 at 02:34:06AM -0500, Paul Wouters wrote: > >> >Users likely also need to store old private keys forever so that >> >old mail can still be read. The complete architecture for encrypted >> >email has many parts we're not making explicit, but all have a >> >bearing on key management requirements for MUAs. >> >> I'd call that out of scope. I think of OPENPGKEY as a transport plus >> data in rest protection while in-transit. Once the final enduser gets >> the email, I expect their email client to decrypt it and store it >> locally, so it remains searchable, indexable, etc. I also expect them >> to use full disk encryption to protect all their email. This method >> does not require keeping old private keys. > > It is out of scope for the DANE SMIMEA and OPENPGP documents, but > it is not out of scope for an architecture or requirements document. > The pieces have to fit together.
Provide mechanism not policy. How MUAs decide to handle old messages and keys isn't really relevant, nor should we force changes from existing practice: people already have keys they will want to use with whatever system for discovering keys we make. Do architecture and requirements documents actually work? Or do they end up overcomplicating solutions, as designers attempt to address things that maybe should be punted on, as they cost too much to implement? They certainly don't help with analysis: the requirements documents may be wrong themselves! > > Decrypted local storage is a fine model. We need more MUAs that > support that mode of operation. We also need to consider the > implications for sign-then-encrypt vs. encrypt-then-sign, and how > signature validation status is retained. Yes, of course not in > the DANE-specific documents, but these should be part of a more > complete architecture (IIRC something along those lines is an argument > that PHB is making). The correct construction is sign-then-encrypt. However, it could be that authenticated encryption is a better idea, but S/MIME and PGP do not support this. One weakness of DNS vs. HTTPS is that HTTPS works in javascript for browser extensions, while DNS data access may be an issue. I understand Google wants to put PGP in the browser: the easiest way to access keys would then be via HTTPS at a well-known URL. However, a DANE-to-Web bridge shouldn't be that much of a pain if needed. This minor, probably wrong, technical point, underscores a broader deployability issue. Success of e2e email depends on everyone in the world doing something. I'd be more confident in our getting this right if people who understood the limitations and possibilities of webmail better would participate in the discussion, or if we had running code for whatever solution was being proposed. Sincerely, Watson Ladd > > -- > Viktor. > > _______________________________________________ > Endymail mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/endymail -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
