Re: [dane] DANE WG Interim Virtual Meeting, December 2, 2014

[Viktor Dukhovni <[e-mail]>]

On Sun, Nov 30, 2014 at 01:26:57PM -0500, Doug Montgomery wrote:

> > Also worth considering / discussing is the whole "Bob writes a mail on
> > March 1st and then leaves the Acme, Inc. on March 2nd. Alice finally
> > gets around to opening the mail on April 10th - should it validate?"

The correct answer is "no, it should not validate".  Business
processes can be applied to send Alice a new email signed by Bob's
successor if that's required.  Bob's signing key is no longer
published at the time that Alice reads the mail.

Alice has no way to know whether Bob's email was sent before or
after Bob left Acme.  Bob's S/MIME signature is not securely
timestamped, all Alice knows is that the message was signed in the
past.  Signed time-of-receipt by Alice's mail system would be needed
to do better, and no standard specifies these at present.

> 
> Not sure the notion of "to open" is well defined at a MUA.   Given the
> models of POP vs IMAP vs webmail vs ..... it is not even clear to me that
> "delivered to MUA" is well defined.

User agents that support encryption and signing need to be able to
distinguish "new" mail from "old".  Otherwise, they are too crippled
to usefully support end-to-end encryption.

> A good test is to substitute "10 years later" for "on April 10th" above and
> see if it changes your thinking.

Actually, 10 years later is different if the mail was originally read
in a timely manner, and is being re-read 10 years later.

> > "Bob gets fired on March 2nd and is understandably disgruntled. He has
> > his laptop at home and sends mail on March 3rd. Can Acme, Inc prevent
> > this / invalidate the keys?"

Just the same as the first case.  Depublish Bob's keys.

> Store your inbox on an encrypted file store if
> you wish, but the idea that I should maintain an infinite historical key
> store to read the email you encrypted to me 10 years ago seems the wrong
> model ... but yet I know large IDM systems that do this.

Secure local storage of decrypted email (with any signature
verification status at time it was first read) is a local requirement
for an MUA that adequately supports email encryption and signing.

Out of scope for DANE, but inescapable for MUA usability.

-- 
	Viktor.