Alfred,
Thanks again for the review. Responses inline. In the version I'm about to
post I haven't addressed comment (0) or (29).
All,
Curious what others feel about (0) and (29).
spt
-----Original Message-----
(0) Front Matter / Standards Actions
The draft already indicates in its front matter:
Obsoletes: 3851
During supporting investigations, it became clear that, due to
specific circumstances, this will let us end up with two "valid"
sets of S/MIME specifications -- those for S/MIME v3.2 and
those for S/MIME v2 !
The historic reason for this scenario seems to be buried in
the S/MIME v2 specifications being published as Informational
RFCs and not expressly being Obsoleted by the S/MIME v3 RFCs.
In Section 1.3, this draft lists RFCs 2311 through 2315 as the
documents originally specifying S/MIME v2. In the RFC index,
the entries for all these RFCs list INFORMATIONAL status,
- RFC 2313 is tagged (Obsoleted by RFC2437),
- RFC 2314 is tagged (Obsoleted by RFC2986), but
- RFCs 2311, 2312, and 2315 look like being current.
Arguably, it would be a matter of CMS to take action for RFC
2315, but at least RFC 2311 and RFC 2312 are clearly within
scope of the S/MIME v3.2 drafts.
I suggest to take the opportunity to clean up the RFC metadata
and either:
- also formally Obsolete the S/MIME v2 RFCs with the publication
of the corresponding intended S/MIME v3.2 RFCs,
(i.e. add RFC 2311 to the Obsoletes list of this draft,
add RFC 2312 to the Obsoletes list of [CERT32], and
defer action for RFC 2315 to CMS), or
- to explicitely declare the S/MIME v2 RFCs as Historic in one place.
We should address this one coment (0) and (25) togther seperately.
(14) Section 2.5.3.1
The second bullet there says:
- If an SMIMEEncryptionKeyPreference attribute is not found in a
SignedData object received from the desired recipient, the set of
X.509 certificates SHOULD be searched for a X.509 certificate
| with the same subject name as the signing of a X.509 certificate
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| which can be used for key management.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I really do not understand precisely what the last two lines
want to say. Please clean up and clarify.
(15) Section 2.7.1.2
The visible paragraph structure there is broken; the section
looks like:
If the following two conditions are met:
- ...
- ...
[[end of section]]
More closely looking at the text, it turns out that
fortunately the situation can be cured by inserting a
paragraph break in the second bullet. For grammatical
consistency, also the initial capitalization of the bullets
should be changed.
Thus, the section should be changed to:
If the following two conditions are met:
- the sending agent has no knowledge of the encryption capabilities
of the recipient; and,
- the sending agent has no knowledge of the version of
S/MIME of the
recipient,
then the sending agent SHOULD use AES 128 because it is a stronger
algorithm and is required by S/MIME v3.2. If the sending agent
chooses not to use AES 128 in this step, it SHOULD use tripleDES.
Additionally, the punctuation at the end of the first bullet now could
be easily simplified: s/; and,/, and/
Accepted
(16) Section 3.1 ff. -- terminological issues
Being a designated Standards Track document, the draft should
precisely use established IETF terminology and not
occasionally fall back to common, yet sluggish (ab)use of the
terms regarding the Internet message structure.
Section 3.1.1 of RFC 4249 summarizes the terms established in
the Internet Mail and MIME RFCs, which I will explain again in my own
words:
- at each conceptual protocol layer, a protocol data unit is
comprised of a header and a payload (i.e., the "body" in textual
protocols like email), and sometimes a trailer, as well;
- the header within a protocol layer is comprised of header fields.
Thus, each Internet (email) message has a single message header
(Section 2.1 of I-D.2822-upd now even uses the term "message header
section").
In a structured MIME message body, each nesting level has a single
"MIME header", "MIME entity header", or "MIME part header" of its
own (cf. RFC 2045).
(We are not interested in lower level details, like MIME prologue
and epilogue, etc., for the purpose of this draft.)
Each message header or MIME header is comprised of header fields,
with in turn consist of a field name, the colon separator, and a
field value.
At the MIME top level, the MIME-related header fields are
integrated in the RFC[2]822 message header; they sometimes
collectively are denoted as the "MIME message header".
Furthermore, as explained in BCP 13, RFC 4288, the IETF should
not use the popular term "MIME type", in favor of "media type".
The former had not even been defined in [MIME-SPEC], and it
has become even more misleading with the spread of other
protocols making use of these media types.
I strongly recommend to update the draft to always use this
precise terminology.
As a side-show, I also recommend consistently using the same
spelling and capitalization for header field names --
preferably the spelling and case used in the original document
defining the header field --, e.g., replace "content type" and
"Content type" by "Content-Type".
Because there are some subtle cases, I try to address most
affected instances of these issues I found in the draft text
in detail below.
Agree
(17) Section 3.1 -- details
(17a) 1st paragraph
Applying the rationale of (16), I suggest to change (also
deleting the repeated second "used" near the end of the third
sentence, to streamline the language a bit):
S/MIME is used to secure MIME entities. A MIME entity can be a sub-
part, sub-parts of a message, or the whole message with all its sub-
parts. A MIME entity that is the whole message includes only the
| MIME headers and MIME body, and does not include the
RFC-822 headers.
^ ^ vvvvvv ^
| Note that S/MIME can also be used to secure MIME entities used in
applications other than Internet mail. If protection of the RFC-822
| headers is required, the use of the message/rfc822 MIME type is
explained later in this section.
--- ^^^^
S/MIME is used to secure MIME entities. A MIME entity can be a sub-
part, sub-parts of a message, or the whole message with all its sub-
parts. A MIME entity that is the whole message includes only the
| MIME message headers and MIME body, and does not include
the RFC-822
| header. Note that S/MIME can also be used to secure MIME entities in
applications other than Internet mail. If protection of the RFC-822
| header is required, the use of the message/rfc822 media type is
explained later in this section.
Accepted
(17b) 1st paragraph below 'Step 3.'
Please remove the comma after "where" -- or put it in front of
that "where".
Deleted the comma
(17c) 2nd paragraph below 'Step 3.'
Correcting a typo and applying (16), I suggest to change:
| In order to protect outer, non-content related message headers (for
v v ^^^^^^^
| nstance, the "Subject", "To", "From" and "CC" fields), the sending
client MAY wrap a full MIME message in a message/rfc822 wrapper in
| order to apply S/MIME security services to these headers. It is up
^^^^^^^
| to the receiving client to decide how to present these "inner"
^^^^^
| headers along with the unprotected "outer" headers.
--- ^ ^
| In order to protect outer, non-content related message
header fields
| (for instance, the "Subject", "To", "From" and "Cc" fields), the
sending client MAY wrap a full MIME message in a message/rfc822
| wrapper in order to apply S/MIME security services to these header
| fields. It is up to the receiving client to decide how to present
| this "inner" header along with the unprotected "outer" header.
Accepted
(18) Section 3.1.1, 2nd paragraph
According to (16), please s/MIME type/media type/ (2x).
I only found one.
(19) Section 3.1.2
According to (16):
[...] If no Content-Transfer-Encoding header is
present, the transfer encoding is presumed to be 7BIT.
--- vvvvvv
| [...] If no Content-Transfer-Encoding
header field is
present, the transfer encoding is presumed to be 7BIT.
Accepted
(20) Section 3.1.4
The legacy example of BITNET seems to be rather aged and of
very low interest -- if any; cf. http://en.wikipedia.org/wiki/BITNET .
I therefore suggest to simply delete " (like BITNET)"
While aged it is part of an example so I think we can leave it.
(21) Section 3.2
(21a) section title
For added precision and consistency, I suggest to add "Media"
in front of "Type" -- cf. 3.4.3.1, discussed in (2x) below:
3.2. The application/pkcs7-mime Type
---
3.2. The application/pkcs7-mime Media Type
Accepted
(21b) 3rd paragraph
According to (16), please s/MIME type/media type/ (1x).
(21c) last paragraph
For added precision, and with respect to (16), the last
sentence should be amended:
| [...]. The MIME headers of all
application/pkcs7-mime objects SHOULD include the optional "smime-
type" parameter, as described in the following sections.
---
| [...]. The Content-Type header
| field of all application/pkcs7-mime objects SHOULD include the
optional "smime-type" parameter, as described in the following
sections.
Accepted
(22) Section 3.2.1, last paragraph
According to (16), please s/MIME type/media type/ (1x), and
s/MIME types/media types/ (1x).
Fixed
(23) Section 3.2.2, last numbered bullet
Please correct punctuation and case:
vvvv
| 3. If no common string is assigned. Then the common string of
"OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1"
would be DES40).
--- vvv
| 3. If no common string is assigned, then the common string of
"OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1"
would be DES40).
Accepted
(24) Section 3.4.3
According to (16), please s/MIME type/media type/ (2x).
Fixed
(25) Section 3.4.3.1
(25a) section title
With respect to (16) please change:
3.4.3.1. The application/pkcs7-signature MIME Type
---
3.4.3.1. The application/pkcs7-signature Media Type
^^^^^
(25b) 1st paragraph
According to (16), please s/MIME type/media type/ (1x).
Accepted
(26) Section 3.4.3.2
(26a) 1st paragraph below 'Step 5'
Please adjust:
vv
| The multipart/signed Content type has two required parameters: the
protocol parameter and the micalg parameter.
--- vv
| The multipart/signed Content-Type has two required parameters: the
protocol parameter and the micalg parameter.
Accepted
(26b) last paragraph:
The draft says:
| The SHA-224 algorithm [SHA224] and SHA-384 and SHA-512 algorithms
[FIPS180-3] are not currently recommended in S/MIME, and
are included
here for completeness.
There's an apparent disparity. SHA-224 is also covered by
FIPS 180-3, and SHA-384 as well as SHA-512 are also covered by
RFC 4634 not even listed as a Reference. Perhaps this has
historical reasonse related to the delayed introduction of
SHA-224 via a Change Notice to FIPS 180-2.
Since the requirements statement is "not recommended", adding
a bulk of references might be overkill; the basic Ref. should suffice.
Thus, I suggest to drop [SHA224] and simplify the language:
| The SHA-224, SHA-384, and SHA-512 algorithms [FIPS180-3] are not
currently recommended in S/MIME, and are included here for
completeness.
Accepted and I deleted the [SHA224] reference
(27) Setcion 3.9
(27a) 2nd paragraph
According to (16), please change:
The file suffix in the table below comes from the "name"
parameter in
| the content-type header, or the "filename" parameter on the content-
v ^ ^ vv ^^ ^
| disposition header. These parameters that give the file suffix are
not listed below as part of the parameter section.
---
The file suffix in the table below comes from the "name"
parameter in
| the Content-Type header field, or the "filename" parameter on the
| Content-Disposition header field. These parameters that give the
file suffix are not listed below as part of the parameter section.
Accepted
(27b) table
According to (16), please s/MIME type/media type/ (3x).
Accepted
(28) Section 4.1
The draft says:
All generated key pairs MUST be generated from a good source of non-
deterministic random input [RANDOM] and the private key MUST be
protected in a secure fashion.
IMO, this 'MUST' requirement constitutes a *Normative*
Reference; so please promote '[RANDOM]' to Normative, moving
the entry from
B.2 to B.1.
Agreed
(29) Section 5
Independent on the decision to be made regarding (0) above,
this section needs to be amended.
(29a) Scenario 1: RFC 2311 *not* Obsoleted / made HISTORIC
In this case, IANA should at least be directed to update the
media type registrations for
"application/pkcs7-mime"
and
"application/pkcs7-signature"
by adding an additional reference to [RFCTHIS], in order to
point the reader to the most current update of the media type
information.
On the other hand, updating an old media type's information
arguably could require updating the registration entirely,
using the new registration template from BCP 13, RFC 4288.
I leave it to the high priests of exegesis (or lawyers) to
figure out whether RFC 4288 in fact even normatively requests to do so.
(29b) Scenario 2: RFC 2311 beinf Obsoleted or made HISTORIC
In this case, the draft should substantially be amended with
the two new media type registration templates, filled for both
media types, "application/pkcs7-mime" and
"application/pkcs7-signature", and IANA should be directed to
update the registrations to incorporate this new information.
Address this with (0).
(30) Section 6, 7th paragraph
I suggest to make the statement on key size more specific
(again, to not interfere with the future addition of other
signing algorithms having other key size requirements), and to
correct the placement of hyphens, as follows:
Some S/MIME agents created in the United States have chosen
to create
| 512 bit keys in order to get more advantageous export licenses.
| However, 512 bit keys are considered by many to be cryptographically
insecure.
---
Some S/MIME agents created in the United States have chosen
to create
| 512-bit RSA keys in order to get more advantageous export licenses.
^ ^^^^ v vvvv
| However, 512-bit RSA keys are considered by many to be
cryptographically insecure.
This paragraph got overtaken by events.
(31) Appendix A
(31a) general
At first glance, it comes to surprise that there's a "~~V3dot1"
ASN.1 module.
For clarity, I suggest adding an introductory statement
indicating that this module has been taken essentially
unchanged from RFC 3851 and still applies to S/MIME v3.2.
Since there are no changes listed in Section 1.6 it would be clear but I
added the NOTE anyway and the corresponding informative reference to MSG3.1.
(31b) ASN.1 comment below id-cap OID definition
I suggest to improve the language a bit, by inserting "OID":
-- The preferBinaryInside indicates an ability to receive messages
-- with binary encoding inside the CMS wrapper
--- vvvvv
-- The preferBinaryInside OID indicates an ability to receive
-- messages with binary encoding inside the CMS wrapper.
Accepted
(32) Appendix B
[ Interestingly, the last item for v3.2 happens to be #32 :-) ]
(32a) section numbering
The RFC Editor prefers References as a numbered section, not
as an Appendix. Therefore, I suggest to shuffle the
Appendices and turn this one into Section 7.
I guess I'm going to leave this one alone like I did in 3850bis.
(32b) B.1, [FIPS180-3] { oooops }
vvvvvvvvvvv
[FIPS180-3] "Secure Hash Signature Standard (SHS)", National
Institute of Standards and Technology (NIST). FIPS
Publication 180-3.
---
| [FIPS180-3] "Secure Hash Standard (SHS)", National Institute of
Standards and Technology (NIST), FIPS Publication
| 180-3, June 2007.
^^^^^^^^^^^
or better, listing the source first (as also done for ITU-T documents):
| [FIPS180-3] National Institute of Standards and Technology (NIST),
| "Secure Hash Standard (SHS)", FIPS Publication 180-3,
| June 2007.
Fixed
(32c) B.2, [RANDOM]
Please add "BCP 106, " in front of "RFC 4086".
regarding eventual promotion to Normative, please see item (28) above.
Fixed