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.
- [dane] Calling the naming issue... Warren Kumari
- Re: [dane] Calling the naming issue... Viktor Dukhovni
- Re: [dane] Calling the naming issue... Richard Barnes
- Re: [dane] Calling the naming issue... Guido Witmond
- Re: [dane] Calling the naming issue... Viktor Dukhovni
- Re: [dane] Calling the naming issue... Guido Witmond
- Re: [dane] Calling the naming issue... Viktor Dukhovni