2.5.8 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00

Chair(s):

Russ Housley <housley@spyrus.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>

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 has completed five Proposed Standards that comprise the S/MIME version 3 specification. Current efforts build on these base specifications.

The use of Diffie-Hellman 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.

The Cryptographic Message Syntax (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. Specifications for the use of additional cryptographic algorithms will be developed. An additional suite of 'mandatory to implement' algorithms may be selected.

To aid implementers, documents containing example output for CMS will be collected and published. Some of the examples will include structures and signed attributed defined in the Enhanced Security Services (ESS) document.

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.

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. S/MIME version 3 permits the use of previously distributed symmetric key-encryption keys. Specifications for the distribution of symmetric key-encryption keys to mmultiple message recipients will be developed. Mail List Agents (MLAs) are one user of symmetric key-encryption keys. The specification will be cryptographic algorithm independent.

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 organizations will be used as examples.

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

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.

Goals and Milestones:

Jul 99

  

First draft of CMS RecipientInfo extension.

Jul 99

  

First draft of security label usage specification.

Aug 99

  

Last call on small subgroup attack avoidance

Aug 99

  

First draft of CAST algorithm specification.

Aug 99

  

Last call on KEA and SKIPJACK algorithm specification.

Sep 99

  

First draft of mail list key distribution.

Sep 99

  

Last call on certificate distribution specification.

Nov 99

  

Updated draft of domain security services document.

Nov 99

  

Last call on security label usage specification.

Nov 99

  

Last call on CAST algorithm specification.

Nov 99

  

Submit small subgroup attack avoidance as Informational RFC

Nov 99

  

Submit KEA and SKIPJACK algorithm specification as Informational RFC.

Dec 99

  

Last call on IDEA algorithm specification.

Dec 99

  

Last call on CMS and ESS examples document.

Dec 99

  

Last call on CMS RecipientInfo extension.

Jan 00

  

Last call on mail list key distribution.

Jan 00

  

Submit certificate distribution specification to IESG for consideration as a Proposed Standard.

Feb 00

  

Submit CAST algorithm specification as Informational RFC.

Feb 00

  

Submit security label usage specification as Informational RFC.

Mar 00

  

Submit CMS and ESS examples document as Informational RFC.

Mar 00

  

Submit CMS RecipientInfo extension to IESG for consideration as a Proposed Standard.

Mar 00

  

Submit IDEA algorithm specification as Informational RFC.

Mar 00

  

Submit mail list key distribution to IESG for consideration as a Proposed Standard.

Jul 00

  

Last call on domain security services document.

Sep 00

  

Submit domain security services as Experimental RFC.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2311

 

S/MIME Version 2 Message Specification

RFC2312

 

S/MIME Version 2 Certificate Handling

RFC2630

PS

Cryptographic Message Syntax

RFC2631

PS

Diffie-Hellman Key Agreement Method

RFC2632

PS

S/MIME Version 3 Certificate Handling

RFC2633

PS

S/MIME Version 3 Message Specification

RFC2634

PS

Enhanced Security Services for S/MIME

RFC2785

 

Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME

RFC2876

 

Use of the KEA and SKIPJACK Algorithms in CMS

Current Meeting Report

None received.

Slides

Agenda
Electronic Signature Formats for Long Term Electronic Signatures
Electronic Signature Policies
Interoperability Matrix
SMIME Working Group Status
SMIME Symmetric Key Distribution