Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06)

Jay Daley <jay@nzrs.net.nz> Wed, 30 March 2011 19:44 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 AC5D33A6BBE for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 12:44:01 -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 X13r96SqRLR2 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 12:44:00 -0700 (PDT)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id F34AC3A6A7F for <keyassure@ietf.org>; Wed, 30 Mar 2011 12:43:59 -0700 (PDT)
Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id ADCE52CE004; Thu, 31 Mar 2011 08:45:41 +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 Ok9tcMdjgn7A; Thu, 31 Mar 2011 08:45:41 +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 62FB12DB66F; Thu, 31 Mar 2011 08:45:41 +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: <F0969248-124A-4A32-9F8F-EA81B17FDE05@bbn.com>
Date: Thu, 31 Mar 2011 08:45:36 +1300
Content-Transfer-Encoding: quoted-printable
Message-Id: <20EEA73E-9E5E-4D8F-B70C-BD6DF37F60E6@nzrs.net.nz>
References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> <AFFDB7BB-8749-4638-AB2D-9ACB617204AC@kirei.se> <20110321130430.GG9247@anguilla.noreply.org> <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org> <20110330091416.GI681@anguilla.noreply.org> <p06240803c9b8c1a35d7c@[130.129.71.125]> <F0969248-124A-4A32-9F8F-EA81B17FDE05@bbn.com>
To: Richard L. Barnes <rbarnes@bbn.com>
X-Mailer: Apple Mail (2.1084)
Cc: Peter Palfrader <peter@palfrader.org>, keyassure@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06)
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: Wed, 30 Mar 2011 19:44:01 -0000

I would argue the complete opposite - that it is in scope for DANE to state that names in certificates should not be checked because the trust chain has been provided by DNSSEC.  Doing that allows individuals and organisations to reuse certificates as they need to for operational reasons and not as dictated to by suppliers or paranoid protocol developers.

Jay

On 31/03/2011, at 12:55 AM, Richard L. Barnes wrote:

> This is outside of DANE's scope.  Checking of names in certificates is up to the application that uses TLS.
> --Richard
> 
> 
> On Mar 30, 2011, at 1:19 PM, Stephen Kent wrote:
> 
>> At 11:14 AM +0200 3/30/11, Peter Palfrader wrote:
>>> On Mon, 21 Mar 2011, Paul Hoffman wrote:
>>> 
>>>> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote:
>>>>> Why is it needed in the first place?
>>>> 
>>>> That's a very good question. I don't feel that it is a "need", but it
>>>> "makes some sense". That is, if I want to go to www.example.com, and I
>>>> get an A record for www.example.com, and I get a TLSA record for
>>>> _http._tcp.www.example.com, and I get a certificate that says "this
>>>> key is associated with www.somethingelse.com"quot;, what does it mean?
>>>> 
>>>> I can see both ways: "it doesn't matter what the cert says, we are
>>>> trusting the binding from the DNS" vs. "the cert needs to mean
>>>> something"? Jakob and I have that text in because a number of people
>>>> on the list were in the latter category, but it seems like a
>>>> reasonable question to ask separately.
>>> 
>>> I wonder if one approach here would be to require a match if, and only
>>> if, any naming attributes (CN, SubjectAltName) are in the certificate.
>>> 
>>> If there are no CN and no SAN attributes in the certificate then that
>>> would be acceptable too.
>>> 
>>> Cheers,
>>> Peter
>> 
>> A CN is a type of attribute in the Subject DN.  A SAN admits a variety of name types, some of which can have attributes. Do you mean to focus on DNS names as SANs or did you have a broader range of SANs in mind?
>> 
>> Steve
>> _______________________________________________
>> keyassure mailing list
>> keyassure@ietf.org
>> https://www.ietf.org/mailman/listinfo/keyassure
> 
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure


-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840