Subject: RE: draft-ietf-smime-rfc3278-update-02

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 24 Apr 2008 12:41:47 -0400

Alfred,

Thanks for your review.  All of you suggestions were incorporated. In
addition to you suggestion, I also added normative references to X.681,
RFC3370, RFC3565, RFC3852, and RFC5084 because we use/import ASN.1 from each
of these documents. I also added an introductory paragraph before the ASN.1
module.

All,

Does anybody think it would be clearer to resubmit this to be a bis draft
(i.e., obsolete 3278) instead of an update draft?  Originally, the draft
just updated the ECDSA 224-512 and SHA2 algorithms, but now it updates most
of the sections in RFC3278.  I think it might be clearer to just obsolete
RFC3278.

spt

>-----Original Message-----
>Hello,
>I also have reviewed your I-D, draft-ietf-smime-rfc3278-update-02.
>
>Here are my suggestions for further improvements of this memo.
>
>
>(1)   Section 1 -- structure and headlines
>
>I recommend amending the section title to:
>
>  1.  Introduction and Overview of Changes
>
>Below the first paragraph, I suggest to insert a subsection title:
>
>  1.1  Overview of Changes to RFC 3278
>
>(Note: The IESG very much likes to see a section title in the 
>ToC  linking the 'Updates' line in the front matter of the 
>document  to the body of the text.)
>
>And then move the unnumbered section now located between the 
>Abstract and 'Discussion' to the end of the original Section, 
>as a new subsection:
>
>  1.2  Conventions Used in this Document

Reshuffle and retitling done

>(2)  new Section 1.1 (now part of Section 1)
>
>I suggest to enhance the language in the bullets to improve 
>the readablitiy and precision of the text, as shown below.
>
>In particular, the repeated clause,
>  "... expands the options to the allowed algorithms to ..."
>seems to be potentially unclear.  I suggest to always use:
>  "... expands the set of allowed algorithms by adding ..."
>or simply:
>  "... expands the set of allowed algorithms by ..."
>
>Also, I recommend to make consistent use of present tense.

Agreed

>In the bullet related to Section 8.1, "algorithms for ..."
>should be changed to "algorithm identifiers for ...", and the 
>repeated use of "and" should be avoided to better represent 
>the logical grouping of the list given.

Agreed

>This leads to the following bullet-wise changes (using the log 
>form of above):
>
>    - Paragraph 3.1.1 used SHA1 in the KDF with ECDH std and cofactor
>      methods.  This document expands the options to the allowed
>      algorithms to SHA-224, SHA-256, SHA-384, and SHA-512.
>---
>    - Paragraph 3.1.1 used SHA1 in the KDF with ECDH std and cofactor
>|     methods.  This document expands the set of allowed algorithms by
>|     adding SHA-224, SHA-256, SHA-384, and SHA-512.

Fixed

>    - Paragraph 3.1.2 used SHA1 in the KDF with ECMQV. This document
>      expands the options to the allowed algorithms to SHA-224, SHA-
>      256, SHA-384, and SHA-512.
>---
>    - Paragraph 3.1.2 used SHA1 in the KDF with ECMQV. This document
>|     expands the set of allowed algorithms by adding SHA-224, SHA-256,
>      SHA-384, and SHA-512.

Fixed

>    - Paragraph 5 was update to include requirements for ...
>---               vvv      v
>    - Paragraph 5 is updated to include requirements for ...

Fixed

>    - Paragraph 7 was update to include S/MIME capabilities ...
>---               vvv      v
>    - Paragraph 7 is updated to include S/MIME capabilities ...

Fixed

>    - Paragraph 8.1 listed the algorithm identifiers for SHA-1 
>and SHA-1
>|     with ECDSA. This document adds algorithms for SHA-224, SHA-256,
>                           vvv       ^^^^^^^^^^
>|     SHA-384, and SHA-512 and SHA-224, SHA-256, SHA-384, and SHA-512
>      with ECDSA. This document also updates the list of algorithm
>      identifiers for ECDH std, ECDH cofactor, and ECMQV with SHA2
>      algorithms as the KDF.
>---
>    - Paragraph 8.1 listed the algorithm identifiers for SHA-1 
>and SHA-1
>|     with ECDSA.  This document adds algorithm identifiers 
>for SHA-224,
>|     SHA-256, SHA-384, and SHA-512 as well as SHA-224, SHA-256, SHA-
>      384, and SHA-512 with ECDSA.  This document also updates the list
>      of algorithm identifiers for ECDH std, ECDH cofactor, and ECMQV
>      with SHA2 algorithms as the KDF.

Fixed

>(3)  Section 6
>
>The second 'New' part seems to be overly complex, hiding the 
>relatively simple orthogonal structure of its content.
>I suggest to remain more closely with the 'Old' style.
>
>Also, the clause "is not a complete list" is potentially 
>misleading and should better be rephrased.
>
>I suggest the following replacement text:
>
>   New:
>
>      The SMIMECapability value to indicate support for
>|        a)  the standard ECDH key agreement algorithm,
>|        b)  the cofactor ECDH key agreement algorithm, or
>|        c)  the 1-Pass ECMWV key agreement algorithm
>|     is a SEQUENCE with the capabilityID field containing the object
>      identifier
>|        a)  dhSingPass-stdDH-sha*kdf-scheme,
>|        b)  dhSingPass-cofactorDH-sha*kdf-scheme, or
>|        c)  mqvSinglePass-sha*kdf-scheme,
>|     respectively (where * is 1, 224, 256, 384, or 512) with the
>      parameters present.  The parameters indicate the supported
>      key-encryption algorithm with the KeyWrapAlgorithm algorithm
>|     identifier.
>|
>|     Example DER encodings that indicate some capabilities are as
>      follows (KA is key agreement, KDF is key derivation function,
>|     and Wrap is key wrap algorithm):
>
>... followed by the 3x3 = 9 examples already present in the 
>text, (without the two additional paragraphs of text).

Fixed

>(4)  Section 7
>
>(7a)  1st 'New': period missing at the end of the first paragraph.

Fixed

>(7b)  2nd 'New', last paragraph:   s/is/are/  ,  giving:
>      "When the object identifiers ... are used within ..."

Fixed

>(5)  Section 10
>
>(5a)
>Please give an indication of the ASN.1 version used, and add a 
>Reference to X.680.

Fixed. Also added reference to X.681.

>(5b)
>As a service to the reader, I suggest to amend all FROM 
>clauses in the IMPORTS ASN.1 statement by an ASN.1 comment 
>stating the document (RFC) where the named ASN.1 module is defined.

Added comments to indicate which document the imports come from. Since we
imported the ASN.1 from 4 RFCs that weren't reference I also added normative
references for RFC 3370, 3565, 3852, and 5084.

>(5c)
>In the first two extensible set definitions  s/::/::=/     :-)

Fixed