Re: [keyassure] The draft and subj alt names

Jay Daley <jay@nzrs.net.nz> Fri, 01 April 2011 03:13 UTC

Return-Path: <jay@nzrs.net.nz>
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 EA14D3A6BCE for <keyassure@core3.amsl.com>; Thu, 31 Mar 2011 20:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 tUWNKBSgM2CV for <keyassure@core3.amsl.com>; Thu, 31 Mar 2011 20:13:45 -0700 (PDT)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 875BC3A6BCC for <keyassure@ietf.org>; Thu, 31 Mar 2011 20:13:45 -0700 (PDT)
Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 294582CE005; Fri, 1 Apr 2011 16:15:28 +1300 (NZDT)
Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80lnpOBbeslL; Fri, 1 Apr 2011 16:15:28 +1300 (NZDT)
Received: from [192.168.1.6] (121-73-171-124.dsl.telstraclear.net [121.73.171.124]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 91BB72CE004; Fri, 1 Apr 2011 16:15:27 +1300 (NZDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jay Daley <jay@nzrs.net.nz>
In-Reply-To: <3DCDB1C2-A372-43F0-A87A-AC97D1FEA8A8@bbn.com>
Date: Fri, 1 Apr 2011 16:15:22 +1300
Content-Transfer-Encoding: quoted-printable
Message-Id: <05F78A16-9DC8-4412-9F18-8976928BE8C4@nzrs.net.nz>
References: <4F5CBD0D-E9D4-4042-B082-B15D3D509A37@edvina.net> <57F0D906-4EF8-4628-AAE0-34C661A7184E@bbn.com> <EB7DE8E2-B40F-4C3B-AB21-B27BF053E4C0@nzrs.net.nz> <3DCDB1C2-A372-43F0-A87A-AC97D1FEA8A8@bbn.com>
To: Richard L. Barnes <rbarnes@bbn.com>
X-Mailer: Apple Mail (2.1084)
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: Fri, 01 Apr 2011 03:13:47 -0000

On 1/04/2011, at 3:06 PM, Richard L. Barnes wrote:

> The only choice that avoids updating several RFCs is 5.

Is that your only reason for not wanting to tackle this?  Do you have any view on the nature of trust that DNSSEC provides to applications or not?

>  Just leave it alone!

No.

warmest regards
Jay

> --Richard
> 
> 
> On Mar 31, 2011, at 10:41 PM, Jay Daley wrote:
> 
>> On 1/04/2011, at 12:12 AM, Richard L. Barnes wrote:
>> 
>>> 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.
>> 
>> There are two separate issues here:
>> a) whether we think name matching is still needed with DANE
>> b) what the draft should say about that
>> 
>> On a) I would make the case that name matching is should not be done because
>> - DNSSEC provides sufficient trust
>> - name matching forces certain operational decisions onto end user (e.g. multiple certs, cert reuse) that are unreasonable
>> 
>> On b) There are six options for the draft:
>> 
>> 1.  State that name matching must be done
>> 2.  State that name matching must not be done
>> 3.  Leave it to applications with a recommendation to match
>> 4.  Leave it to applications with a recommendation not to match
>> 5.  Leave it to applications with no recommendation
>> 6.  Add a flag into TLSA that specifies whether name matching is to be done or not
>> 
>> My choice, in order of preference would be 2, 6, 4.  
>> 
>> Jay
>> 
>>> 
>>> --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
>>> 
>>> _______________________________________________
>>> keyassure mailing list
>>> keyassure@ietf.org
>>> https://www.ietf.org/mailman/listinfo/keyassure
>> 
>> 
>> -- 
>> Jay Daley
>> Chief Executive
>> .nz Registry Services (New Zealand Domain Name Registry Limited)
>> desk: +64 4 931 6977
>> mobile: +64 21 678840
>> 
> 


-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840