Re: [dane] [Uta] DANE Testing
Viktor Dukhovni <viktor1dane@dukhovni.org> Sat, 22 February 2014 03:32 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 1DB841A0379 for <dane@ietfa.amsl.com>; Fri, 21 Feb 2014 19:32:41 -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 KWMFjsggqhB2 for <dane@ietfa.amsl.com>; Fri, 21 Feb 2014 19:32:38 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 755BC1A02BD for <dane@ietf.org>; Fri, 21 Feb 2014 19:32:38 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D76E62AB256; Sat, 22 Feb 2014 03:32:32 +0000 (UTC)
Date: Sat, 22 Feb 2014 03:32:32 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140222033232.GY278@mournblade.imrryr.org>
References: <5307B4BE.9010706@nist.gov> <20140221213052.GA4505@roeckx.be>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20140221213052.GA4505@roeckx.be>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/C_OF7XVgGzjI2fGeIUB87FmIVXs
Subject: Re: [dane] [Uta] DANE Testing
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: Sat, 22 Feb 2014 03:32:41 -0000
On Fri, Feb 21, 2014 at 10:30:52PM +0100, Kurt Roeckx wrote: > On Fri, Feb 21, 2014 at 03:19:10PM -0500, Stephen Nightingale wrote: > > > > - For 0xx and 1xx uses, it is hard to identify a single canonical CA > > list. I have overlapping, but different Root Cert sets from Mozilla, > > Fedora and Linux Mint. So when searching for an authority to build a > > verification chain I cycle through all of these until succeeding or > > exhaustion of the possibilities. Some of the DANE 360 listed sets > > (including some from members of this group) fail to authenticate > > because the root certs are not in my authorities. > > I'm not really sure why you can't find the relevant CAs in your > root store. It looks like you don't properly build the chain or > something? Looking for instance at the fedoraproject.org results, > you try all 3 of them, but each time fail, where for all 3 you > actually seem to list the root CA as a relevant cert? The handshake chain from fedoraproject.org is: subject=/serialNumber=GFaoFyCf99PHtAPDHLEBYfFi/1hePcED/C=US/ST=North Carolina/L=Raleigh/O=Red Hat Inc/OU=Fedora Infrastructure/CN=*.fedoraproject.org issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA subject=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA subject=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA issuer=/C=US/O=Equifax/OU=Equifax Secure Certificate Authority Per http://tools.ietf.org/html/rfc5246#page-48 certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. and of course fedoraproject.org does not include the root cert in the TLS handshake chain. The chain needs to be augmented with the relevant issuing root by the verifier. In this case the Equifax root CA. Which is in many of the popular CA bundles. The certificate that matches the TLSA record (CA constraint) is the immediate issuer, but is not the root issuer and does not appear in various CA bundles. Perhaps the code incorrectly assumes that the CA matched by a "0 0 1" TLSA record, needs to be the root CA. -- Viktor.
- [dane] DANE Testing Stephen Nightingale
- Re: [dane] DANE Testing Viktor Dukhovni
- Re: [dane] DANE Testing Stephen Nightingale
- Re: [dane] DANE Testing Viktor Dukhovni
- Re: [dane] [Uta] DANE Testing Kurt Roeckx
- Re: [dane] [Uta] DANE Testing Viktor Dukhovni