Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11

Ben Campbell <ben@nostrum.com> Wed, 08 December 2010 05:44 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: certid@core3.amsl.com
Delivered-To: certid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAABB3A68C5; Tue, 7 Dec 2010 21:44:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.127
X-Spam-Level:
X-Spam-Status: No, score=-101.127 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_00=-2.599, MANGLED_LIST=2.3, SPF_PASS=-0.001, 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 5hkEogdPydgh; Tue, 7 Dec 2010 21:44:31 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 464723A689C; Tue, 7 Dec 2010 21:44:31 -0800 (PST)
Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB85joBG096934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Dec 2010 23:45:55 -0600 (CST) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <4CFF13C6.8090807@stpeter.im>
Date: Tue, 07 Dec 2010 23:45:50 -0600
Content-Transfer-Encoding: 7bit
Message-Id: <0BEA063A-8BC5-4292-8F7D-79588E7256EA@nostrum.com>
References: <4CFD8731.9060208@KingsMountain.com> <49E7482C-83CF-4341-B6FA-F75E74038F8E@nostrum.com> <4CFF13C6.8090807@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1082)
Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism)
Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team <gen-art@ietf.org>, IETF cert-based identity <certid@ietf.org>, =JeffH <Jeff.Hodges@KingsMountain.com>
Subject: Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Representation and verification of identity in certificates <certid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/certid>
List-Post: <mailto:certid@ietf.org>
List-Help: <mailto:certid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Dec 2010 05:44:34 -0000

On Dec 7, 2010, at 11:12 PM, Peter Saint-Andre wrote:

> On 12/7/10 6:35 PM, Ben Campbell wrote:
>> 
>> On Dec 6, 2010, at 7:00 PM, =JeffH wrote:
>> 
>>> Peter Saint-Andre <Peter.SaintAndre@webex.com> replied..
>>>> 
>>>> On 12/3/10 2:24 PM, "Ben Campbell" <ben@nostrum.com> wrote:
> 
> <snip/>
> 
>>>>> -- 3.1, 1st paragraph:
>>>>> 
>>>>> It's probably worth emphasizing that the rules are often
>>>>> cumulative.  I think someone thinking about these for the first
>>>>> time might not grasp that until they see examples later in the
>>>>> doc.
>>>> 
>>>> I've added the second sentence to this paragraph:
>>>> 
>>>> When a certification authority issues a certificate based on the 
>>>> fully-qualified DNS domain name at which the application service
>>>> provider will provide the relevant application, the following
>>>> rules apply to the representation of application service
>>>> identities.  The reader needs to be aware that some of these
>>>> rules are cumulative and can interact in important ways that are
>>>> illustrated later in this document.
>>> 
>>> LGTM.
>> 
>> WFM
>> 
>> In fact, as I was re-reading RFC 5922, it occurred to me to wonder if
>> people need guidance one way or another on the idea of
>> "multi-purpose" certs that might have any number of subjectAltName
>> entries for different purposes. I'm talking about virtual domain
>> hosting, or multi-protocol hosts. I assume in the latter case, you
>> would expect a host to use different certs for different protocols.
>> In the first case, is their any guidance to give. I can't remember,
>> do you mention the TLS server_name extension?
>> 
>> (I don't mean to suggest any real action here--just thinking out loud
>> about something that would have been much better to bring up well
>> before IETF LC. :-)  )
> 
> Those scenarios are important, but IMHO how the server determines which
> certificate to present (e.g., based on the SNI or something else, such
> as the 'to' address on an XMPP stream header) is something that an
> application protocol specification needs to define.

Agreed. Does this draft need to say that, or do we just take it as given?

> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art