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

Alexey Melnikov <> Thu, 26 January 2012 19:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1BE621F8615; Thu, 26 Jan 2012 11:02:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.156
X-Spam-Status: No, score=-101.156 tagged_above=-999 required=5 tests=[AWL=-0.757, BAYES_00=-2.599, J_BACKHAIR_13=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BzT3vh5RXltk; Thu, 26 Jan 2012 11:02:53 -0800 (PST)
Received: from ( [IPv6:2a00:14f0:e000:7c::2]) by (Postfix) with ESMTP id B5E6B21F85D1; Thu, 26 Jan 2012 11:02:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327604571;; s=selector;; bh=hNhnoZx8JQcoTdPGnnuJM+ARTc8wIqnbdW9WemWDUjU=; 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=hmyYOU8jmuKShmZfKpHQP6q12YM/3q3dz4tZvKz5IytqvYw6tHAHo7IcoXmCwXwM1pe22/ BzDvBrFOthXWn0W6y/7XuovaJuhaeasCp5UxTI5/cnn2c4esZw1xnCXqFvXXoF+/OQFoby vFB3/wnXl1low0ZuEzvlvdWvjnV9L9E=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Thu, 26 Jan 2012 19:02:51 +0000
Message-ID: <>
Date: Thu, 26 Jan 2012 19:03:03 +0000
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: Brian Trammell <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc:, Kathleen Moriarty <>, The IESG <>, Peter Saint-Andre <>
Subject: Re: [Gen-art] Gen-ART last call review of draft-ietf-mile-rfc6046-bis-05
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Jan 2012 19:02:53 -0000

On 24/01/2012 19:17, Brian Trammell wrote:
> Hi, Peter, Alexey, all,
Hi Brian,
> 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?
Your text basically says that DNS-ID are mandatory to include and use. 
RFC 6125 requires for DNS-ID to take precedence over CN-ID, if both are 
present. I don't think this leave any space for older PKI systems that 
only include CN-IDs. If you want to allow for them, I think you need to 
make the requirement on having DNS-ID a SHOULD (for example. Other ways 
might be possible.)

But otherwise I am Ok with your text.
> 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