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