Re: [keyassure] TLSA record does not mandate the given certificate
Jay Daley <jay@nzrs.net.nz> Tue, 29 March 2011 01:26 UTC
Return-Path: <jay@nzrs.net.nz>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9F828C143 for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 18:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNqBytHCxEYh for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 18:26:20 -0700 (PDT)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id A70AE28C142 for <keyassure@ietf.org>; Mon, 28 Mar 2011 18:26:20 -0700 (PDT)
Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id CA0082DAA91; Tue, 29 Mar 2011 14:28:01 +1300 (NZDT)
Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ria7SDW-zkMY; Tue, 29 Mar 2011 14:28:01 +1300 (NZDT)
Received: from [192.168.22.200] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 981842DA68E; Tue, 29 Mar 2011 14:28:01 +1300 (NZDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Jay Daley <jay@nzrs.net.nz>
In-Reply-To: <AANLkTinb0UBewLn-Dk2GPS6+8t9Y8DSO889TGWLeXNXZ@mail.gmail.com>
Date: Tue, 29 Mar 2011 14:27:57 +1300
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD2940CC-DF2A-4D1B-BC99-7D6CE9411B4E@nzrs.net.nz>
References: <AANLkTikregQCBOovJz4yrcyet+60yT0EMxRkXFw0wqVi@mail.gmail.com> <4672.1301340852@marajade.sandelman.ca> <AANLkTinX7KDrHTzp996yNodFqkPhNdhyM5umA7yKH+iG@mail.gmail.com> <AA2DCA69-7C46-40DD-A444-65009480CD3C@nzrs.net.nz> <AANLkTinb0UBewLn-Dk2GPS6+8t9Y8DSO889TGWLeXNXZ@mail.gmail.com>
To: Zack Weinberg <zack.weinberg@sv.cmu.edu>
X-Mailer: Apple Mail (2.1084)
Cc: keyassure@ietf.org
Subject: Re: [keyassure] TLSA record does not mandate the given certificate
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Mar 2011 01:26:21 -0000
On 29/03/2011, at 2:02 PM, Zack Weinberg wrote: > On Mon, Mar 28, 2011 at 5:39 PM, Jay Daley <jay@nzrs.net.nz> wrote: >> >> Two questions: >> >> 1. How is the current text in 3. not good enough? >> >> "If a match between one of the certificate association(s) and the >> server's end entity certificate in TLS is found, the TLS client >> continues the TLS handshake. If no match between the usable >> certificate association(s) and the server's end entity certificate in >> TLS is found, the TLS client MUST abort the handshake with an >> "access_denied" error." > > Only in being more confusing than I would like. I think it's vital to > be crystal clear how a client should behave in all cases. Sorry to be a pain, but I struggle to see how this is confusing. Can you explain? > By highlighting this text you reassure me that my changes to emphasize > the exclusivity properties of TLSA really are editorial, though, so > that's a relief. Good. >> 2. Assuming there is a problem with that text and your replacement text is needed, then shouldn't this be more explicit about multiple TLSA records? (And also use correct terminology) >> >> "A DANE client must determine whether the certificate bundle provided in the TLS handshake from a server found at a domain name matches a trusted TLSA record for that domain name. If it does not ..." > > I changed the terminology (see text above this), I'm not sure what you are referring to. Did I miss some text? Jay > again, to reduce > confusion. An entire certificate bundle does not match anything > anymore, it can only be associated. Only single certificates match. > > You're right, though, I forgot to consider the case of multiple TLSA > records. I'll need to tweak wording throughout to fix that, I think. > > zw -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
- [keyassure] PROPOSAL: Revision of DANE client req… Zack Weinberg
- [keyassure] TLSA record does not mandate the give… Michael Richardson
- Re: [keyassure] TLSA record does not mandate the … Zack Weinberg
- Re: [keyassure] TLSA record does not mandate the … Jay Daley
- Re: [keyassure] TLSA record does not mandate the … Zack Weinberg
- Re: [keyassure] TLSA record does not mandate the … Jay Daley
- Re: [keyassure] TLSA record does not mandate the … Paul Wouters
- Re: [keyassure] TLSA record does not mandate the … Richard L. Barnes
- Re: [keyassure] PROPOSAL: Revision of DANE client… Paul Wouters
- Re: [keyassure] TLSA record does not mandate the … Zack Weinberg
- Re: [keyassure] PROPOSAL: Revision of DANE client… Zack Weinberg
- Re: [keyassure] TLSA record does not mandate the … Zack Weinberg
- Re: [keyassure] PROPOSAL: Revision of DANE client… Paul Wouters