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

Brian Trammell <> Tue, 17 January 2012 10:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15A4421F8505; Tue, 17 Jan 2012 02:16:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TbjFkkDOAMy2; Tue, 17 Jan 2012 02:16:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C07AA21F852D; Tue, 17 Jan 2012 02:16:50 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC0A2D9308; Tue, 17 Jan 2012 11:16:48 +0100 (MET)
X-Virus-Scanned: by amavisd-new on
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id Qgie-9s5y9-e; Tue, 17 Jan 2012 11:16:48 +0100 (MET)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by (Postfix) with ESMTPSA id 9B889D9305; Tue, 17 Jan 2012 11:16:48 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="windows-1252"
From: Brian Trammell <>
In-Reply-To: <>
Date: Tue, 17 Jan 2012 11:16:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Alexey Melnikov <>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Tue, 17 Jan 2012 05:18:56 -0800
Cc: Kathleen Moriarty <>,, The IESG <>
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: Tue, 17 Jan 2012 10:16:55 -0000

Hi, Alexey,

Thanks for the review; questions and comments thereon inline...

On Jan 14, 2012, at 9:45 PM, Alexey Melnikov wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <>.
> Please resolve these comments along with any other Last Call comments you may receive.
> Document: draft-ietf-mile-rfc6046-bis-05
> Reviewer: Alexey Melnikov
> Review Date: 2012–01–14
> IETF LC End Date: 2012-01-17
> IESG Telechat date: 2012-01-19
> Summary: This draft is almost ready for publication as a Proposed Standard RFC.
> Major issues:
> In Section 3:
>   The RID callback MUST contain a zero-length entity body
>   and a 'RID-Callback-Token' entity header
> [Minor issue] "header" --> "header field" (header is the collection of all header fields).
>   , itself containing a unique
>   token generated by the receiving RID system.
> I am missing ABNF for the new header field.

Seems a little superfluous... it's an opaque string, but I suppose we should point out it doesn't contain \r or \n... Will add.

>   RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
>   authentication for transport confidentiality, identification, and
> Do you mean that a RID client must use X.509 certificates?

Well, each RID system (HTTP client or server) is identified by an X.509 certificate (hence "mutual"); how can I make this clearer?

>   authentication, as in [RFC2818].
> I find the whole sentence to be confusing. Note that the rules of RFC 6125 for certificate verification are stricter than in RFC 2818 and this sentence can be read as conflicting with the paragraph below which requires use of RFC 6125. What are you trying to say here?

The intention here is "Use current best practices as would be supported by off-the-shelf HTTP/1.1 and TLS 1.1 implementations to provide mutual authentication." "Current best practices", however, seems to be something of a moving target.

I cite 2818 as it is the current binding between HTTP/1.1 and TLS. I cite 6125 solely for certificate verification. 

>   RID systems MUST provide for the verification of the identity of a
>   RID system peer presenting a valid and trusted certificate, by
>   verifying the fully-qualified domain name and service name from the
>   DNS SRV record, if available, against that stored in the certificate,
> I am confused: this is the first time DNS SRV records are mentioned
> (BTW, they need a Normative Reference). Earlier text seem to suggest that DNS SRV are not used to locate protocol endpoints. If RID is using DNS SRV, then information about how it is used is missing from the document.

It doesn't. Was trying to point out here that SRV must be matched if (for deployment-specific reasons) it was present. This is simply a poor attempt at citing 6125.

>   as in Section 6 of [RFC6125].
> RFC 6125 allows for various options and this paragraph doesn't seem to cover all of them. I suggest you check Section of RFC 6120 for an example of what should be specified (ignore XmppAddr identifier type, as it is very XMPP specific). For X.509 SANs which are disallowed, you should say so.

Will do. (6125 is missing something here, a guide for using it in other specs...)

Best regards,