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

Posted related IPR disclosure: Certicom's Statement about IPR related to draft-ietf-tls-rfc4347-bis, draft-rescorla-tls-suiteb, draft-ietf-tls-extractor, draft-green-secsh-ecc, draft-ietf-avt-dtls-srtp, draft-igoe-secsh-suiteb, draft-ietf-smime-3851bis, draft-ietf-smime-3850bis, dra...

Posted related IPR disclosure: Certicom's Statement about IPR related to draft-ietf-smime-3278bis, draft-ietf-smime-sha2, draft-ietf-smime-multisig, draft-ietf-smime-3850bis, draft-ietf-smime-3851bis, draft-igoe-secsh-suiteb, draft-ietf-avt-dtls-srtp, draft-green-secsh-ecc, draft-ie...

[Ballot comment]
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

[Ballot discuss]
Items in the COMMENTS section marked "**" are ones I consider DISCUSS
level, meaning the authors need to come to an understanding with me on
the issue prior to publication.  I leave resolution of the other issues
to the authors.

[Ballot discuss]
It is not clear what are the operational implications of the following statement in Section 1.4:

>    S/MIME version 3.2 agents SHOULD attempt to have the greatest
  interoperability possible with agents for prior versions of S/MIME.

What does 'SHOULD attempt' means from a practical perspective? Is interoprability possible under some conditions and possible in some other situations? Which ones?

[Ballot discuss]
Appendix B recommends moving RFC 2311 (S/MIME version 2) to Historical. I believe that the same recommendation should be extended to RFC 2312 which describes  S/MIME Version 2 Certificate Handling.

[Ballot discuss]
Appendix B recommends moving RFC 2311 (S/MIME version 2) to Hostorical. I believe that the same recommendation should be extended to RFC 2312 which describes  S/MIME Version 2 Certificate Handling.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
changes in the Application Media Types registry at
http://www.iana.org/assignments/media-types/application/

OLD:

application
pkcs7-mime [RFC2311]
pkcs7-signature [RFC2311]

NEW:

application
pkcs7-mime [RFC-smime-3851bis-08]
pkcs7-signature [RFC-smime-3851bis-08]

We understand the above to be the only IANA Action for this document.

Posted related IPR disclosure: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?

Russ Housley is the Document Shepherd.


(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed?

The document is intended for publication as a Proposed Standard.
It has been reviewed by the S/MIME WG, and several key WG members
provided comments. There are no concerns about depth or breadth
of the reviews.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

No concerns.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or
she is uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

No concerns.


(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

No concerns. The two main changes in this doucment were the
algorithms and support key sizes. The WG reached a concensus on
the algorithms and a rough consensus on the key sizes. The rough
consensus on key size was mitigated by updating the security
considerations to address large and small key sizes.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media
type and URI type reviews?

Yes. No problems with ID-Checklist were noticed. ID-Nits did
flag an error, but the reference to the older version was
intentional. There is no need for any formal review from the
MIB Doctors or any other such group.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the strategy for their
completion? Are there normative references that are downward
references, as described in [RFC3967]? If so, list these downward
references to support the Area Director in the Last Call procedure
for them [RFC3967].

References are split.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the
IANA registries clearly identified? If the document creates a new
registry, does it define the proposed initial contents of the
registry and an allocation procedure for future registrations?
Does it suggested a reasonable name for the new registry? See
[RFC5226]. If the document describes an Expert Review process has
the Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during the IESG Evaluation?

The document has an IANA consideration and it is consistent with
the main body of the document. The IANA considerations are intended
to update the protocol registry for application/pkcs7-mime and
application/pkcs7-signauture. Currently, the registry points to
RFC 2311, but RFC 2311 is being moved to historic status (see
Annex B).


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker?

ASN.1 module was compiled by the authors.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document specifies the Secure/Multipurpose Internet Mail
Extensions (S/MIME) version 3.2. It is the third update of the
S/MIME Message Specification (aka S/MIME MSG v3.2) and it will
obsolete RFC 3851, when approved. Note that Annex A recommends
moving RFC 2311, which is S/MIME MSG v2, to historic status.

Working Group Summary

The majority of the S/MIME WG discussion was on what key sizes
and which algorithms to support. The initial proposal included
ECC algorithms as SHOULDs, but they were removed. After removal
of the ECC algorithms, the S/MIME WG quickly reached a concensus
on the algorithms. The key size discussion had two camps "go big"
and "be realistic". The rough consensus is somewhere in the
middle and is supported by widely deployed implementations.

Document Quality

S/MIME has numerous implementations. In fact, many implementations
already support the algorithms and key sizes specied in this
document, with the exception of RSA-PSS and RSA-OAEP.

Personnel

Russ Housley is the document Shepherd.
Tim Polk is the responsible Security Area AD.