Alfred,
Thanks for the review. Responses inline.
All,
Alfred suggests demoting UTCTime to a SHOULD- in his last comment. I think
we should stay aligned with CMS/PKIX - curious what others think.
spt
-----Original Message-----
(1) Conventions used ...
- The RFC Editor will want to make that a proper (numbered) section.
I suggest to move it to between the current sub-sections 1.1 and 1.2.
Fixed.
- The comments I sent on the same part of draft-ietf-smime-3850bis-02
also apply.
Fixed.
(2) Section 1
(2a) 1st paragraph
For completeness (and matching of what is said in the
Abtract), I suggest to add a short note on message compression
to the end of the first paragraph of Section 1, for instance:
As a supplementary service, S/MIME provides for message compression.
Added the sentence.
(2b) 2nd paragraph
Perhaps the most important usage scenario for S/MIME now is
bound to SIP (using the 'sips' URIs) to protect the
negotioation of multimedia session parameters (cf. RFC 3261).
Therefore, I suggest to replace in the second paragraph of
Section 1 the clause "such as HTTP" by "such as HTTP or SIP".
Added the SIP reference.
(3) General -- terminology
It has been generally recognized that the media type concept
defined in [MIME-SPEC] has outgrown the narrow context of
MIME, and RFC 4288 (BCP 13) has confirmed that the popular
sluggish term "MIME Type"
should not be used, in favor of the proper term "Media Type",
which already had been used throughout [MIME-SPEC].
Therefore, I recommend to also change in this draft all
occurrences of "MIME type" to "media type" (inclusive of the
title of Section 3.4.3.1).
Also, when refering to MIME header fields, their names should
be quoted faithfully for clarity and precision; in particular,
the hyphen should always be included after "Content", e.g.,
"Content type" --> "Content-type".
Agreed
(4) Section 1.1
(4a) 1st paragraph
The draft says:
This document describes a protocol for adding cryptographic
signature
and encryption services to MIME data. The MIME standard [MIME-SPEC]
| provides a general structure for the content type of Internet
| messages and allows extensions for new content type applications.
There are two issues with the use of "content type":
- "structure of the content type" is a slight abuse of language;
"structure of content" is the proper designation.
It does say "structure for the content type :) I changed it to ...structure
for the content of Internet messages...
- "content type applications" seems to be vague and unclear.
I suggest to use "content type specific applications" or
"content type based applications" instead
Choose the later
(4b) 2ns and 3rd paragraph
Please apply (3) -- 3 occurrences.
I did a search for MIME type and replaced them with media type
(5) Section 1.3
For clarity, please add another comma after the first instance
of "inclusive", or place this word in parentheses.
I tweaked it a bit but I think it's fixed now.
(6) Section 1.4
(6a) section title
The legacy section title obviously is outdated, turning it ambiguous.
It should better be changed:
1.4. Changes Since S/MIME v3
---
| 1.4. Changes From S/MIME v3 to S/MIME v3.1
This should properly complement the correctly entitled new section,
1.5. Changes Since S/MIME v3.1
Fixed
(6b) last two paragraphs
Please apply (3) -- two occurrences.
Fixed
(7) Section 1.5 -- typo
Please replace "in parantheticals" by either "parenthetical"
or "in parenthesis".
I deleted "in parantheticals" - it wasn't needed.
(7) Section 1.5 -- typo
Please replace
vv v
"AES-CBC" in parantheticals.
by either:
parenthetical "AES-CBC".
or:
parenthetic "AES-CBC".
or:
"AES-CBC" in parenthesis.
Accepted - I just removed the in parenthesis.
(8) Section 2 -- clarification of the role of [ESS]
I suggest to add a note to the text in Section 2 clarifying
that RFC 2634 [ESS] is applicable for S/MIME v3.2 as well.
This is intended to complement the remarks in Section 1.3
stating that RFC 2634 is part of the S/MIME v3 and S/MIME v3.1
specification.
ESS gets pulled in in section 2.5 when discussing attributes. I did add text
to address ESS in section 2.
(9) Section 2.3
Please replace
using rsaEncryption algorithm.
by either:
using the rsaEncryption algorithm.
or:
using rsaEncryption.
Accepted
(10) Section 2.4.1
The draft says:
vvvvvvvvvvvv
... the MIME content MUST be stored in the SignedData
encapContentInfo eContent OCTET STRING ...
This is misleading; the Content-Type has to be stored there,
not the "content".
In line with (3) above, I suggest to use the phrase:
vvvvvvvvvvv
| ... the media type MUST be stored in the SignedData
encapContentInfo eContent OCTET STRING ...
Accepted
(11) Section 2.4.4, 1st paragraph
I suggest to insert the article "the" giving "reduce the message size".
Accepted
(12) Section 2.5
(12a) 1st paragraph
The draft says, using redundant/replicated wording:
vvvvvvvvvvvvv
The SignerInfo type allows the inclusion of unsigned and signed
attributes to be included along with a signature.
^^^^^^^^^^^^^^
I suggest to simplify the wording to:
The SignerInfo type allows the inclusion of unsigned and signed
| attributes along with a signature.
^
Accepted
(12b) 2nd-to-last paragraph
The draft says:
[..]. Receiving agents SHOULD handle attributes or
values that it does not recognize in a graceful manner.
The wording "receiving agents ... it does not" should be improved upon.
I suggest either to turn to singular:
vv vv
| [..]. A Receiving agent SHOULD handle
attributes or
values that it does not recognize in a graceful manner.
or substitute "they" in the last line:
[..]. Receiving agents SHOULD handle attributes or
| values they do not recognize in a graceful manner.
^^^^^^^
Accepted (used the 2nd one)
(13) Section 2.5.1
The rules for UTCTime vs. GeneralizedTime are unfortunate for
several reasons, as I have pointed out in recent comments on
RFC 5280. They violate the lessons learned during Y2K that
4 decimal digits should *always* be encoded for year numbers,
and they cause general non-exercising of 'MUST implement'
code, generating a new security risk.
I strongly recommend to, at a minimum, demote the "MUST" to
encode signing-time through 2049 as UTCTime to a "MUST-",
preferably "SHOULD", to promote starting general migration to
GeneralizedTime.
I think we should stay aligned with CMS & PKIX on this. But, I think we
should add that receiving agents must support both UTCTime and
GeneralizedTime.
spt