S/MIME Mail Security (smime)

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

Last Modified: 2004-05-18

Sean Turner <turners@ieca.com>
Blake Ramsdell <blake@sendmail.com>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Russell Housley <housley@vigilsec.com>
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) (RFC 3369) 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 CERT and MSG (RFC 2632 and RFC 2633). Building on the CMS CompressedData content type specified in RFC 3274, the update to MSG will specify conventions for message compression, in addition to message signature and encryption.

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) (RFC 2634) document.

CMS, and thus S/MIME version 3 and later, permit 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.

In S/MIME version 3 and later, CMS is used to provide security to the message content if an Internet mail message. However, 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.

The working group will perform necessary interoperability testing to progress the S/MIME specifications to Draft Standard. The CMS specification depends on the RFC 3280, the PKIX certificate and CRL profile. This profile must progress to Draft Standard before CMS and the other S/MIME specification can progress to Draft Standard. Assuming timely progress by the PKIX Working Group, the S/MIME specification can start progressing to Draft Standard toward the end of 2003.

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.
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.
Done  Submit mail list key distribution as a Proposed Standard
Done  Submit X.400 CMS wrapper specification as a Proposed Standard
Done  Submit HMAC key wrap description as Proposed Standard
Done  Submit RSA OAEP algorithm specification as Proposed Standard
Done  Sumbit AES algorithm specification as Proposed Standard
Done  Submit X.400 transport as a Proposed Standard
Done  Last call on CMS and ESS examples document
Apr 03  Sumbit update to MSG as Proposed Standard
Apr 03  Sumbit update to CERT as Proposed Standard
Done  First draft of RSA KEM algorithm specification
May 03  Submit CMS and ESS examples document as Informational RFC
Done  Last call on RSA PSS algorithm specification
Jul 03  Last call on RSA KEM algorithm specification
Sep 03  Submit RSA PSS algorithm specification as Proposed Standard
Oct 03  Submit RSA KEM algorithm specification as Proposed Standard
Oct 03  Final S/MIME version 3.1 interoperability matrix
Nov 03  Request advancement of CMS Algorithms to Draft Standard
Nov 03  Request advancement of CMS to Draft Standard
Dec 03  Request advancement of ESS to Draft Standard
Dec 03  Request advancement of CERT to Draft Standard
Dec 03  Request advancement of MSG to Draft Standard
  • - draft-ietf-smime-examples-13.txt
  • - draft-ietf-smime-symkeydist-09.txt
  • - draft-ietf-smime-x400transport-09.txt
  • - draft-ietf-smime-x400wrap-09.txt
  • - draft-ietf-smime-pss-03.txt
  • - draft-ietf-smime-gost-02.txt
  • - draft-ietf-smime-cms-seed-01.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
    RFC3537 PS Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES)Key
    RFC3560 PS Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)
    RFC3565 PS Use of the Advanced Encryption Standard (AES)Encryption Algorithm in Cryptographic Message Syntax (CMS)
    RFC3657StandardUse of the Camellia Encryption Algorithm in CMS
    RFC3850StandardS/MIME Version 3.1 Certificate Handling
    RFC3851StandardS/MIME Version 3.1 Message Specification
    RFC3852StandardCryptographic Message Syntax (CMS)

    Current Meeting Report

    Minutes for Secure MIME (S/MIME) WG Meeting
    IETF #60
    Tuesday PM III Session

    Agenda: Blake Ramsdell covered the agenda for the meeting. No changes were made.

    Working Group Status: Blake Ramsdell covered the status of the active documents in the working group. the documents that have changed status since the last meeting are:

    Published as RFC:
    - draft-ietf-smime-rfc2632bis-08 is now approved as RFC 3850
    - draft-ietf-smime-rfc2633bis-10 is now approved as RFC 3851
    - draft-ietf-smime-rfc3369bis-05 is now approved as RFC 3852
    - draft-ietf-smime-x400wrap-09 is now approved as RFC 3854
    - draft-ietf-smime-x400transport-09 is now approved as RFC 3855

    RFC Editor Queue:
    - PSS is pinned by a PSS document in PKIX. schaad reported that PSS has also been awaiting an IESG write-up since April. housley indicated that he would check on this.
    - SYMKEYDIST is pinned by CMCbis (from PKIX) which is in turn pinned by CRMFbis (from PKIX).

    - EXAMPLES - A new release incorporates some edits, but is essentially done. New version was after deadline, so will go to WG Last Call as soon as queue opens up.
    - GOST - Some editorial issues to take care of. Draft is good until October.
    - KEM - See later discussion.
    - RFC2624bis - Not yet published; fixes some problems with ML expansion and receipt policy; moves them into separate attributes.

    Milestone Updates:
    - Updates to MSG and CERT for Proposed Standards.
    - Submitted RSA PSS as a Proposed Standard
    - Milestones themselves need to be updated to more realistic dates especially for RSA KEM.

    KEM Status - ramsdell said he received a status update from burt kaliski<!--[if !supportLists]--><!--[if !supportLists]--> (RSA) on KEM. RSA KEM I-D has alignment relationship with ISO/IEC 18033-2 and ANSI X9.44. Outstanding issues in X9.44 include: text on assurance of validity of public keys, possession of private key, and security considerations. Clearly these need to be resolved before advancing. Expect substantial completion of ISO/IEC 18033-2 and ANSI X9.44 in mid-2005 with formalities continuing into 2006. The KEM I-D will be updated to track these, but should not be finalized until balloting begins. PKCS #1 may also be updated. Upshot is that we will probably not complete the KEM I-D until late 2005 or early 2006.
    Formats for Long Term Electronic Signatures - ross briefly introduced the background of the project for ETSI to establish guidelines for digital signatures that will have legal standing. RFC 3126 was produced to align with the ETSI document. Additional changes to the underlying signature standards (CMS, etc.) have somewhat advanced the discussion. The updated I-D that would obsolete RFC 3126. housley asked whether he was asking to take this on as a WG item. 10 or so were in favor, and no objections were voiced.

    Boneh-Franklin Identity Based Encryption in S/MIME - martin presented this proposal for an alternative to PKI-based encryption. Based on a process for deriving a public key based on a string representation of the user identity. The mechanism relies on supersingular elliptic curves. It uses a Tate pairing on a particular supersingular curve that has been tested to ensure that it isnít cryptographically ďbadĒ. The public key must be obtained from a key server so it isnít good for digital signature, but is okay for encryption. Bottom line is that this is being proposed as an alternative key exchange mechanism for use with CMS/SMIME. There were technical questions about how the identity is bound to the identity string, and there were IPR questions. ramsdell indicated that the politics of the solution aside, he considered this interesting to the WG as something that is using CMS. ramsdell summarized that the WG is basically in a monitoring mode with respect to this proposal, but there are clearly some concerns wrt IPR and complexity. He noted that that he would like to see some more before definition considering this any further. turner pointed out that you could still develop the draft as an individual submission. housley remarked that this would give people an opportunity better evaluate the idea.
    X.509 S/MIME Capabilities - santesson gave an overview of his proposal that the S/MIME Capabilities attribute from RFC 2633 be included in the user certificate. The proposal is to include the attribute as a non-critical extension as opposed to in the subject directory attributes extension. ramsdell asked if there were any opposition to bringing this in as a WG item. No opposition was expressed.

    Other Business: There was some discussion about closing the WG, but it was decided to poll the WG for work items prior to each meeting to better assess whether it should meet at future IETF meetings.


    S/MIME Capabilities Certificate Extension
    KEM Status
    Formats for long term signatures