Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt

"Osterweil, Eric" <> Wed, 05 February 2014 21:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D079D1A020D for <>; Wed, 5 Feb 2014 13:30:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YvEAIk6fmyZJ for <>; Wed, 5 Feb 2014 13:30:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8F81F1A01D1 for <>; Wed, 5 Feb 2014 13:30:36 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Wed, 05 Feb 2014 13:30:36 PST
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id s15LUZp2016187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Wed, 5 Feb 2014 16:30:35 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 16:30:34 -0500
From: "Osterweil, Eric" <>
To: "<>" <>
Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt
Thread-Index: AQHPCyZe4iLhCQLcdU6kJvU3W3pU85p7QbWAgAAPoACALFgggIAABxEA
Date: Wed, 5 Feb 2014 21:30:34 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
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: Wed, 05 Feb 2014 21:30:40 -0000

On Feb 5, 2014, at 4:05 PM, Viktor Dukhovni <> wrote:

> On Wed, Jan 08, 2014 at 07:54:26AM -0800, Paul Hoffman wrote:
>>> 2. a new CU value for "revoked" to indicate that this user's
>>> certificates have been revoked.
>> We considered things like this for TLSA, and the WG seemed very
>> hesitant to have the DNS be used as a second, unofficial revocation
>> mechanism. For instance, what would it mean for the DNS to say that
>> an S/MIME cert is revoked, but when the user pulls a fresh CRL,
>> the cert isn't there? The best we might do is to have a signal for
>> "go refresh your revocation view" in the DNS, but that seems like
>> very marginal value.
> I strongly support Paul's comment.  Unlike stale on-disk certificates
> held by third-parties, published DANE records (SMIMEA, TLSA, ...)
> are maintained by the subject's domain and can be presumed *current*
> when the publishing domain is not negligent.
> Therefore, there is no need for a fragile blacklist mechanism.
> The DANE data in DNSSEC is a comprehensive whitelist.  Every
> certificate not listed in DANE is the wrong certificate, unlike
> CRLs DANE fails closed.

Hey Viktor,

So, I worry that this relies on implicit assumptions being made about processing being done on the MUA (RP) side.  If something is not available in DNS, does that mean I shouldn't use a cert I may already have in hand, I shouldn't fall back to AD, I shouldn't use a previously seen value, etc… How do I know the domain was ever serving SMIMEA if there is nothing in there now?  I suppose we could conflate deauthorization of certs with revocation of certs.  However, I was suggesting that we _could_ use this opportunity to express an unambiguous piece of evidence that clients should use SMIMEA-processing, and should _not_ use a specific cert (even though it may not be universally revoked).

> When the DANE associated data published for a user is a CA that
> signs multiple EE certs and a particular user's keys need to be
> revoked, the simplest solution is to publish an EE association for
> that user until the revoked certificate expires.  Either way there
> is a special EE DANE record for the user in question, but one or
> more valid EE certs are more useful than a list of invalid EE certs.

As I think you said above, ``DANE records (SMIMEA, TLSA, …) are maintained by the subject's domain and can be presumed *current* when the publishing domain is not negligent.'' I think it's a nice option to give DNS provisioning systems to set a flag in an RR that deauthorizes a cert w/o having to have the CA issue a new association.  Perhaps I'm off here, but it seems far more complicated from an operational perspective to have to hop through a CA and get something issued in order to deauthorize a cert rather than just updating the RR, no?