Re: [dane] DANE-EE(3) certificate matching rules?

James Cloos <> Sun, 16 March 2014 22:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CFEEA1A01E8 for <>; Sun, 16 Mar 2014 15:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LmMkkh2ZnHuN for <>; Sun, 16 Mar 2014 15:47:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BB47D1A030D for <>; Sun, 16 Mar 2014 15:47:33 -0700 (PDT)
Received: by (Postfix, from userid 10) id 050FA1EBF2; Sun, 16 Mar 2014 22:47:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ore13; t=1395010043; bh=p9srwYvNElgxoLVxA9BkDommwtYQ1tlHChfYGBBiPoY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mQsiaFtulIIlWCcmk5sQqkFLrIeIgm20UfKKYIdk238wapbVBguigwv1aK3GvwO+3 ugvhAlLF9CrSBymZFitSqhw2NdGh6cdNTRoad/jOVQU4ucZ2DmAn8QrdD5NQnHRc2T c4KVXMzJttu6HIugTN59A72U9ScQxlQkmBiSN0oWFSw==
Received: by (Postfix, from userid 500) id 7B94660021; Sun, 16 Mar 2014 22:45:20 +0000 (UTC)
From: James Cloos <>
In-Reply-To: <> (Viktor Dukhovni's message of "Sun, 16 Mar 2014 20:54:28 +0000")
References: <>
User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux)
Copyright: Copyright 2014 James Cloos
OpenPGP: ED7DAEA6; url=
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
Date: Sun, 16 Mar 2014 18:45:20 -0400
Message-ID: <>
Lines: 22
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [dane] DANE-EE(3) certificate matching rules?
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, 16 Mar 2014 22:47:36 -0000

>>>>> "VD" == Viktor Dukhovni <> writes:

VD> Therefore, the final proposal for DANE-EE(3) is that only name
VD> checks and expiration checks are out of scope.  This applies whether
VD> the selector is Cert(0) or SPKI(1).  However, when *all* TLSA records
VD> are "IN TLSA DANE-EE(3) SPKI(1) ?", implementations that support the
VD> proposed bare public key TLS extension, may signal that extension,
VD> in which case if the server cooperates, in effect the rest of the
VD> certificate is ignored (in fact never transmitted).

VD> Any comments? Can the above be the final consensus on this topic?

That seems reasonable.

Some software stacks may make that difficult easily to accomplish.
At least in the short term.  But such libraries can be fixed.

So, +1.

James Cloos <>         OpenPGP: 1024D/ED7DAEA6