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

[Doug Montgomery <[e-mail]>]

On Wed, Nov 26, 2014 at 12:38 PM, Warren Kumari <[e-mail]> wrote:

> On Tue, Nov 25, 2014 at 9:29 AM, Olafur Gudmundsson <[e-mail]> wrote:
> >
> > Dear colleagues
> > Just a reminder that the virtual meeting is happening next week on
> Tuesday.
> > Please send in usage statements ASAP, as that will help frame the
> discussion
>
> Also, please read
> https://datatracker.ietf.org/doc/draft-osterweil-dane-ent-email-reqs/
> and
> https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-01 before
> the meeting[0].
>
> 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?"
>

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.

But, your MUA, or MTA if privy to your trust anchors, should mark if the
message signatures were valid at time of first delivery.   Optionally if
the app wants to show if the signature is still valid, it could, but this
is less important.

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



or
> "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?"
>

Not sure if your question is about the timing (1 day) or the capability at
all.

But in general if Acme can't revoke invalid or compromised credentials...
then the system is next to useless.   I know of very large IDM systems and
supporting policies/laws that require credential revocation within 24 hours
or less of employee termination.

Ideally Acme would be able to publish (somewhere) a policy that says all
Acme.com email is signed ... and would be able to insure there is no valid
binding between Bob and a email signing key for the domain.

Those two bits of information would be enough to enable receivers that care
to check / enforce the ability to determine that Bob's disgruntled email
does not come from a valid acme.com network identity.

In a somewhat related point on historical keying material, I think MUAs
should mark that encrypted messages were encrypted at time of first
delivery and not store the message in its original encrypted form.    The
problem of historical key escrow so that I can go back and recover my old
keys and read emails sent to me years ago seems bizarre, yet I know large
IDM systems that do this.   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.

dougm