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

Viktor Dukhovni <viktor1dane@dukhovni.org> Mon, 02 December 2013 23:19 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 4CEA41ADF46 for <dane@ietfa.amsl.com>; Mon, 2 Dec 2013 15:19:36 -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 R-AY-57GsmHZ for <dane@ietfa.amsl.com>; Mon, 2 Dec 2013 15:19:33 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id B57091ADBCD for <dane@ietf.org>; Mon, 2 Dec 2013 15:19:33 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 718892AB165; Mon, 2 Dec 2013 23:19:30 +0000 (UTC)
Date: Mon, 2 Dec 2013 23:19:30 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20131202231930.GP761@mournblade.imrryr.org>
References: <20131202221525.GO761@mournblade.imrryr.org> <CEC276E2.F1B6%bdickson@verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CEC276E2.F1B6%bdickson@verisign.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ]
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: Mon, 02 Dec 2013 23:19:36 -0000

On Mon, Dec 02, 2013 at 10:47:04PM +0000, Dickson, Brian wrote:

> IMHO the acronym should clarify things, or at least suggest which
> angle to hold 6698 while squinting.
> 
> How about these:
> 0 - CERT-CA
> 1 - CERT-EE
> 2 - ROOT-TA
> 3 - JUST-EE

What is the "CERT" prefix intended to suggest?

> 0 can be either a root CA, or intermediate CA. If the latter, this cert
> itself must PKIX-validate.

A simpler view of 0 is that one constructs a chain to a trusted
root as usual, but it is only valid if it also contains the DANE
specified CA (CA constraint).  Thus there is only one case not two.

PKIX validation of two separate half-chains, from the root down to
the intermediate CA, and from the intermediate CA down the leaf,
is *not* equivalent to PKIX validation of a complete chain.  It
can fail to enforce pathlength limits and name constraints.

> 2 can be either a root CA, or another trust anchor - but must be
> the root of the validation chain either way.

This conflicts with the usual meaning of "root" (meaning self-signed).
You're using "root" to mean top of validation chain which is what
the "TA" part means so "ROOT-TA" is redundant.

> Thus, a ROOT-CA cert, can be used as either type 0 or type 2 -
> but that is the only likely place where there is likely confusion.

Any CA (root or not) can be used with either 0 or 2.  Since root
already means something else (self-issued a.k.a. self-signed) we
should avoid using it here, since DANE does not treat root CAs
differently from other CAs.

> (Of course, if your EE is a root CA, it could be type 1 - but
> then you are clearly insane. :-))

PKIX chains don't include the trust anchor, and may not be empty,
so any TLS peer that presents a leaf self-signed certificate should
fail PKIX (and can only be validated by some other mechanism).

In usage 3, self-signed certificates will often be root CAs that
nobody trusts to sign any other certificates.  The "basicConstraints:
CA:true" bit is harmless noise in this context.  Some users will
carefully generate self-signed certs with "CA:false", but this
makes little to no difference.

-- 
	Viktor.