Re: [keyassure] The draft and subj alt names

Paul Wouters <> Fri, 01 April 2011 07:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F8523A691A for <>; Fri, 1 Apr 2011 00:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.593
X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yyUityYQZFmA for <>; Fri, 1 Apr 2011 00:21:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9D2AB3A69B5 for <>; Fri, 1 Apr 2011 00:21:00 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 1B65CC5A0; Fri, 1 Apr 2011 03:22:40 -0400 (EDT)
Date: Fri, 1 Apr 2011 03:22:39 -0400 (EDT)
From: Paul Wouters <>
To: Jay Daley <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Subject: Re: [keyassure] The draft and subj alt names
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Apr 2011 07:21:20 -0000

On Fri, 1 Apr 2011, Jay Daley wrote:

>> As I've said in other threads, this WG should be silent on requirements for certificate names, since different applications use TLS certificate names in different ways.  See for example the difference between RFC 2818 and RFC 6125.  The text you reference in the draft is technically harmless ("must" not "MUST"), but should probably be deleted anyway.
> There are two separate issues here:
> a) whether we think name matching is still needed with DANE
> b) what the draft should say about that
> On a) I would make the case that name matching is should not be done because
> - DNSSEC provides sufficient trust
> - name matching forces certain operational decisions onto end user (e.g. multiple certs, cert reuse) that are unreasonable

Also, image you have to keep updating your cert in DANE every time you add/remove a
vhost and you have to update the subjectAltname. One of the advantages of putting it
in DNS is that you know the name of the entity without having to look inside the cert.

The cert is just a legacy container for the public key. We should not be adding policy
in DANE that entangles DANE with PKIX (or any other trust scheme)