Re: [keyassure] The draft and subj alt names

"Richard L. Barnes" <rbarnes@bbn.com> Thu, 31 March 2011 11:11 UTC

Return-Path: <rbarnes@bbn.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 E93033A6B3C for <keyassure@core3.amsl.com>; Thu, 31 Mar 2011 04:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.552
X-Spam-Level:
X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, 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 X7tJws-6+++Y for <keyassure@core3.amsl.com>; Thu, 31 Mar 2011 04:11:05 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id ADDE13A6B3B for <keyassure@ietf.org>; Thu, 31 Mar 2011 04:11:04 -0700 (PDT)
Received: from [128.89.255.164] (port=49214 helo=[130.129.71.95]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Q5Fnv-0005AB-Ih; Thu, 31 Mar 2011 07:12:43 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <4F5CBD0D-E9D4-4042-B082-B15D3D509A37@edvina.net>
Date: Thu, 31 Mar 2011 13:12:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <57F0D906-4EF8-4628-AAE0-34C661A7184E@bbn.com>
References: <4F5CBD0D-E9D4-4042-B082-B15D3D509A37@edvina.net>
To: "Olle E. Johansson" <oej@edvina.net>
X-Mailer: Apple Mail (2.1082)
Cc: keyassure@ietf.org
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: Thu, 31 Mar 2011 11:11:07 -0000

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.

--Richard



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)."
> 
> I feel we need to be more specific in the draft.  What type of subjectAltName should we match with?
> dnsName?
> 
> And if we're using SIP, and have URI's in the certificate - should that be part of this draft
> or should we open for protocol-specific specifications for other types of subject Alt Names?
> 
> /O
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure