Re: [Gen-art] Gen-ART last call review of draft-ietf-mile-rfc6046-bis-05

Peter Saint-Andre <stpeter@stpeter.im> Tue, 24 January 2012 16:45 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1144021F8636; Tue, 24 Jan 2012 08:45:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.65
X-Spam-Level:
X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IGjmaiWP+9A; Tue, 24 Jan 2012 08:45:32 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4E421F8613; Tue, 24 Jan 2012 08:45:32 -0800 (PST)
Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7FABC40058; Tue, 24 Jan 2012 09:55:13 -0700 (MST)
Message-ID: <4F1EE02A.5070800@stpeter.im>
Date: Tue, 24 Jan 2012 09:45:30 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Brian Trammell <trammell@tik.ee.ethz.ch>
References: <4F11E975.9070307@isode.com> <10722E0B-059E-4800-84C0-B330F397B63A@tik.ee.ethz.ch> <4F16D95A.3000006@isode.com> <89E47BB4-C228-4700-94C4-3F4ED03F99A2@tik.ee.ethz.ch> <4F1704DE.1090208@isode.com> <4F170904.2000603@isode.com> <60243B0C-A3FF-4B51-AFF8-27C34158E02E@tik.ee.ethz.ch> <4F185391.9050005@isode.com> <4F18704B.4010309@stpeter.im> <C36BCAAE-5F03-4514-8F18-34A5476C3F8E@tik.ee.ethz.ch> <4F1D5E5A.6090505@isode.com> <5ED8B1A1-11AF-4416-9940-63C75358FFF3@tik.ee.ethz.ch> <4F1D7DA7.8060600@isode.com> <BAE06AC9-65DE-451E-8DE2-462CCC0B479C@tik.ee.ethz.ch> <4F1D8808.9090203@isode.com> <48460543-BDED-4B54-B1A7-07D210968A08@tik.ee.ethz.ch>
In-Reply-To: <48460543-BDED-4B54-B1A7-07D210968A08@tik.ee.ethz.ch>
X-Enigmail-Version: 1.3.4
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: gen-art@ietf.org, Kathleen Moriarty <kathleen.moriarty@emc.com>, The IESG <iesg@ietf.org>
Subject: Re: [Gen-art] Gen-ART last call review of draft-ietf-mile-rfc6046-bis-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jan 2012 16:45:33 -0000

On 1/24/12 2:25 AM, Brian Trammell wrote:
> Hi, Alexey,
> 
> So far only one voice on the WG list, stating no need for CN-ID. However, on thinking about it a bit further, if you happen to have an older PKI built out, and you're still using it, you've probably got a large investment in it, and it probably makes sense to allow you to use it for RID too...
> 
> So, I'd suggest the following language to grudgingly allow such a thing:
> 
> The use of CN-ID identifiers in certificates identifying RID systems
> is NOT RECOMMENDED, and CN-ID identifiers MUST be ignored by PKI
> implementations which can use DNS-ID identifiers. However, CN-ID 
> identifiers MAY be used when the RID consortium to which the system 
> belongs uses an older, existing PKI implementation. 

Brian, first of all, thanks for working with us on this topic. As you
can see from the length of RFC 6125 (which didn't start out that big!),
there's more complexity here than meets the eye.

I think the mix of "NOT RECOMMENDED, MUST be ignored by some, but MAY be
used by others" might be a bit confusing to those who implement and
deploy RID. Also, RFC 6125 makes a distinction between cert generation
and cert checking, which gets obscured by the word "use". Thus I might
make the following suggestion:

   The inclusion of Common Names (CN-IDs) in certificates identifying
   RID systems is NOT RECOMMENDED.  A PKI implementation that
   understands DNS-IDs SHOULD ignore CN-IDs when checking server
   certificates. However, because many existing PKI implementations
   still include CN-IDs when generating certificates, RID consortiums
   might want to continue supporting them during certificate checking.

This removes the normative force from the text about existing PKI
implementations, while still encouraging use of DNS-IDs.

Let us know what you think.

Peter

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