Re: [Gen-art] Gen-ART LC Review of draft-jivsov-openpgp-ecc-10

Andrey Jivsov <openpgp@brainhub.org> Tue, 20 March 2012 21:51 UTC

Return-Path: <openpgp@brainhub.org>
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 04ACF21F8574 for <gen-art@ietfa.amsl.com>; Tue, 20 Mar 2012 14:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.444
X-Spam-Level:
X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001]
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 gNsoBb1o-iJq for <gen-art@ietfa.amsl.com>; Tue, 20 Mar 2012 14:51:09 -0700 (PDT)
Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by ietfa.amsl.com (Postfix) with ESMTP id E15CD21F856F for <gen-art@ietf.org>; Tue, 20 Mar 2012 14:51:08 -0700 (PDT)
Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta03.emeryville.ca.mail.comcast.net with comcast id nxkE1i0040x6nqcA3xr80s; Tue, 20 Mar 2012 21:51:08 +0000
Received: from [127.0.0.1] ([98.234.252.65]) by omta12.emeryville.ca.mail.comcast.net with comcast id nxr51i00K1RRS8a8Yxr6sU; Tue, 20 Mar 2012 21:51:08 +0000
Message-ID: <4F68FC11.6000209@brainhub.org>
Date: Tue, 20 Mar 2012 14:52:17 -0700
From: Andrey Jivsov <openpgp@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C413D2304@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C413D2304@ESESSCMS0356.eemea.ericsson.se>
Content-Type: multipart/mixed; boundary="------------060503010707080604050701"
X-Mailman-Approved-At: Tue, 20 Mar 2012 15:23:36 -0700
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-jivsov-openpgp-ecc.all@tools.ietf.org" <draft-jivsov-openpgp-ecc.all@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART LC Review of draft-jivsov-openpgp-ecc-10
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, 20 Mar 2012 21:51:13 -0000

Hello Christer, thank you for the feedback.

I attempted to integrate your every comment into the 
draft-jivsov-openpgp-ecc-11 revision that I attached to this e-mail (I 
didn't post it via IETF tools.) I am also attaching the diff with -10.

The summary of my changes are inlined bellow:

On 03/19/2012 05:07 AM, Christer Holmberg wrote:
>
> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments 
> you may receive.
>
> Document:                                         
> draft-jivsov-openpgp-ecc-10
>
> Reviewer:                                           Christer Holmberg
>
> Review Date:                                     2012-03-19
>
> IETF LC End Date:                             2012-04-09
>
> IESG Telechat date: (if known)   2012-04-09
>
> Summary:           The draft is ready for publication, with a couple 
> of editorial nits.
>
> Major issues:     -
>
> Minor issues:     -
>
> Nits/editorial comments:
>
> Q1:         The “MPI” abbreviation is used throughout the document, 
> but it is not expanded anywhere, nor is there any reference.
>
Done by referring to RFC 4880 and expanding MPI on first use to 
Multiprecision Integer.

> Q2:         The Abstract says:
>
>                 “The document aims to standardize an optimal but 
> narrow set of parameters for best interoperability”
>
> I think it would to make it more clear what interoperability you refer to.
>

Corrected this issue and  the next one ...
>
> Q3:         The Abstract says:
>
>                 “within the framework it defines”
>
>                 However, the framework is not 
> mentioned/clarified/defined anywhere in the document, so if you want 
> to talk about a framework I think some clarification is needed.
>

... with the following text:

>
>    This document defines an Elliptic Curve Cryptography extension to
>    the OpenPGP public key format and specifies three Elliptic Curves
>    that enjoy broad support by other standards, including NIST
>    standards.  The document aims to standardize an optimal but narrow
>    set of parameters for easier interoperability between compliant
>    OpenPGP implementations.
>


> Q4:         In the Introduction, please add references to OpenPGP, RSA 
> and DSA. Also consider expansion on first occurrence.
>

Added the [RFC 4880] next to the OpenPGP in the Introduction, which 
happened to be the first use of OpenPGP in the body of the document. I 
left RSA and DSA undefined, as done in RFC 4880. This document is not 
concerned with these two algorithms.

> Q5:         The document uses “This document”, “This specification”, 
> “This draft” and “This standard” terminology. Please use consistent 
> terminology.
>

Corrected to "this document", which seems like the most common use 
throughout RFCs.

> Q6:         In section 5, I don’t think you need the “defined in” 
> parts. Simply add the reference.
>
>                 Example:             “Elliptic Curve Digital Signature 
> Algorithm (ECDSA) [FIPS 186-3],…”
>
>                 Maybe similar changes can be done in some other parts 
> of the document also.
>

I reduced a few references similar to the one you provided.

I left a few that contain additional qualifiers.

Even in this sentence that you provided, it now reads as:
> Supported public key algorithms are Elliptic Curve Digital
>    Signature Algorithm (ECDSA) [FIPS 186-3] and Elliptic Curve Diffie-
>    Hellman (ECDH), defined in section 8.

After the suggested change I felt  that earlier "defined in [FIPS 
186-3]" provided better parallelism, as I cannot use [section 8]. In any 
case, there will remain plenty of "defined" throughout the document that 
refer to inner sections.


> Q7:         In section 5, consider modifying the following sentence:
>
>                 “The section 9.1. Public-Key Algorithms of [RFC4880] 
> is expanded to define the following public key algorithm IDs”
>
>                 To:
>
>                 “This section extends section 9.1 (Public-Key 
> Algorithms) or [RFC4880], by defining the following public key 
> algorithm IDs”
>

I reworded this sentence, but I kept it to maintain the original 
reference that section 9.1 is a section in RFC 4880.

> Q8:         Section 5 says:
>
>                 “Applications MUST support ECDSA and ECDH.”
>
>                 Please clarify what applications you refer to. I 
> assume you mean “Applications that implement this specification”, or 
> something similar…
>
>                 The same comment also applies to section 12.1, and 
> section 13 (the word is used many times in section 13, but it is 
> enough to clarify it on first occurrence :)
>

I changed the document by introducing the term "compliant application" 
and I replaced the relevant "applications" with "compliant applications".

> Regards,
>
> Christer
>
>
Thank you.