Re: [keyassure] The draft and subj alt names

=JeffH <Jeff.Hodges@KingsMountain.com> Mon, 04 April 2011 14:49 UTC

Return-Path: <Jeff.Hodges@KingsMountain.com>
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 9F5193A680A for <keyassure@core3.amsl.com>; Mon, 4 Apr 2011 07:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
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 qppuL5ia7dfj for <keyassure@core3.amsl.com>; Mon, 4 Apr 2011 07:49:18 -0700 (PDT)
Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 8FF4C3A67F5 for <keyassure@ietf.org>; Mon, 4 Apr 2011 07:49:18 -0700 (PDT)
Received: (qmail 30755 invoked by uid 0); 4 Apr 2011 14:51:01 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy2.bluehost.com with SMTP; 4 Apr 2011 14:51:01 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=kj94Fj/28g/7ukp8p5L5lkLZyqGfeDqZskg1xicA9+pz5dRwbmWTZp9lE7d4VhNOeuR4GP6T9lzeQPlzmhdSlaHGX2EglY6wmxYXLapTegsCQbkQUiFZDbEJqazW9N6P;
Received: from zcu-mobile-n410.zcu.cz ([147.228.185.154]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1Q6l7M-0005O1-Rm for keyassure@ietf.org; Mon, 04 Apr 2011 08:51:01 -0600
Message-ID: <4D99DAD3.50205@KingsMountain.com>
Date: Mon, 04 Apr 2011 07:50:59 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: IETF DANE WG list <keyassure@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 147.228.185.154 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [keyassure] The draft and subj alt names
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, 04 Apr 2011 14:49:25 -0000

On Mar 31, 2011, at 12:05 PM, Olle E. Johansson wrote:

 > I have read the draft and reacted to one thing. Sorry if this already have 
been discussed on the list.
 >
 > The draft -06 says
 > "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. "
 >
 > The new RFC 6125 tells us that we should:
 > "Move toward including and checking even more specific
 >      subjectAlternativeName extensions where appropriate for using the
 >      protocol (e.g., uniformResourceIdentifier and the otherName form
 >      SRVName)."
 >


"Richard L. Barnes" <rbarnes@bbn.com> replied on Thu, 31 Mar 2011 13:12:32 +0200..
 >
 > 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.


+1 to what Richard says.

The RFC6125 (aka "TLS Server Identity Check") text quoted by Olle is a 
suggestion to _applications_ to move away from CN-ID and towards leveraging 
SubjectAlternativeName (SAN) name types in terms of the identifiers embedded in 
certs and checked against _at the app layer_ during TLS connection establishment.

I think that Richard is correct that what the DANE WG is designing lies "below" 
the applications, and it is still their job to ascertain whether the name(s) 
embedded in the cert used to secure the connection meaningfully match the 
intended server. Please see sections 1 and 2 of RFC6125 for an in-depth 
discussion of the nuances.

HTH,

=JeffH