2.7.15 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-03


Sean Turner <turners@ieca.com>
Blake Ramsdell <blake@sendmail.com>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Russ 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.1 specification. As part of the
specification update, a new suite of "mandatory to implement"
was be selected. Current efforts update and build upon these base

The Cryptographic Message Syntax (CMS) (RFC 3852) 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.

CMS, as well as S/MIME version 3 and later, permit the use of
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 use of
symmetric key-encryption keys. The specification will be algorithm

To aid initial determination of recipient's cryptographic capabilities
specification will be developed allowing S/MIME capabilities to be
stored and asserted in X.509 certificates based on the X.509
and CRL profile developed by the PKIX Working Group.

The working group will perform necessary interoperability testing to
progress the CMS and S/MIME specifications to Draft Standard. The CMS
specification depends on the RFC 3280, which was developed by the PKIX
working group. This profile must progress to Draft Standard before CMS
and the other S/MIME specifications can progress to Draft Standard.
Assuming timely progress by the PKIX Working Group, the S/MIME
specification can start progressing to Draft Standard in 2005.

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
Done  First draft of RSA KEM algorithm specification
Done  Submit update to MSG as Proposed Standard
Done  Submit update to CERT as Proposed Standard
Done  Last call on RSA PSS algorithm specification
Done  Submit RSA PSS algorithm specification as Proposed Standard
Done  First draft of S/MIME Capabilities Certificate Extension
Done  Working Group Last Call for S/MIME Capabilities Certificate Extension
Done  Submit S/MIME Capabilities Certificate Extension as Informational RFC
Feb 2005  Request advancement of CMS Algorithms to Draft Standard
Feb 2005  Request advancement of CMS to Draft Standard
Feb 2005  Request advancement of ESS to Draft Standard
Feb 2005  Request advancement of CERT to Draft Standard
Feb 2005  Request advancement of MSG to Draft Standard
Nov 2005  Last call on RSA KEM algorithm specification
Jan 2006  Submit RSA KEM algorithm specification as Proposed Standard


  • draft-ietf-smime-symkeydist-09.txt
  • draft-ietf-smime-gost-05.txt
  • draft-ietf-smime-certcapa-05.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
    RFC3114 I Implementing Company Classification Policy with the S/MIME Security Label
    RFC3125 E Electronic Signature Policies
    RFC3126 I Electronic Signature Formats for long term electronic signatures
    RFC3183 E Domain Security Services using S/MIME
    RFC3185 PS Reuse of CMS Content Encryption Keys
    RFC3211 PS Password-based Encryption for SMS
    RFC3217 I Triple-DES and RC2 Key Wrapping
    RFC3218 I Preventing the Million Message Attack on CMS
    RFC3274 PS Compressed Data Content Type for Cryptographic Message Syntax (CMS)
    RFC3278 I Use of ECC Algorithms in CMS
    RFC3369 PS Cryptographic Message Syntax
    RFC3370 PS Cryptographic Message Syntax (CMS) Algorithms
    RFC3394 I Advanced Encryption Standard (AES) Key Wrap Algorithm
    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)
    RFC3657 Standard Use of the Camellia Encryption Algorithm in CMS
    RFC3850 Standard S/MIME Version 3.1 Certificate Handling
    RFC3851 Standard S/MIME Version 3.1 Message Specification
    RFC3852 Standard Cryptographic Message Syntax (CMS)
    RFC3854 Standard Securing X.400 Content with S/MIME
    RFC3855 Standard Transporting S/MIME Objects in X.400
    RFC4010 Standard Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS)
    RFC4056 Standard Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)
    RFC4134 I Examples of S/MIME Messages

    Current Meeting Report

    Working group status. There are four drafts that are currently in the 
    working group that have not become RFCs yet. symkeydist is still in the 
    RFC editor's queue with a missing reference, waiting for the CMC draft 
    to be released from PKIX. certcapa is in the RFC editor's queue and 
    requires no further action. gost has a new release that was made 
    recently, and is going to immediately progress to working group last 
    call. KEM is waiting on work to complete in X9.44.
    The open milestones for the working group fall into two categories. One 
    category is progressing the CMS and S/MIME RFCs to draft standard 
    status. The first step towards this is the completion of an 
    interoperability report, which is waiting for interoperability work to 
    be published from the PKIX working group. The other category surrounds 
    the KEM algorithm draft, which is waiting for the X9.44 work to be 
    completed (as noted above).
    John Biccum from Microsoft announced that they will be S/MIME digitally 
    signing security bulletins starting in February 2006. The root 
    certificate is the software signing authority certificate that has been 
    distributed with Windows essentially forever, and will be made available 
    from Microsoft for non-Windows clients.
    Mark Schertler from Voltage Security discussed their Identity Based 
    Encryption (IBE) public key system, and proposed an integration with CMS 
    using the OtherRecipientInfo field. The underlying algorithms are being 
    discussed in the IEEE 1363.3 working group, and I expect that Voltage 
    will be releasing individual internet-drafts in the short term, and we 
    can further discuss the relevance to the S/MIME working group.
    Russ Housley gave an overview of the algorithm transition we are 
    undertaking, and the "walk, don't run" attitude that we have towards 
    moving away from SHA-1 as a digest algorithm.
    Jim Schaad presented a concern about the algorithm flexibility of the 
    ESSCertID field. Right now this field is limited to the use of the SHA-1 
    algorithm, and Jim proposed the addition of an AlgorithmIdentifier to 
    indicate the digest algorithm used to prepare the digest. Jim also 
    proposed an idea for handling signature algorithm transitions in CMS. 
    Basically, in each SignerInfo the signer would indicate the other 
    SignerInfos that were added by the signer. Jim's theory was that this 
    might help mitigate a downgrade attack where the signer applies both a 
    SHA-256 signature and a SHA-1 signature, and the attacker removes the 
    SHA-256 signature to force the receiver to use the SHA-1 signature.
    Blake Ramsdell discussed a strawman for SHA-256 support in S/MIME. The 
    draft as it stands right now needs more work to discuss both the reasons 
    for the transition to SHA-256, as well as the considerations for 
    handling the transition and processing multiple signature values, as 
    well as using existing capabilities constructs for expressing support 
    for SHA-256.
    * gost to WG last call
    * Continued pressure to get CMC released to get symkeydist moving again
    * Continue discussion about SHA-256 transition


    Introduction, agenda, draft status, milestone status
    Identity-Based Encryption technology overview
    Hash transition updates
    SHA-256 as an alternative digest