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

Peter Palfrader <peter@palfrader.org> Wed, 30 March 2011 09:12 UTC

Return-Path: <peter@palfrader.org>
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 186FC28C119 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 02:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 MUQzeDXa6T21 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 02:12:39 -0700 (PDT)
Received: from anguilla.debian.or.at (anguilla.debian.or.at [IPv6:2001:858:10f:6::2]) by core3.amsl.com (Postfix) with ESMTP id B552A28C11E for <keyassure@ietf.org>; Wed, 30 Mar 2011 02:12:38 -0700 (PDT)
Received: by anguilla.debian.or.at (Postfix, from userid 1002) id 51AF210EBAF; Wed, 30 Mar 2011 11:14:16 +0200 (CEST)
Date: Wed, 30 Mar 2011 11:14:16 +0200
From: Peter Palfrader <peter@palfrader.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Disposition: inline
In-Reply-To: <4BC9E139-CBC5-46EE-A18F-E8F16AE108D6@vpnc.org>
X-PGP: 1024D/94C09C7F 5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F
X-Request-PGP: http://www.palfrader.org/keys/94C09C7F.asc
X-Accept-Language: de, en
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: keyassure@ietf.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 09:12:40 -0000

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
-- 
                           |  .''`.       ** Debian **
      Peter Palfrader      | : :' :      The  universal
 http://www.palfrader.org/ | `. `'      Operating System
                           |   `-    http://www.debian.org/