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

Viktor Dukhovni <viktor1dane@dukhovni.org> Wed, 11 December 2013 00:31 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D11B1ADF86 for <dane@ietfa.amsl.com>; Tue, 10 Dec 2013 16:31:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn2PmMhl36T2 for <dane@ietfa.amsl.com>; Tue, 10 Dec 2013 16:31:47 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAD21AD94A for <dane@ietf.org>; Tue, 10 Dec 2013 16:31:46 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F10E12AB16E; Wed, 11 Dec 2013 00:31:40 +0000 (UTC)
Date: Wed, 11 Dec 2013 00:31:40 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20131211003140.GM761@mournblade.imrryr.org>
References: <77C3BA84-1EC4-4536-B66D-D9C36CCF7C1A@kumari.net> <20131210194214.GH761@mournblade.imrryr.org> <CAL02cgRy5xUwUf5R0O+2JroQ5Q2f5fdXLVN8b51up08LJUTGGA@mail.gmail.com> <52A79155.1040100@witmond.nl> <20131210225838.GK761@mournblade.imrryr.org> <52A7A789.401@witmond.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52A7A789.401@witmond.nl>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Calling the naming issue...
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 00:31:49 -0000

On Wed, Dec 11, 2013 at 12:45:13AM +0100, Guido Witmond wrote:

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

[ EXACTLY.  This is the misunderstanding I want to discourage by NOT
naming "0" DANE-TA, but that is exactly what is is NOT.  My objection
to DANE-TA is looking stronger.  Please REVERT it to DANE-CA, and
the draft can then move forward without reinforcing confusion. ]

Yes, one can exclude various reseller subordinate CAs, or other
intermediates issued by some trusted CA, and thus protect verifiers
of your domain for being fooled by certificates issued by unrelated
rogue intermediates.  Provider your intermediate CA is not rogue,
you're safe(r).

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

I agree.  Thus my earlier posts suggesting we use name components
more familar to every-day users.  This excludes "PKIX" (almost
nobody knows what that means), "TA" and "EE".  The only proposed
name component that might mean something to people is "DANE" but
that applies to *all* the usages, they are all "DANE".  So the
proposed names are somewhat memorable, but meaningless.

The following would be much better:

	- LIMIT-ISSUING-AUTHORITY
	- LIMIT-LEAF-ENTITY
	- ASSERT-TRUSTED-ISSUER
	- ASSERT-LEAF-ENTITY

but unless the author decides to propose a revision, perhaps we're
stuck with the broken names and any confusion they may entrench.
I encourage the author to boldly change the names if he has seen
any merit in my arguments.  It is of course possible that I'm not
convincing anyone at all.  That's fine, I have actual code to write
and test.

-- 
	Viktor.