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

Paul Hoffman <> Mon, 21 March 2011 15:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 642A328C0EB for <>; Mon, 21 Mar 2011 08:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.02
X-Spam-Status: No, score=-102.02 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AcMrIlvWGqHU for <>; Mon, 21 Mar 2011 08:58:19 -0700 (PDT)
Received: from (unknown [IPv6:2001:4870:a30c:41::81]) by (Postfix) with ESMTP id 344C428C0E2 for <>; Mon, 21 Mar 2011 08:58:19 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.3) with ESMTP id p2LFxm20097100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Mar 2011 08:59:50 -0700 (MST) (envelope-from
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <>
In-Reply-To: <>
Date: Mon, 21 Mar 2011 08:59:48 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Peter Palfrader <>
X-Mailer: Apple Mail (2.1082)
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06)
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: Mon, 21 Mar 2011 15:58:20 -0000

On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote:

> 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?

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, and I get an A record for, and I get a TLSA record for, and I get a certificate that says "this key is associated with"quot;, 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.

--Paul Hoffman