Re: [dane] draft-ietf-dane-smime

Viktor Dukhovni <> Thu, 02 October 2014 22:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1735D1ACEB8 for <>; Thu, 2 Oct 2014 15:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x-fE0ayV-huZ for <>; Thu, 2 Oct 2014 15:46:50 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 669041ACED9 for <>; Thu, 2 Oct 2014 15:46:50 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 6CF9A2AB2D6; Thu, 2 Oct 2014 22:46:48 +0000 (UTC)
Date: Thu, 02 Oct 2014 22:46:48 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [dane] draft-ietf-dane-smime
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: Thu, 02 Oct 2014 22:46:52 -0000

On Thu, Oct 02, 2014 at 05:05:14PM -0400, Doug Montgomery wrote:

> And how is that definitively distinguishable from that email identity never
> having a CERT in DANE in the first place?

It is not, but identities can have multiple associated certificates,
and in fact need to do so during key rotation.  The proposal seems
to suggest a revocation of the "identity" rather than a particular
key and this seems to be operating at the wrong granularity.

Ignoring everything but the CU with usage 4 eliminates the option
of revoking key "A" while publishing a replacement key "B".

Explicit revocation is not a good idea in DANE, the DNS publishes
a sufficiently current state of the world, not a stale assertion
with a one year TTL.  It is I think a mistake to ask where the
handbrake goes on a boat, when one happens to be more familiar with

In any case if CU=4 is to be a DANE revocation record, it should
have a meaningful selector, matching type and association data.
It shold be an explicit revocation of just the matching certificate
or public key (whether it be associated with a trust-anchor or an