Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06)
Stephen Kent <kent@bbn.com> Wed, 30 March 2011 11:40 UTC
Return-Path: <kent@bbn.com>
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 AB03F28C174 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 04:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Level:
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Y0Oq7+VaRc1h for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 04:40:07 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 3CAE628C114 for <keyassure@ietf.org>; Wed, 30 Mar 2011 04:40:07 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:58034 helo=[130.129.71.125]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Q4tmS-000A36-Sd; Wed, 30 Mar 2011 07:41:45 -0400
Mime-Version: 1.0
Message-Id: <p06240803c9b8c1a35d7c@[130.129.71.125]>
In-Reply-To: <20110330091416.GI681@anguilla.noreply.org>
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>
Date: Wed, 30 Mar 2011 07:19:39 -0400
To: Peter Palfrader <peter@palfrader.org>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: 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 11:40:09 -0000
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", 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] End entity certificate matching, trus… Paul Hoffman
- Re: [keyassure] End entity certificate matching, … Peter Gutmann
- Re: [keyassure] End entity certificate matching, … Peter Gutmann
- Re: [keyassure] CN/SAN matching (was: End entity … Paul Hoffman
- [keyassure] CN/SAN matching (was: End entity cert… Peter Palfrader
- Re: [keyassure] CN/SAN matching (was: End entity … Jakob Schlyter
- Re: [keyassure] CN/SAN matching (was: End entity … Peter Palfrader
- Re: [keyassure] CN/SAN matching (was: End entity … Paul Wouters
- Re: [keyassure] CN/SAN matching (was: End entity … Peter Palfrader
- Re: [keyassure] CN/SAN matching (was: End entity … Stephen Kent
- Re: [keyassure] CN/SAN matching (was: End entity … Richard L. Barnes
- Re: [keyassure] CN/SAN matching (was: End entity … Jay Daley
- Re: [keyassure] CN/SAN matching (was: End entity … Richard L. Barnes
- Re: [keyassure] CN/SAN matching (was: End entity … Jay Daley
- Re: [keyassure] CN/SAN matching (was: End entity … Eric Rescorla
- Re: [keyassure] CN/SAN matching (was: End entity … Richard L. Barnes
- Re: [keyassure] CN/SAN matching (was: End entity … Martin Rex