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

Peter Saint-Andre <stpeter@stpeter.im> Wed, 08 December 2010 22:49 UTC

Return-Path: <stpeter@stpeter.im>
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 1FC2D3A69AD; Wed, 8 Dec 2010 14:49:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.495
X-Spam-Level:
X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 InbyzziXw+8s; Wed, 8 Dec 2010 14:49:53 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C03A93A69A9; Wed, 8 Dec 2010 14:49:52 -0800 (PST)
Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 01B814009B; Wed, 8 Dec 2010 16:03:12 -0700 (MST)
Message-ID: <4D000BE6.50208@stpeter.im>
Date: Wed, 08 Dec 2010 15:51:18 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: =JeffH <Jeff.Hodges@KingsMountain.com>
References: <4D000B33.2050405@KingsMountain.com>
In-Reply-To: <4D000B33.2050405@KingsMountain.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms060103000604090804010803"
Cc: Ben Campbell <ben@nostrum.com>, General Area Review Team <gen-art@ietf.org>, IETF cert-based identity <certid@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, draft-saintandre-tls-server-id-check.all@tools.ietf.org
Subject: Re: [certid] 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 22:49:54 -0000

On 12/8/10 3:48 PM, =JeffH wrote:
>> Possible text for the Security Considerations:
>>
>> ###
>>
>> 5.4.  Multiple Identifiers
>>
>>    This specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a
>>    certificate, but discourages multiple CN-IDs.  The inclusion in the
>>    Common Name of multiple strings whose form matches that of a fully-
>>    qualified DNS domain name (e.g., "www.example.com") makes it more
>>    difficult to parse the Common Name and increases the likelihood of
>>    false positives in the identity verification process.  Although it
>>    would be preferable to forbid multiple CN-IDs entirely, there are
>>    several reasons why this specification states that they SHOULD NOT
>>    (instead of MUST NOT) be included:
>>
>>    o  At least one significant technology community of interest
>>       explicitly allows multiple CN-IDs [EV-CERTS].
>>
>>    o  At least one significant certification authority is known to issue
>>       certificates containing multiple CN-IDs.
>>
>>    o  Many service providers often deem inclusion of multiple CN-IDs
>>       necessary in "virtual hosting" environments because at least one
>>       widely-deployed operating system does not yet support the Server
>>       Name Indication extension [TLS-EXT]
>>
>>    It is hoped that the recommendation in this specification can be
>>    further tightened in the future.
>>
>> ###
>>
>> To be referenced from bullet #6 in Section 3.1:
>>
>>    6.  The certificate MAY contain more than one DNS-ID, SRV-ID, or
>>        URI-ID (but SHOULD NOT contain more than one CN-ID, as further
>>        explained under Section 5.4).
> 
> 
> in general looks good to me, thanks.
> 
> However, I'd alter the first sentence to  s/allows/accommodates/, and in
> 2nd sentence s/discourages/explicitly discourages/.
> 
> I'd alter the last sentence of 1st para s/reasons/reasons at this time/.

Agreed, and fixed.

> And in terms of this..
> 
>                                                   The inclusion of
>     multiple strings whose form matches that of a fully-qualified DNS
>     domain name (e.g., "www.example.com") makes it more difficult to
>     parse the Common Name and therefore increases the likelihood of false
>     positives in the identity verification process.
> 
> 
> ..well, no, it doesn't make it more difficult to parse, and "it" is the
> Subject, not "the CN". There's multiple CN= AVAs in the Subject, but
> parsing
> them out is simple.  I guess I'd just delete that entire middle sentence
> "The
> inclusion of...process."

Well, since this text is in the security considerations section,
presumably we need to provide some security-related justification for
saying you SHOULD NOT include multiple CN-IDs, instead of mere aesthetic
preference. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/