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

<kathleen.moriarty@emc.com> Tue, 24 January 2012 18:00 UTC

Return-Path: <kathleen.moriarty@emc.com>
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 AAE2121F865A; Tue, 24 Jan 2012 10:00:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.522
X-Spam-Level:
X-Spam-Status: No, score=-9.522 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 PoFx8e3a6DlS; Tue, 24 Jan 2012 10:00:21 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id B886621F864D; Tue, 24 Jan 2012 10:00:21 -0800 (PST)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0OI088v019990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jan 2012 13:00:18 -0500
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 24 Jan 2012 12:59:58 -0500
Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0OHxvoG029232; Tue, 24 Jan 2012 12:59:57 -0500
Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Tue, 24 Jan 2012 12:59:57 -0500
From: kathleen.moriarty@emc.com
To: alexey.melnikov@isode.com, stpeter@stpeter.im
Date: Tue, 24 Jan 2012 12:59:55 -0500
Thread-Topic: [Gen-art] Gen-ART last call review of draft-ietf-mile-rfc6046-bis-05
Thread-Index: AczauZWrTlHZwpEGQJmRsNEooCM0SAAB2R5w
Message-ID: <AE31510960917D478171C79369B660FA0E2BFCC87B@MX06A.corp.emc.com>
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>
In-Reply-To: <4F1EE379.7080505@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: gen-art@ietf.org, iesg@ietf.org, trammell@tik.ee.ethz.ch
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 18:00:22 -0000

I agree, the guidance in RFC6125 Section 2.4 is pretty clear and should just be referenced if we go this route.  I do have a question out to a practitioner to see if we need to allow anything other than DNS-IDs.  She did say support is good in CAs, maybe it is OK to require DNS-IDs.  She will be posting to MILE later today.  Are there any CAs that do not support this yet?  RFC6125 says this is to support older CAs, but has this changed?  RFC6125 was only published in March, so it may still be important.  

Thanks,
Kathleen

-----Original Message-----
From: gen-art-bounces@ietf.org [mailto:gen-art-bounces@ietf.org] On Behalf Of Alexey Melnikov
Sent: Tuesday, January 24, 2012 12:00 PM
To: Peter Saint-Andre
Cc: gen-art@ietf.org; Moriarty, Kathleen; The IESG; Brian Trammell
Subject: Re: [Gen-art] Gen-ART last call review of draft-ietf-mile-rfc6046-bis-05

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").

The rest of your proposal looks fine.
> 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
>

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art