[keyassure] The draft and subj alt names

"Olle E. Johansson" <oej@edvina.net> Thu, 31 March 2011 10:04 UTC

Return-Path: <oej@edvina.net>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 402453A6A4D for <keyassure@core3.amsl.com>; Thu, 31 Mar 2011 03:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id EBhKIzKnXoHA for <keyassure@core3.amsl.com>; Thu, 31 Mar 2011 03:04:11 -0700 (PDT)
Received: from smtp6.webway.se (smtp2.webway.se []) by core3.amsl.com (Postfix) with ESMTP id 56C303A6919 for <keyassure@ietf.org>; Thu, 31 Mar 2011 03:04:10 -0700 (PDT)
Received: from [] (unknown []) by smtp6.webway.se (Postfix) with ESMTPA id 951F2552C41; Thu, 31 Mar 2011 10:05:48 +0000 (UTC)
From: "Olle E. Johansson" <oej@edvina.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 31 Mar 2011 12:05:48 +0200
To: keyassure@ietf.org
Message-Id: <4F5CBD0D-E9D4-4042-B082-B15D3D509A37@edvina.net>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [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 10:04:12 -0000

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

I feel we need to be more specific in the draft.  What type of subjectAltName should we match with?

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?