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

[Andrey Jivsov <[e-mail]>]

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.