Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
draft-ietf-smime-3851bis-11

Section 2.5.1

>   Sending agents MUST encode signing time through the year 2049 as 
>   UTCTime; signing times in 2050 or later MUST be encoded as 
>   GeneralizedTime.  When the UTCTime CHOICE is used, S/MIME agents MUST 
                   ^^   
** I suggest the following text be added here:

  "The optional time zone offset component of UTCTime and
   GeneralizedTime MUST be included by sending agents."

(see RFC 3339 section 4.4 for the reason)

Section 3.1.1

>   [MIME-SPEC].  The chosen charset SHOULD be named in the charset 
>   parameter so that the receiving agent can unambiguously determine the 
>   charset used.

Why is this a SHOULD rather than a MUST?  Perhaps the intent was to say
``If the chosen charset is not "us-ascii", it MUST be named in the
charset parameter so that the receiving agent ...''

Section 3.2.2

>   It is explicitly intended that this field be a suitable hint for mail 
>   client applications to indicate whether a message is "signed" or 
>   "encrypted" without having to tunnel into the CMS payload. 

** Important security consideration: The mere presence of a message
flagged by a user interface as "signed" or "encrypted" from a
particularly important sender in a message list view can have security
implications.  For example, if a military communications officer
receives a message with subject "change in orders" from the general that
is flagged as signed in the user interface, this may cause the officer
to interrupt another critical officer to view the message which may then
turn out to be a forgery.  Clients which display this hint in a user
interface MUST provide an administrative option to ignore the hint and
only display an indication that a message is signed/secure if the
signature has actually been verified as valid.

Section 3.4.3.2

** These textual names disagree with the names in the IANA "Hash
Function Textual Names" registry.  I think that is unfortunate, but
presume it is historical.  I would like that to not happen for future
hash function names.  I suggest text similar to the following:

  Some of these hash function names are different from the names in the
  IANA "Hash Function Textual Names" registry.  Receiving agents SHOULD
  also support the names in that registry.  Future names for this
  parameter will be consistent with those in that registry.

  http://www.iana.org/assignments/hash-function-text-names/

Question for IESG/authors: should this document register "unknown" or
suggest an "x-" naming convention?

Section 5.1

** As you recommend generation of a "name" parameter for this media
type, it needs to be listed in the registration template as an optional
parameter.

Section 6

>   This specification uses Public-Key Cryptography technologies.  It is 
>   assumed that the private is protected to ensure that it is not 
                            ^
                            key