2.6.7 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 04-Jun-99

Chair(s):

Russ Housley <housley@spyrus.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortel.ca>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:ietf-smime@imc.org
To Subscribe: ietf-smime-request@imc.org
Archive: http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group will define MIME encapsulation of digitally signed and encrypted objects whose format is based on PKCS #7. [1] X.509 Certificates and CRLs as profiled by the existing PKIX Working Group will be used to support authentication and key management. The Working Group will base its work on the S/MIME version 2 specification (available from RSA Data Security), but the Working Group will be free to change any part of that specification. In particular, the Working Group will prepare a new document that allows algorithm independence, based on PKCS #7 1.5.

The message syntax specification, based on PKCS #7 version 1.5, will be expanded to allow additional key signature and key exchange algorithms. The message and certificate specifications will be revised to allow them to become standards. The optional security extensions document will specify protocols that allow for additional security features, such as signed message receipts.

The S/MIME Working Group will attempt to coordinate its efforts with the OpenPGP Working Group in areas where the work of the two groups overlap, particularly in specification of cryptographic algorithms and MIME structure.

[1] RSA Data Security publishes the PKCS Series of documents. RSA Data Security has permitted the IETF to publish them as Informational RFCs as well as to extend and enhance them.

Goals and Milestones:

Nov 97

  

Submit First draft of message syntax specification as an I-D.

Nov 97

  

Submit First draft of S/MIME v3 message specification as an I-D.

Nov 97

  

Submit First draft of S/MIME optional security extensions as an I-D.

Nov 97

  

Submit First draft of S/MIME v3 certificate specification as an I-D

Dec 97

  

WG Last Call on Message Syntax.

Dec 97

  

WG Last Call on Certifiticate Specification.

Dec 97

  

WG Last Call on Message specification.

Jan 98

  

WG Last Call on Optional Security Extensions.

Jan 98

  

Submit Message Syntax I-D to IESG for consideration as a Proposed Standard.

Jan 98

  

Submit S/MIME v3 message specification I-D to IESG for consideration as a Proposed Standard.

Jan 98

  

Submit S/MIME v3 certificate specification I-D to IESG for consideration as a Proposed Standard.

Feb 98

  

Submit S/MIME optional security extensions I-D to IESG for consideration as a Proposed Standard.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2311

  

S/MIME Version 2 Message Specification

RFC2312

  

S/MIME Version 2 Certificate Handling

Current Meeting Report

Minutes of the IETF S/MIME Working Group (WG) meeting held on 15 July 1999 in Oslo, Norway.
All briefing slides are stored at: ftp://ftp.ietf.org/ietf/smime/.
Reported by John Pawling.

Introductions - Russ Housley

Russ reviewed the agenda. It was identical to that publicized prior to the meeting except that the DOMSEC Draft Discussion was cancelled and Russ substituted for several of the presenters who were unable to attend the meeting. Nobody objected to the agenda.

RFC 2630-2634 Status - Russ Housley

The following IETF S/MIME v3 Proposed Standards are available at http://www.ietf.org/rfc/:
- RFC 2630 Cryptographic Message Syntax, R. Housley, June 1999
- RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
- RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
- RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
- RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999

To become Internet Draft Standards, the aforementioned documents must meet the following requirements:
1) Exist as Proposed Standards for 6 months.
2) Each MUST and SHOULD requirement must be implemented by at least two independent implementations such that they are interoperable.

Russ requested that all S/MIME v3 implementors provide a description of the S/MIME v3 features that are supported by their implementation.

Paul Hoffman stated that RFC 2632 is dependent on RFC 2459 (Internet X.509 Public Key Infrastructure Certificate and CRL Profile), so RFC 2632 can not become a Draft Standard until RFC 2459 becomes one. Similarly, RFC 2633 is dependent on RFC 2632 and RFC 2634 is dependent on RFC 2633. Therefore, RFC 2459 must become a Draft Standard before RFC 2632, RFC 2633 or RFC 2634 can become Draft Standards. Paul noted that there are still unresolved issues with RFC 2459. Russ stated that neither RFC 2630 nor RFC 2631 are dependent on the portions of RFC 2459 that are unresolved.

Charter Revision - Russ Housley

Russ reviewed the following proposed changes to the S/MIME WG charter that he had previously sent to the mail list.

Small Subgroup Attacks:

The use of D-H Key Agreement as the mandatory to implement key establishment mechanism may expose some implementations to vulnerabilities based on "small subgroup" attacks. An informational document will be prepared describing techniques that can be used to avoid these attacks.

Proposed Milestones:
History: First "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME" Internet-Draft (I-D) published.
Aug 1999: Last call.
Nov 1999: Submit Informational RFC.

Additional Algorithms

CMS is cryptographic algorithm independent, yet there is always more than one way to use any algorithm. To ensure interoperability, each algorithm should have a specification that describes its use with CMS.

Proposed Milestones:
History: First "CMS KEA and SKIPJACK Conventions" I-D published.
First " Incorporation of IDEA encryption algorithm in S/MIME" I-D published.
Aug 1999: KEA and Skipjack last call.
Nov 1999: KEA and Skipjack Informational RFC.
Dec 1999: IDEA last call.
Mar 2000: IDEA Informational RFC.

CMS and ESS Examples

To aid implementors, documents containing example output for CMS and ESS will be collected and published.

Proposed Milestones:
History: First "Examples of S/MIME Messages" I-D published.
Dec 1999: Last call.
Mar 2000: Informational RFC.

Russ asked that implementors provide interesting invalid cases in addition to valid cases.

CERTDIST

Current methods of publishing certificates in the Directory do not allow the inclusion of secondary support information such as the SMIMECapabilities attribute. A method of publishing certificates along with authenticated secondary support information will be defined.

Proposed Milestones:
History: First "Certificate Distribution Specification" I-D published.
Sep 1999: Last call.
Jan 2000: Proposed Standard RFC.

Password-based Key Management

In some situations it would be advantageous for the CMS RecipientInfo structure to support additional key management techniques, including cryptographic keys derived from passwords. A mechanism to facilitate the definition of additional key management techniques will be defined.

Proposed Milestones:
History: First "Password-based Encryption for S/MIME" I-D published.
Dec 1999: Last call.
Mar 2000: Proposed Standard RFC.

Mail List Key Distribution

S/MIME version 3 supports encrypted mail lists. Specifications for the distribution of symmetric mail list keys to mail list agents (MLAs) and message recipients will be developed. The specification will be cryptographic algorithm independent.

Proposed Milestones:
Sep 1999: First Mail List Key Distribution I-D will be published.
Jan 2000: Last call.
Mar 2000: Proposed Standard RFC.

Russ stated that an editor is needed for this document. He stated that this I-D will document the distribution of pre-placed symmetric keys that can be used to process CMS KEKRecipientInfo. He noted that this capability can be used for purposes other than to support mail lists.

Security Label Usage

S/MIME version 3 supports security labels. Specifications that show how this feature can be used to implement an organizational security policy will be developed. Security policies from large corporations will be used as examples.

Proposed Milestones:
Jul 1999: First Security Label Usage I-D will be published.
Nov 1999: Last call.
Feb 2000: Informational RFC.

DOMSEC

S/MIME version 3 can be used to protect electronic mail to and from a domain. "Domain Security Services" result when the S/MIME v3 processing is performed by message transfer agents, guards or gateways. Mechanisms are needed to solve a number of interoperability problems and technical limitations that arise when domains supporting different security policies wish to interoperate.

Proposed Milestones:
History: First "Domain Security Services using S/MIME" I-D published.
Jul 2000: Last call.
Sep 2000: Experimental RFC.

Sean Turner asked if the proposed charter could be changed to allow I-Ds to be submitted that document environments other than those described in the DOMSEC I-D. Russ stated that he would edit the text in the charter regarding DOMSEC so that it is more generic to allow other I-Ds to be submitted.

Charter Wrap-Up

Russ asked if any attendees knew of any issues, had comments or wished to discuss any related topics. He asked if the attendees believed that the revised charter was ready for the Security Area Directors and IESG.

Paul Hoffman requested that text be added to the charter that allows work to be performed related to adding other options for mandatory-to-implement strong encryption algorithms.

Jim Schaad asked if the WG should consider replacing D-H with RSA as the mandatory-to-implement key management algorithm once the RSA patent expires. Russ added that the RSA patent expires in about a year.

An attendee expressed his opinion that the RSA algorithm should be deprecated from the S/MIME v3 specifications altogether.

Another attendee stated that European software uses the RSA algorithm because the RSA patent doesn't apply outside of the US.

Andrew Farrell requested that the name of the Mail List Key Distribution I-D be changed to "Previously-Distributed Symmetric Keys". Nobody objected.

Paul Hoffman recommended that the WG should consider replacing D-H with RSA as the mandatory-to-implement key management algorithm, but not to associate any milestones with the work.

Russ stated that he will send out a revised draft charter.

Avoiding Small Subgroups - Russ Housley

Robert Zuccherato generated the "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME" I-D. Russ stated that the I-D has not has not been discussed much on the mail list. The WG is obligated to generate this I-D to address the subject vulnerabilities. He strongly recommends that implementors read the I-D so that they are aware of the vulnerabilities. He asked how many attendees have read the I-D. Only 6 people raised their hands. Russ asked that the WG members review and provide comments to the document.

Tony Mione stated a comment to the I-D. Russ asked him to send his comment to the mail list, and he did so. See Tony's 15 July 1999 message sent to the list, subject: "Quick comment on the Small Subgroup Attack draft".

CERTDIST Draft Discussion - Jim Schaad

Jim stated that he has only received comments from Russ to the 25 February 1999 Certificate Distribution (CERTDIST-03) I-D.

CMS/ESS Examples - Paul Hoffman

Paul stated that the following companies have been participating in the generation of the "Examples of S/MIME Messages" I-D: Microsoft, Worldtalk, Baltimore, SPYRUS and J.G. Van Dyke & Associates (VDA). He stated that the June draft includes placeholders for examples from ESS. He requested that the WG members review the I-D and provide comments. He is planning to establish an "Examples" mail list for people to exchange information regarding interoperability testing. The document will include some incorrect examples that flag common implementation errors including explanations of the mistakes. Russ stated that he is especially looking for folks who have implemented the AuthenticatedData, EncryptedData and/or DigestedData content types.

Security Policies and Labels - Russ Housley

Russ stated that Weston Nicolls is developing an I-D that will document the security policies of Whirlpool, Caterpillar and Amoco. The draft will document how the ESSSecurityLabel can be used to implement those corporations' security policies.

S/MIME Freeware Library (SFL) - John Pawling

The SFL is a freeware implementation of RFC 2630 and RFC 2634. It uses the Crypto++ freeware library to implement RFC 2631. It provides functions to support the use of RFC 2632 and RFC 2633. The goal of the SFL is to provide a reference implementation of RFC 2630 and RFC 2634 to encourage their acceptance as Internet Standards. VDA is developing the SFL.

The SFL protects any type of data (not just MIME). It is algorithm independent. It is used with external crypto libraries that provide the crypto algorithms. It uses the VDA-enhanced SNACC freeware library to perform all ASN.1 encoding (including DER) and decoding of CMS and ESS objects as well as certificates, CRLs, etc. All SFL source code is provided (all code is C++).

The SFL implements the optional RFC 2634 security services such as signed receipts, security labels, mail list information, signing certificate attribute and equivalent security labels. It has been used with the RSA BSAFE v3.0 and Crypto++ v3.0 libraries. VDA is currently enhancing the SFL to work with the Fortezza Cryptologic Interface Library and SPYRUS SPEX/ Library.

VDA provides several test utilities along with the SFL including:
- Test driver to build and process a variety of CMS/ESS messages;
- Test utility that processes and displays contents of MIME encoded messages containing single body part or multi-part CMS/ESS components; and
- Test utility to generate key material, certificates (such as D-H) and CRLs.

Version 1.0 SFL was released in June 1999. It was tested on MS Windows 95/NT, Sun Solaris 2.6 and Linux. It was tested using the mandatory and RSA algorithm suites. VDA continues to enhance the SFL.

The SFL has been used to exchange signedData and envelopedData messages with MS Internet Explorer Outlook Express v4.01 and Netscape Communicator 4.X. Signed messages have been exchanged with RSA S/MAIL, WorldTalk and Entrust S/MIME v2 products. S/MIME v3 interoperability testing between SFL and Microsoft includes all envelopedData features such as using Ephemeral-Static D-H pairwise key with 3DES-wrapped and RC2-wrapped content encryption keys. RSA-signed signedData messages have also been exchanged. The majority of the ESS features have been tested. S/MIME v3 interoperability testing also performed with Baltimore, Inc. VDA plans to participate in the IETF S/MIME WG interoperability testing including providing CMS/ESS messages for inclusion in the S/MIME "Examples of S/MIME Messages" document.

Organizations can use the SFL as part of their applications without paying any royalties or licensing fees (see SFL Public License). VDA-enhanced SNACC ASN.1 software and SFL documents are freely available to everyone at: http://www.jgvandyke.com/services/infosec/sfl.htm. All other portions of the SFL are available at: http://www.armadillo.huntsville.al.us/software/smime and are export controlled as per U.S. Government Export Administration Regulations (see: http://www.bxa.doc.gov/Encryption/Default.htm).

The IMC has established an SFL mail list to: distribute information regarding SFL releases; discuss SFL-related issues; and provide a means for SFL users to provide feedback, comments, bug reports, etc. Subscription information for the imc-sfl mailing list is at IMC SFL web page: http://www.imc.org/imc-sfl.

An attendee asked if there was any way that the SFL could be obtained from outside the U.S. John stated that the vendor would need to obtain an export license and referred him to the aforementioned U.S. Government Export Administration Regulations web page. Several attendees then discussed how the SFL could be distributed outside the U.S. such as publishing the source code in a book.

Wrap Up - Russ Housley

None of the attendees had any other comments or issues.

ACTION ITEMS:

1. Tony Mione will send his comment regarding the Avoiding Small Subgroup Attacks I-D to the mail list.
2. ALL S/MIME v3 Implementors: Provide a description to Russ of the S/MIME v3 features that are supported by your software.
3. ALL S/MIME v3 Implementors: Provide valid and invalid sample data to Paul Hoffman for inclusion in the "Examples of S/MIME Messages" I-D.
4. Russ will send the revised charter to the mail list.

Slides

Agenda
S/MIME Working Group Charter Revision
S/MIME Freeware Library
RFC Publication Status