----- Forwarded message from Alfred Hönes -----
From A(_dot_)Hoenes(_at_)TR-Sys(_dot_)de Mon May 19 11:21:42 MES 2008
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3)
id AA254648901; Mon, 19 May 2008 11:21:41 +0200
Return-Path: <A(_dot_)Hoenes(_at_)TR-Sys(_dot_)de>
Received: (from ah(_at_)localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)
id LAA12918; Mon, 19 May 2008 11:21:38 +0200 (MESZ)
From: Alfred Hönes <ah(_at_)TR-Sys(_dot_)de>
To: blake(_at_)sendmail(_dot_)com, turners(_at_)ieca(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
Message-Id: <200805190921(_dot_)LAA12918(_at_)TR-Sys(_dot_)de>
Date: Mon, 19 May 2008 11:21:38 +0200 (MESZ)
Subject: draft-ietf-smime-3851bis-02 (notes, part 1)
Hello,
I would like to also submit a few comments on your Internet-Draft,
draft-ietf-smime-3851bis-02.
Due to time constraints, I have decided to split the intended
comments. This is the first part addressing the initial sections
of the draft, up to section 2.5.1; more will follow ASAP.
(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.
- The comments I sent on the same part of draft-ietf-smime-3850bis-02
also apply.
(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.
(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".
(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".
(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.
- "content type applications" seems to be vague and unclear.
I suggest to use "content type specific applications" or
"content type based applications" instead
(4b) 2ns and 3rd paragraph
Please apply (3) -- 3 occurrences.
(5) Section 1.3
For clarity, please add another comma after the first instance of
"inclusive", or place this word in parentheses.
(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
(6b) last two paragraphs
Please apply (3) -- two occurrences.
(7) Section 1.5 -- typo
Please replace "in parantheticals" by either "parenthetical" or
"in parenthesis".
(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.
(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.
(9) Section 2.3
Please replace
using rsaEncryption algorithm.
by either:
using the rsaEncryption algorithm.
or:
using rsaEncryption.
(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 ...
(11) Section 2.4.4, 1st paragraph
I suggest to insert the article "the" giving "reduce the message size".
(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.
^
(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.
^^^^^^^
(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.
Kind regards,
Alfred Hönes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah(_at_)TR-Sys(_dot_)de
|
+------------------------+--------------------------------------------+
----- End of forwarded message from Alfred Hönes -----