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

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 23 January 2012 15:32 UTC

Return-Path: <alexey.melnikov@isode.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 CBC2C21F86AF; Mon, 23 Jan 2012 07:32:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.257
X-Spam-Level:
X-Spam-Status: No, score=-101.257 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_00=-2.599, J_BACKHAIR_13=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=0.6, 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 WcBGYi-qK+f6; Mon, 23 Jan 2012 07:32:50 -0800 (PST)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id D712321F8683; Mon, 23 Jan 2012 07:32:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327332765; d=isode.com; s=selector; i=@isode.com; bh=/CsDCCARIJ2LFL0ppF9o8lIrrAF5HLeVNfm5KO8BX3o=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=cjXNWrArKI7bE/FM2OaTQTViV6uj5pGLs/F+lByBvRQQUs8OvPYzG1d0lIbccoQ06fPOux dYMSi54SCi18upQ0f5kjD7W2pkNpvycs304QmP+NlVIRqc2FCSf4Yk66QC1/GKPFpWMVHr hdh6G5bWkIYEn0wnk45q+cxxYw5rrWY=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <Tx19nAAV57ci@rufus.isode.com>; Mon, 23 Jan 2012 15:32:45 +0000
Message-ID: <4F1D7DA7.8060600@isode.com>
Date: Mon, 23 Jan 2012 15:32:55 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.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>
In-Reply-To: <5ED8B1A1-11AF-4416-9940-63C75358FFF3@tik.ee.ethz.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: gen-art@ietf.org, Kathleen Moriarty <kathleen.moriarty@emc.com>, The IESG <iesg@ietf.org>, Peter Saint-Andre <stpeter@stpeter.im>
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: Mon, 23 Jan 2012 15:32:50 -0000

On 23/01/2012 14:22, Brian Trammell wrote:
> Hi, Alexey,
Hi Brian,
> one more round (hopefully) :) ...
>
> On Jan 23, 2012, at 2:19 PM, Alexey Melnikov wrote:
>
>>> Okay; how about the following (including Alexey's comments from the previous review, and pointing more specifically to 6125)
>>>
>>>      <t>RID systems MUST verify the identity of their peers against that stored
>>>      in the certificate presented, as in section 6 of<xref target="rfc6125"/>.
>>>      As RID systems are identified not by URI and RID does not use DNS SRV
>>>      records, they are identified solely by their DNS Domain Names; see Section
>>>      6.4 of<xref target="rfc6125"/>.
>> (I think you are saying that [using RFC 6125 terminology] DNS-IDs are supported, but SRV-IDs or URI-IDs aren't.)
> I can say that directly then.
That would be good, thanks.

>> This is better, but I think you need to say a bit more. Are CN-IDs allowed? Are wildcards allowed?
> Here, I'm a little unclear on the implications this has for implementation: is it reasonable to assume that all implementations that support TLS 1.1 should not require CN-IDs for backward compatibility?

There is no direct correlation. But you should keep away from CN-IDs in 
new protocols, if you can. RFC 6125 goes into details why CN-ID don't 
necessarily work.
In reality though, you might have to support CN-IDs if you are using 
existing Certificate Authorities, as opposed to creating your own ones.

>> Another example of the document that describes
>> http://tools.ietf.org/html/draft-melnikov-email-tls-certs-00
> Thanks for the example. Here's what I've come up with for now...
>
>      <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"/>. Certificates identifying
>      RID systems MAY additionally contain a CN-ID identifier, to allow backward
>      compatibility with older PKI implementations. 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>
>
> (The text about CN-IDs would be removed if the assumption that TLS 1.1 implies no need for CN-ID, as above)
This looks Ok (with or without CN-ID). I am a bit undecided about CN-ID.
>
> Thanks,
>
> Brian
>