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

Guido Witmond <> Tue, 10 December 2013 23:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B2FC01ADEA0 for <>; Tue, 10 Dec 2013 15:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.194
X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iYiI-pPM5BYB for <>; Tue, 10 Dec 2013 15:45:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 62EA31ADEAE for <>; Tue, 10 Dec 2013 15:45:27 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTP id 46DAFC55EB for <>; Tue, 10 Dec 2013 23:45:19 +0000 (UTC)
Message-ID: <>
Date: Wed, 11 Dec 2013 00:45:13 +0100
From: Guido Witmond <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="----enig2WSHLALTIHDCKNKNURGUO"
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 23:45:30 -0000

On 12/10/13 23:58, Viktor Dukhovni wrote:
> 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.

Which could be changed by a malicious Register. Ie. That's what needs to
be verified by both the domain owner and the end user.

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

I'm arguing to propose names that the matches the End Users'
expectation. That might lead to some smart domain owners to consider how
their TLSA-records are received. Can't protect against Stupid, regrettably.

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

My misunderstanding. I believed it would specify my chosen CA for my
domain, I understand it could be more specific than that: A certain
subCA from that CA. Would it mean that that specific CA has *less*
options to get coerced to issue a fake certificate for my domain?

>> 1: End certificate in a chain from a Global trusted CA;
> Sure.  But I don't see an acronym 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.

I left acronyms to those better able to decide. I just wanted to point
out my ideas. Especially the idea to frame the acronyms in the mind-set
of the end-user. Because I believe, that's the person we need to protect.

Regards, Guido.