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

Stephen Kent <> Wed, 30 March 2011 11:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB03F28C174 for <>; Wed, 30 Mar 2011 04:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y0Oq7+VaRc1h for <>; Wed, 30 Mar 2011 04:40:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3CAE628C114 for <>; Wed, 30 Mar 2011 04:40:07 -0700 (PDT)
Received: from ([]:58034 helo=[]) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1Q4tmS-000A36-Sd; Wed, 30 Mar 2011 07:41:45 -0400
Mime-Version: 1.0
Message-Id: <p06240803c9b8c1a35d7c@[]>
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Wed, 30 Mar 2011 07:19:39 -0400
To: Peter Palfrader <>
From: Stephen Kent <>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc:, Paul Hoffman <>
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: Wed, 30 Mar 2011 11:40:09 -0000

At 11:14 AM +0200 3/30/11, Peter Palfrader wrote:
>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, 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.
>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.

A CN is a type of attribute in the Subject DN.  A SAN admits a 
variety of name types, some of which can have attributes. Do you mean 
to focus on DNS names as SANs or did you have a broader range of SANs 
in mind?