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

Brian Trammell <trammell@tik.ee.ethz.ch> Tue, 24 January 2012 19:17 UTC

Return-Path: <trammell@tik.ee.ethz.ch>
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 1730611E8072; Tue, 24 Jan 2012 11:17:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 F5BPjuOf6eZy; Tue, 24 Jan 2012 11:17:27 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D748511E8096; Tue, 24 Jan 2012 11:17:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 03F19D9308; Tue, 24 Jan 2012 20:17:26 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8BB1dmxBukmq; Tue, 24 Jan 2012 20:17:25 +0100 (MET)
Received: from [10.90.4.76] (unknown [89.200.200.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 22659D9307; Tue, 24 Jan 2012 20:17:25 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Brian Trammell <trammell@tik.ee.ethz.ch>
In-Reply-To: <4F1EE5FE.9090702@stpeter.im>
Date: Tue, 24 Jan 2012 20:17:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D2D1AC5F-6510-4AD8-A7C0-EF9FDB018774@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> <4F1EE02A.5070800@stpeter.im> <4F1EE379.7080505@isode.com> <4F1EE5FE.9090702@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1084)
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 19:17:28 -0000

Hi, Peter, Alexey, all,

Thanks for the suggestion on fixing the ambiguity in "use" -- that was bothering me a bit, too...

Okay, so how about straight NOT RECOMMENDED, which would make the whole paragraph:

    <t>RID systems MUST verify the identity of their peers against that stored
    in the certificate presented. All RID systems MUST be identified by a
    certificate containing a <xref target="RFC5280">DNS-ID identifier</xref>
    as in section 6.4 of <xref target="RFC6125"/>. The inclusion of Common
    Names (CN-IDs) in certificates identifying RID systems is NOT RECOMMENDED.
    Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate
    identifying a RID system. Additional general information on the use of PKI
    with RID systems is detailed in Section 9.3 of <xref
    target="I-D.ietf-mile-rfc6045-bis"/>.</t>

And we let people who really, really need to support CN-ID read between the lines. Thoughts?

Cheers,

Brian

On Jan 24, 2012, at 6:10 PM, Peter Saint-Andre wrote:

> On 1/24/12 9:59 AM, Alexey Melnikov wrote:
>> On 24/01/2012 16:45, Peter Saint-Andre wrote:
>>> 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.
>> I thought RFC 6125 has a rule saying that CN-IDs are ignored in presence
>> of DNS-IDs? I would just rather reference RFC 6125, or at least be clear
>> that this is defined there (using "as specified in RFC 6125").
> 
> Yes, so you're right: just reference the rules from RFC 6125.
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
>