Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ]

Viktor Dukhovni <> Fri, 06 December 2013 20:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 671161AE01A for <>; Fri, 6 Dec 2013 12:51: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 6FdbGDhR0kzL for <>; Fri, 6 Dec 2013 12:51:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 501C71AD957 for <>; Fri, 6 Dec 2013 12:51:45 -0800 (PST)
Received: by (Postfix, from userid 1034) id D0E352AABD1; Fri, 6 Dec 2013 20:51:40 +0000 (UTC)
Date: Fri, 06 Dec 2013 20:51:40 +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] On the PKIX-TA / PKIX-CA question? [ One week WGLC ]
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: Fri, 06 Dec 2013 20:51:47 -0000

On Fri, Dec 06, 2013 at 03:00:17PM -0500, Warren Kumari wrote:

> > The sample size of responses seems too small to reach a meaningful
> > consensus.
> Unfortunately both too small, and not all in agreement.
> I'm going to extend this LC to Wednesday and suggest that, if we
> don't get consensus on this we simply stick with what is in the
> current (draft-ietf-dane-registry-acronyms-02) document.

I think the main audience for the short names is server administrators
too busy to read RFCs.  Until I joined this group, I'd never seen
the terms "EE" and "TA" and had only a vague notion of what "PKIX"
was about.  Rather, I had a decent working knowledge of root,
intermediate and leaf certificates and public keys.

So if I rewind the clock back 8 months, to where I knew nothing
about DANE and was not steeped in related IETF TLS slang, I would
note that none of the components of the proposed acronyms will
connect to concepts familar to system administrators deploying

To make the acronyms less confusing than the numbers, we need to
use words people already understand:


These are I think not only more clear, but use more familiar terms.
The first two limit (or constrain) the chain to have an acceptable
issuer or leaf certificate.  The last two specify a trusted CA or
a fixed leaf certificate that are sufficient to verify the chain.

> We don't need these names / acronyms to be perfect, simply clearer
> / easier to remember than the ordinals.
> Any (strong) objections?

Returning to the origin acronyms, I for one still prefer PKIX-CA
to PKIX-TA, but I won't change my code to do the wrong thing should
the final name be misleading.  I can't make a similar assurance
about server administrators provisioning TLSA recrods.