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

Peter Palfrader <peter@palfrader.org> Mon, 21 March 2011 09:23 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 6CEF93A6806 for <keyassure@core3.amsl.com>; Mon, 21 Mar 2011 02:23:49 -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 fYiYhs7LZ2CR for <keyassure@core3.amsl.com>; Mon, 21 Mar 2011 02:23:45 -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 4B5593A67A8 for <keyassure@ietf.org>; Mon, 21 Mar 2011 02:23:45 -0700 (PDT)
Received: by anguilla.debian.or.at (Postfix, from userid 1002) id 36CCD10EBC7; Mon, 21 Mar 2011 10:25:14 +0100 (CET)
Date: Mon, 21 Mar 2011 10:25:14 +0100
From: Peter Palfrader <peter@palfrader.org>
To: keyassure@ietf.org
Message-ID: <20110321092514.GE9247@anguilla.noreply.org>
References: <4D7BFB41.4000403@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <4D7BFB41.4000403@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: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: [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 09:23:50 -0000

On Sat, 12 Mar 2011, Paul Hoffman wrote:

> Comments are, of course, welcome.

Verison 06 of the draft, in section 2.3, introduces this new paragraph:

|  The end entity certificate from TLS, regardless of whether it was
|  matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA
|  certificate, must have at least one identifier in the subject or
|  subjectAltName field of the matched certificates matches the expected
|  identifier for the TLS server.
[..]

This requirement has been discussed in passing earlier already (e.g in
the thread around [1]), but I think never exhaustively.  If it has and I
just missed it please accept my apologies (and I'd appreciate a pointer
to the right thread).


Do we assume that every client that will ever support TLSA will also
support SNI?  If not, then this would require that every time a virtual
host is added to, or removed from a webserver the certificate be
re-generated to update the list of SANs and the corresponding TLSA
information be updated.

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.

Another drawback is that a having all the domains listed as
subjectAltNames in a certificate leaks that list of domains hosted on a
given server.


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].


This requirement seems to place some additional burden on the entity
implementing TLSA, but it does not provide any benefit that is obvious
to me.  So I wonder what the rationale for needing a matching CN or SAN
in the certificate is.


Thanks,
Peter

1. http://www.ietf.org/mail-archive/web/keyassure/current/msg01582.html
2. I am not familiar with hardware accelerators for RSA, but I assume
   there are certain limits on the number of keys such a thing can hold
   and some overhead for switching keys, so in the end a hoster might be
   tempted to create all the certificates from the same key material,
   maybe.
-- 
                           |  .''`.       ** Debian **
      Peter Palfrader      | : :' :      The  universal
 http://www.palfrader.org/ | `. `'      Operating System
                           |   `-    http://www.debian.org/