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

Peter Palfrader <peter@palfrader.org> Mon, 21 March 2011 13:03 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 214F43A684A for <keyassure@core3.amsl.com>; Mon, 21 Mar 2011 06:03:00 -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 N87hgok1g7wd for <keyassure@core3.amsl.com>; Mon, 21 Mar 2011 06:02:59 -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 D96F93A6846 for <keyassure@ietf.org>; Mon, 21 Mar 2011 06:02:58 -0700 (PDT)
Received: by anguilla.debian.or.at (Postfix, from userid 1002) id 216E610EBAE; Mon, 21 Mar 2011 14:04:30 +0100 (CET)
Date: Mon, 21 Mar 2011 14:04:30 +0100
From: Peter Palfrader <peter@palfrader.org>
To: keyassure@ietf.org
Message-ID: <20110321130430.GG9247@anguilla.noreply.org>
References: <4D7BFB41.4000403@vpnc.org> <20110321092514.GE9247@anguilla.noreply.org> <AFFDB7BB-8749-4638-AB2D-9ACB617204AC@kirei.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <AFFDB7BB-8749-4638-AB2D-9ACB617204AC@kirei.se>
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: 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: Mon, 21 Mar 2011 13:03:00 -0000

On Mon, 21 Mar 2011, Jakob Schlyter wrote:

> On 21 mar 2011, at 10.25, Peter Palfrader wrote:
> 
> > Updating the certificate and its corresponding binding in DNS is not
> > dissimilar to updating DNSKEY and DS records: care must be taken to get
> > the timing right, so that's a potential source of error.
> 
> Update TLSA resource records is very different from update DNSKEY et
> al. - as long as you take the TTL into consideration, you can update
> as you wish.

Create a new cert, create its hash, send to the DNS guys for inclusion.
Wait TTL.
Deploy new cert.
Mail the DNS people that they can now remove the old hash.

That's not really something you want to have to do all that often.

> > But even if we do require SNI for TLSA to be useful with virtual
> > hosting, that still means a virtual hosting provider has to create a
> > certificate for each of the domains they want to serve[2].
> 
> Yes, why would that be a problem?

Why is it needed in the first place?

-- 
                           |  .''`.       ** Debian **
      Peter Palfrader      | : :' :      The  universal
 http://www.palfrader.org/ | `. `'      Operating System
                           |   `-    http://www.debian.org/