[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-smime-rfc3278-update-02
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