Re: [dane] Calling the naming issue...

Viktor Dukhovni <> Tue, 10 December 2013 22:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 43C101A1F1A for <>; Tue, 10 Dec 2013 14:58:47 -0800 (PST)
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 rqj92r9d92cB for <>; Tue, 10 Dec 2013 14:58:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4F6E71AE281 for <>; Tue, 10 Dec 2013 14:58:45 -0800 (PST)
Received: by (Postfix, from userid 1034) id 3A2202AB163; Tue, 10 Dec 2013 22:58:39 +0000 (UTC)
Date: Tue, 10 Dec 2013 22:58:39 +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.21 (2010-09-15)
Subject: Re: [dane] Calling the naming issue...
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: Tue, 10 Dec 2013 22:58:47 -0000

On Tue, Dec 10, 2013 at 11:10:29PM +0100, Guido Witmond wrote:

> DANE can only specify *intent*. Intent of the domain owner what they
> choose for their certificate source.

The intent of the holder of the current zone signing key.

> Without *verification* that intent is worthless.

The intent is conveniently verified by an RRSIG generated by the
zone signing public key.

Arguing against the DANE security model has no bearing on the acronyms.

> IMHO, the naming should reflect the source of the certificate:
> 0: Global trusted CA;

Except that the record value is not a global trusted CA.  Rather
its value is a CA constraint on the chain from some trusted CA
requiring the presence of some intermediate at or below such a CA.

The record should be named after what is specifies, which is a CA
required in your chain, not a trusted root.  This was my objection
to the change from PKIX-CA to PKIX-TA.  The change from PKIX-CA to
PKIX-TA is still wrong (even if I am willing to let it slide), as
it will perpetuate confusion by many people who don't understand
usage 0 or usage 2, but think they do.

> 1: End certificate in a chain from a Global trusted CA;

Sure.  But I don't see an ancronym here...

> 2: My own CA;  ( from the perspective of the domain owner)

Your own trust-anchor.

> 3: My own Certificate; (same perspective)

Still no actual acronym.