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

Doug Montgomery <> Sun, 30 November 2014 18:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7F87C1A1A64 for <>; Sun, 30 Nov 2014 10:27:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v4sts0ty14Wv for <>; Sun, 30 Nov 2014 10:27:20 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 944FD1A1A60 for <>; Sun, 30 Nov 2014 10:27:19 -0800 (PST)
Received: by with SMTP id z12so7474391lbi.32 for <>; Sun, 30 Nov 2014 10:27:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=b0JWw/CzgBVCC+Z03RlikMDf8cP1secKTsxojEMcy34=; b=hFIYYOhxG8ZmOKrUaKNdRKU+FJ/lm1hTPySOX5osr/xVHX944S+VNKPtHfhVOjOOPE LvsRnY65T6bstxGPLv7j4dHz1YE3Pyyto24kiL+7jHjmaumqS6uhtVsuKSDHReyfF+L1 8cohzcBhcwam3D0U+2CCGrnG9KwoSJ8sbEWh3dWTrF2SmN5YOKTuoFynnv8yPqwl1pod 5AlAfl/FI3aB1xPWcWkrQ83wrT6mi6J2qmHg2QfDcqCCz+C2ZzMUTJukpqRTDxOPl+9c 4Xhe7YqY2rp8CIHYAqhVPZ3gtlP19OxJXTm0iVLtyUdsYih4AqUq8IF0Iz17sVwzsG1i Q0hA==
X-Received: by with SMTP id xk9mr10723051lbb.99.1417372037979; Sun, 30 Nov 2014 10:27:17 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 30 Nov 2014 10:26:57 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Doug Montgomery <>
Date: Sun, 30 Nov 2014 13:26:57 -0500
Message-ID: <>
To: Warren Kumari <>
Content-Type: multipart/alternative; boundary=001a11c38c70d6a484050917a47c
Cc: "<>" <>
Subject: Re: [dane] DANE WG Interim Virtual Meeting, December 2, 2014
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 30 Nov 2014 18:27:22 -0000

On Wed, Nov 26, 2014 at 12:38 PM, Warren Kumari <> wrote:

> On Tue, Nov 25, 2014 at 9:29 AM, Olafur Gudmundsson <> 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
> and
> 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.

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

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 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 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.