Skip to main content

Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling
draft-ietf-smime-3850bis-11

Revision differences

Document history

Date Rev. By Action
2015-10-14
11 (System) Notify list changed from smime-chairs@ietf.org, draft-ietf-smime-3850bis@ietf.org to (None)
2012-08-22
11 (System) post-migration administrative database adjustment to the Yes position for Chris Newman
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2010-01-25
11 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2010-01-25
11 Cindy Morgan [Note]: 'RFC 5750' added by Cindy Morgan
2010-01-25
11 (System) RFC published
2009-05-27
(System)
2009-05-18
(System)
2009-05-15
11 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-05-14
11 (System) IANA Action state changed to No IC from In Progress
2009-05-14
11 (System) IANA Action state changed to In Progress
2009-05-14
11 Amy Vezza IESG state changed to Approved-announcement sent
2009-05-14
11 Amy Vezza IESG has approved the document
2009-05-14
11 Amy Vezza Closed "Approve" ballot
2009-05-14
11 (System) New version available: draft-ietf-smime-3850bis-11.txt
2009-04-27
10 (System) New version available: draft-ietf-smime-3850bis-10.txt
2009-04-14
09 (System) New version available: draft-ietf-smime-3850bis-09.txt
2009-04-02
11 Tim Polk State Changes to IESG Evaluation::External Party from IESG Evaluation::Revised ID Needed by Tim Polk
2009-04-02
11 Tim Polk waiting for wg to confirm AD-requested changes on key sizes
2009-04-02
11 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2009-03-25
11 Chris Newman [Ballot Position Update] Position for Chris Newman has been changed to Yes from Discuss by Chris Newman
2009-03-24
11 Chris Newman
[Ballot discuss]
Updating on 2009-03-24 based on current RFC editor notes.

All issues except this one have been resolved:

Section 3:

>  End-entity certificates MAY …
[Ballot discuss]
Updating on 2009-03-24 based on current RFC editor notes.

All issues except this one have been resolved:

Section 3:

>  End-entity certificates MAY contain an Internet mail address as
>  described in [IMF].  The address must be an "addr-spec" as defined in
>  Section 3.4.1 of that specification.

This should be made consistent with RFC 5280, section 4.2.1.6.  The
reference to IMF addr-spec is incorrect as that ABNF allows
linear-white-space; the RFC 5321 "Mailbox" ABNF does not allow
linear-white-space.
2009-01-08
11 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead by Cindy Morgan
2009-01-08
11 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2009-01-08
11 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2009-01-08
11 Jari Arkko [Ballot comment]
Diffs to RFC 3850 can be found from:
http://arkko.com/ietf/smime/draft-ietf-smime-3850bis-08-from-rfc3850.diff.html
2009-01-08
11 Chris Newman
[Ballot discuss]
Section 3:

>  End-entity certificates MAY contain an Internet mail address as
>  described in [IMF].  The address must be an "addr-spec" as …
[Ballot discuss]
Section 3:

>  End-entity certificates MAY contain an Internet mail address as
>  described in [IMF].  The address must be an "addr-spec" as defined in
>  Section 3.4.1 of that specification.

This should be made consistent with RFC 5280, section 4.2.1.6.  The
reference to IMF addr-spec is incorrect as that ABNF allows
linear-white-space; the RFC 5321 "Mailbox" ABNF does not allow
linear-white-space.

>  ...  Receiving agents MUST check that the address in the
>  From or Sender header of a mail message matches an Internet mail
>  address, if present, in the signer's certificate, if mail addresses
>  are present in the certificate.

This does not does describe the algorithm for this check.  I'm not aware
of any RFC which documents the algorithm for comparing if two mail
addresses are the same.  The S/MIME implementation in my mail client
regularly fails this check incorrectly because the domain name has had
the case altered by an MTA and it does an octet-based comparison.  In
addition, what happens if the From or Sender header has different
linear-white-space from the address in the cert?

Because this algorithm is not specified, the present specification
creates a situation where fully complaint implementations and
deployments of this specification fail to interoperate.

The algorithm would be (roughly):
1. The recipient uses the address from the Sender header if it is
present.  If the Sender header is not present, the address in the From
header is used.
2. The header address is unfolded and linear-white-space is removed.
3. The local part (left hand side) of the address is compared using a
case-sensitive comparison.  The domain part (right hand side) is
compared using a US-ASCII case-insensitive comparision (upper and lower
case letters are considered equivalent).

RFC 5335 addresses can't appear in subjectAltName presently.  To verify
an address from an RFC 5335 message header, there is a step 2.5 to
down-convert the domain portion of the header address per RFC 3490 prior
to comparison.  No need to mention this if you don't want to as 5335 is
experimental, I'm just pointing it out for completeness.

Section 4.4.3

>  preferred means to convey the RFC-2822 email address(es) that

The RFC 2822 reference is obsolete.  I suggest simply removing "RFC-2822" every place it occurs, and adding a pointer to [KEYM] so this section would then read:

  The subject alternative name extension is used in S/MIME as the
  preferred means to convey the email address(es) that
  correspond(s) to the entity for this certificate.  Any email
  addresses present MUST be encoded using the rfc822Name CHOICE of the
  GeneralName type as described in [KEYM] section 4.2.1.6.  Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple email
  addresses MAY be present.
2009-01-08
11 Chris Newman [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman
2009-01-08
11 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2009-01-08
11 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2009-01-07
11 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-01-07
11 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2009-01-06
11 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-01-06
11 Dan Romascanu
[Ballot comment]
The text in 1.3 should use a capitalized SHOULD:

> S/MIME version 3.2 agents should attempt to have the greatest
  interoperability possible …
[Ballot comment]
The text in 1.3 should use a capitalized SHOULD:

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

This would also be consistent with the similar text in draft-ietf-smime-3851bis-08.txt
2009-01-06
11 Dan Romascanu
[Ballot discuss]
I have a similar question as the one relative to draft-ietf-smime-3851bis-08.txt. It is not clear what are the operational implications of the following …
[Ballot discuss]
I have a similar question as the one relative to draft-ietf-smime-3851bis-08.txt. It is not clear what are the operational implications of the following statement in Section 1.3:

>    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 interoperability possible under some conditions and possible in some other situations? Which ones?
2009-01-06
11 Dan Romascanu
[Ballot discuss]
I have a similar question as the one relative to draft-ietf-smime-3851bis-08.txt. It is not clear what are the operational implications of the following …
[Ballot discuss]
I have a similar question as the one relative to draft-ietf-smime-3851bis-08.txt. It is not clear what are the operational implications of the following statement in Section 1.3:

>    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?
2009-01-06
11 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2009-01-05
11 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-12-17
11 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-12-16
11 Tim Polk Telechat date was changed to 2009-01-08 from 2008-12-18 by Tim Polk
2008-12-16
11 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2008-12-12
11 Russ Housley [Ballot Position Update] New position, Yes, has been recorded by Russ Housley
2008-12-06
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Nicolas Williams
2008-12-06
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Nicolas Williams
2008-12-06
11 Samuel Weiler Assignment of request for Last Call review by SECDIR to Sam Hartman was rejected
2008-11-19
11 Tim Polk [Ballot Position Update] New position, Yes, has been recorded for Tim Polk
2008-11-19
11 Tim Polk Ballot has been issued by Tim Polk
2008-11-19
11 Tim Polk Created "Approve" ballot
2008-11-19
11 Tim Polk Telechat date was changed to 2008-12-18 from 2008-12-11 by Tim Polk
2008-11-18
11 Tim Polk Placed on agenda for telechat - 2008-12-11 by Tim Polk
2008-11-13
11 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-11-11
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Hartman
2008-11-11
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Hartman
2008-11-10
11 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand
this document to have NO IANA Actions.
2008-10-30
11 Cindy Morgan Last call sent
2008-10-30
11 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2008-10-30
11 Tim Polk State Changes to Last Call Requested from Publication Requested by Tim Polk
2008-10-30
11 Tim Polk Last Call was requested by Tim Polk
2008-10-30
11 (System) Ballot writeup text was added
2008-10-30
11 (System) Last call text was added
2008-10-30
11 (System) Ballot approval text was added
2008-10-30
(System)
Posted related IPR disclosure: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, …
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...
2008-10-06
11 Cindy Morgan

(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 …

(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?

There are no IANA considerations.


(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?

No formal language is used.


(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 conventions for X.509 certificates
for use with S/MIME agents. It is the third update of the S/MIME
Certificate Handling specification (aka S/MIME CERT v3.2) and it
will obsolete RFC 3850, when approved. Note that Annex A
recommends moving RFC2312, which is S/MIME CERT 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.

Personnel

Russ Housley is the document Shepherd.
Tim Polk is the responsible Security Area AD.
2008-10-06
11 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-10-06
08 (System) New version available: draft-ietf-smime-3850bis-08.txt
2008-09-26
07 (System) New version available: draft-ietf-smime-3850bis-07.txt
2008-09-22
06 (System) New version available: draft-ietf-smime-3850bis-06.txt
2008-08-21
05 (System) New version available: draft-ietf-smime-3850bis-05.txt
2008-07-01
04 (System) New version available: draft-ietf-smime-3850bis-04.txt
2008-06-04
03 (System) New version available: draft-ietf-smime-3850bis-03.txt
2008-05-12
02 (System) New version available: draft-ietf-smime-3850bis-02.txt
2008-02-21
01 (System) New version available: draft-ietf-smime-3850bis-01.txt
2007-11-08
00 (System) New version available: draft-ietf-smime-3850bis-00.txt