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) | 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 … 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... |
|
|
2009-05-18
|
(System) | 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 … 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... |
|
|
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) | ||
|
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 |