2.6.9 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-23

Russell Housley <housley@vigilsec.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Steven Bellovin <smb@research.att.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 a series of Proposed Standards that comprise the S/MIME version 3 specification. Current efforts update and build upon these base specifications.

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.

As part of the specification update, a new suite of "mandatory to implement" algorithms will be selected. These algorithms will be reflected in updates to RFC 2632 and RFC 2633.

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

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

Compressing data prior to encryption or signature has a number of advantages. Compression improves security by removing known data patterns, improves throughput by reducing the amount of data which needs to be encrypted or hashed, and reduces the overall message size. Enabling S/MIME version 3 to use compression will provide all of these advantages.

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

As part of S/MIME version 3, CMS is used to provide security to the message content. CMS can also be employed in an X.400 electronic messaging envionments. Specifications will be developed allowing this to be done in an interoperable manner.

Perform necessary interoperability testing to progress the S/MIME version 3 specifications to Draft Standard. Due to the dependency of the CMS specification on the PKIX certificate and CRL profile, the timeline for the actual progression is impossible to estimate.

Goals and Milestones:
Done  First draft of security label usage specification.
Done  First draft of CMS RecipientInfo extension.
Done  Last call on KEA and SKIPJACK algorithm specification.
Done  Last call on small subgroup attack avoidance
Done  First draft of CAST algorithm specification.
Done  Last call on certificate distribution specification.
Done  First draft of mail list key distribution.
Done  Submit KEA and SKIPJACK algorithm specification as Informational RFC.
Done  Submit small subgroup attack avoidance as Informational RFC
Done  Last call on CAST algorithm specification.
Done  Updated draft of domain security services document.
Done  Last call on security label usage specification.
Done  Last call on IDEA algorithm specification.
Done  Last call on CMS RecipientInfo extension.
Done  Last call on mail list key distribution.
Done  Submit CAST algorithm specification as Informational RFC.
Done  Submit security label usage specification as Informational RFC.
MAR 00  Submit mail list key distribution to IESG for consideration as a Proposed Standard.
Done  Submit IDEA algorithm specification as Informational RFC.
Done  Submit CMS RecipientInfo extension to IESG for consideration as a Proposed Standard.
Done  Last call on domain security services document.
Done  Submit domain security services as Experimental RFC.
AUG 02  Last call on CMS and ESS examples document.
SEP 02  Submit CMS and ESS examples document as Informational RFC
OCT 02  Sumbit update to RFC 2633 as Proposed Standard
OCT 02  Sumbit update to RFC 2632 as Proposed Standard
OCT 02  Last call on RSA PSS algorithm specification
NOV 02  Last call on RSA KEM algorithm specification
DEC 02  Sumbit AES algorithm specification as Proposed Standard
DEC 02  Submit RSA OAEP algorithm specification as Proposed Standard
JAN 03  Submit RSA PSS algorithm specification as Proposed Standard
FEB 03  Submit RSA KEM algorithm specification as Proposed Standard
  • - draft-ietf-smime-examples-09.txt
  • - draft-ietf-smime-symkeydist-09.txt
  • - draft-ietf-smime-cms-rsaes-oaep-07.txt
  • - draft-ietf-smime-x400transport-05.txt
  • - draft-ietf-smime-x400wrap-05.txt
  • - draft-ietf-smime-aes-alg-06.txt
  • - draft-ietf-smime-hmac-key-wrap-01.txt
  • - draft-ietf-smime-rfc2632bis-03.txt
  • - draft-ietf-smime-rfc2633bis-03.txt
  • - draft-ietf-smime-camellia-01.txt
  • - draft-ietf-smime-pss-00.txt
  • Request For Comments:
    RFC2311 I S/MIME Version 2 Message Specification
    RFC2312 I 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 I Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME
    RFC2876 I Use of the KEA and SKIPJACK Algorithms in CMS
    RFC2984 PS Use of the CAST-128 Encryption Algorithm in CMS
    RFC3058 I Use of the IDEA Encryption Algorithm in CMS
    RFC3125 E Electronic Signature Policies
    RFC3183 E Domain Security Services using S/MIME
    RFC3126 I Electronic Signature Formats for long term electronic signatures
    RFC3185 PS Reuse of CMS Content Encryption Keys
    RFC3217 I Triple-DES and RC2 Key Wrapping
    RFC3211 PS Password-based Encryption for SMS
    RFC3218 I Preventing the Million Message Attack on CMS
    RFC3278 I Use of ECC Algorithms in CMS
    RFC3274 PS Compressed Data Content Type for Cryptographic Message Syntax (CMS)
    RFC3369 PS Cryptographic Message Syntax
    RFC3370 PS Cryptographic Message Syntax (CMS) Algorithms
    RFC3394 I Advanced Encryption Standard (AES) Key Wrap Algorithm
    RFC3114 I Implementing Company Classification Policy with the S/MIME Security Label

    Current Meeting Report

    Here are the minutes for the San Francisco meeting. Cheers - spt
    Minutes for the S/MIME Meeting
    IETF 56
    March 18, 2003
    Agenda:  Russ Housley covered the agenda for the meeting.  No changes were 
    Working Group Status:  Russ Housley covered the status of the active 
    documents in the working group.  The documents that have changed status 
    since the last meeting are:
    Published as an RFC:
    - RFC 3394 Advanced Encryption Standard (AES) Key Wrap Algorithm.
    RFC Editors Queue:
    - symkeydist CMS Symmetric Key Management and Distribution
    With the IESG:
    - Use of the RSAES-OAEP Transport Algorithm in CMS
    - Transporting S/MIME Objects in X.400
    - Securing X.400 Content with S/MIME
    - Wrapping an HMAC key with a Triple-DES Key or an AES Key
    - Use of the AES Encryption Algorithm in CMS.
    Progression to Draft Standard:  Need to have two interoperable 
    implementations (see report below) and all referenced documents advance to 
    Draft Standard.  For CMS to advance this means RFC 3280 
    (Certificate Profile) and RFC 3281 (V2 Attribute Certificate Profile) need to 
    advance first.
    Russ then resigned as the chair of the S/MIME working group due to his 
    promotion to the position of Security Area Director on the IESG.  The new 
    co-chairs of the working group are Blake Ramsdell 
    (blake@brutesquadlabs.com) and Sean Turner 
    (turners@ieca.com).  Blake and Sean chaired the balance of the meeting.
    Message Update and Certificate Update Drafts:  Blake Ramsdell gave a 
    presentation on the progress of these two documents.  The message draft has 
    had a number of small changes between the -02 and -03 drafts.  The 
    document was put into working group last call after the last meeting. The 
    comments on the list have not yet been incorporated into a published draft 
    but that should be done soon.  The certificate draft has had some minor 
    changes in the extended key usage description and should go into working 
    group last call in the near future.
    Examples Draft:  Paul Hoffman said that there have been some new 
    examples submitted for the draft; however these contained some personal 
    email addresses so Paul has asked that they be regenerated.  Areas of the 
    document that do not currently have examples have been removed. When the new 
    examples are placed in the document it should be ready for working group 
    last call.
    CMS Interoperability Status:  Jim Schaad stated that advancement has been 
    made since the last meeting for CMS interoperability.  Four items need to be 
    tested, but implementers have been found for SignedData.  The document 
    describing the results of the interoperability testing has been 
    started.  This document should be ready for publishing before the next 
    meeting.  During the process of developing the matrix an error was 
    discovered in the CMS ASN.1 module, an update has been submitted to the RFC 
    Editor to supply the missing OIDs from the module.  Eventually, an update to 
    the RFC will be needed, perhaps when the document progresses to Draft 
    RSA PSS: Jim Schaad presented two issues with the RSA PSS draft. The first 
    dealt with whether the key identifier and signature identifier should use 
    the existing OIDs or whether new ones should be assigned. The second dealt 
    with PSS parameter comparisons. Paul Hoffman raised a concert about the 
    reason for having the PSS draft, a second signature algorithm (DSS) is 
    already documented by the working group.  Russ Housley and others 
    indicated that having a backup was the main reason, and this permitted a 
    backup within the RSA family of algorithms.  Blake Ramsdell then raised a 
    concern over whether the working group is going to become a location for 
    anybody to create a document for their favorite algorithm.  Russ Housley 
    indicated that this was within the scope of the group's charter. If 
    interested in the RSA PSS outcome working group members are directed to 
    comment on the PKIX mailing list (ietf-pkix@imc.org).
    SIP and SIPPING:  Rohan Mahy, one of the co-chairs for the SIP working 
    group, gave a presentation on how SIP/SIPPING are in the process of using 
    S/MIME and CMS in the SIP protocol for providing origin 
    authentication, integrity and confidentiality security services. These were 
    added in a hurry to RFC 3261 just before adoption.  Rohan was asking to get 
    some help both for providing implementation assistance and advise on what 
    should be specified in future documents from the groups.
    Camellia Draft: KATO Akihiro gave the presentation on the draft for 
    Camellia to be used as a content encryption algorithm with CMS.  Draft -01 
    contains two additional sections, one for S/MIME Capabilities and one for 
    Key Wrap algorithm details.  Some comments have been made on the -01 
    draft, after these are address the document should be ready for working 
    group last call.  Information on Camellia can be obtained at 
    ESS Document Updates:  Jim Schaad gave a brief description of a problem 
    that has been identified with the ML Expansion History update in the ESS 
    document.  The problem is that this signed attribute currently 
    addresses two different problems, the detection of loops during ML 
    expansion and changing receipt generation behavior.  This means that a work 
    flow application cannot easily change the receipt behavior without 
    appearing to be an MLA.  The proposal is to split these two different 
    requirements into separate signed attributes.  An MLA would make use of 
    both new attributes, but the work flow application would only make use of 
    one of them.  An update the ESS document (RFC 2634) is needed.
    - CERTbis, MSGbis, Examples, and Camellia drafts will undergo working 
    group last call as soon as next versions are published.
    - ESS draft to be updated to address workflow issue.
    - SIP/SIPPING issues to be addressed by S/MIME mailing list.
    - RSA PSS signatures will be adopted as described in PKIX.


    S/MIME Working Group Status
    Camellia Update
    SIP Issues with S/MIME and CMS
    CMS Interoperability Matrix