2.6.9 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-13

Sean Turner <turners@ieca.com>
Blake Ramsdell <blake@brutesquadlabs.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
Jun 03  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-12.txt
  • - draft-ietf-smime-symkeydist-09.txt
  • - draft-ietf-smime-x400transport-09.txt
  • - draft-ietf-smime-x400wrap-09.txt
  • - draft-ietf-smime-rfc2632bis-04.txt
  • - draft-ietf-smime-rfc2633bis-06.txt
  • - draft-ietf-smime-camellia-05.txt
  • - draft-ietf-smime-cms-rsa-kem-01.txt
  • - draft-ietf-smime-gost-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
    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)

    Current Meeting Report

    IETF 58th Meeting
    Hilton Hotel - Minneapolis, Minnesota
    11 November 2003, 1700-1800
       The meeting was chaired by Blake Ramsdell of Brute Squad Labs.  The 
    other co-chair, Sean Turner of IECA, was unable to attend.  
    Approximately 40 participants were in attendance.
       The Chairman introduced the agenda.  There were no comments on the 
    agenda from the WG.  He acknowledged that Chris Bonatti agreed to serve as 
    note-taker.  He asked for an official XMPP scribe, but there were no 
    volunteers.  So the Chairman suggested that anybody using XMPP act on 
    their own recognizance to highlight important statements over that 
       The Chairman gave an update of the status of WG activities. He 
    reported the following:
    	There are two newly completed RFCs:
    		- RFC 3560: Use of the RSAES-OAEP Key Transport Algorithm in the 
    Cryptographic Message Syntax (CMS), Russ Housley, July 2003.
    		- RFC 3565: Use of the Advanced Encryption Standard (AES) 
    Encryption Algorithm in Cryptographic Message Syntax (CMS), Jim Schaad, 
    July 2003.
    	Reported that four I-Ds were approved and were now in the
    	RFC Editor's Queue:
    		- draft-ietf-smime-camellia-05
    		- draft-ietf-smime-symkeydist-09
    		- draft-ietf-smime-x400wrap-09
    		- draft-ietf-smime-x400transport-09
    	WG Last Call coming up again on:
    		- draft-ietf-smime-rfc2632bis-04 (Son-of-CERT)
    		- draft-ietf-smime-rfc2633bis-06 (Son-of-MSG)
    		- draft-ietf-smime-examples-12
    	Up and coming drafts include:
    		- draft-ietf-smime-cms-rsa-kem-01
    		- draft-ietf-smime-gost-00
    	New draft coming in soon:
    		- draft-park-cms-seed-00
    	Completed milestones
    		- Submittted x400wrap and x400transport drafts
    	Open Milestones
    		- Complete rfc2632bis and rfc2633bis 
    		- Complete examples draft
    		- Develop draft on RSA PSS algorithm
    	Longer Term
    		- WG Last Call on RSA KEM
    		- Submit RSA KEM
    		- Final S/MIME version 3.1 interoperability matrix
    	New Milestones
    		- SEED
    		- GOST
       Paul Hoffman reported on the update to the CMS and ESS Examples draft.  He 
    noted that major revision was performed since Vienna.  Essentially we 
    admitted that we were in denial about a lot of the examples, and so 
    rethought the scope so that it took at least two working 
    implementations to include the case.  Thus many examples were deleted.  
    There are still some outstanding comments from Jim Schaad noting some bugs in 
    the code.  These should be resolved shortly.  He noted that comments are 
    still welcome.  At least one comment outstanding.
    MSGbis and CERTbis
       Blake Ramsdell reported as the editor of MSGbis and CERTbis drafts. He 
    noted numerous changes from Jim Schaad (mostly editorial) had been 
    integrated into the document. He noted that he still needs to clear up the 
    "I-D Nits" issues (i.e., splitting references, etc.). He also noted that he 
    is waiting for a secondary validation of hex dump. Jim Schaad is looking at 
    this, but additional comments from others would be helpful. He noted that 
    there was a new issue on definition of smimeCapabilities attribute values 
    for the RC2 algorithm. It is not clear that these are defined 
    anywhere. Ideally, we would like to have this elsewhere, but since it's 
    kind of an afterthought we're going to have to squeeze it into MSG. 
    Another new issue that has been discussed on the list is the guidance text on 
    selection encryption algorithm. There was some obsolete language that 
    dealt with weaker algorithms. Ramsdell indicated that he was revising text to 
    update the decision tree to lead you instead to 3DES. 
       Another new issue was clarification of the semantics of the 
    smime-type subtype.  The smime-type is indicated an attribute on the 
    Content-Type MIME header.  Current values defined in MSG include 
    signed-data, enveloped-data, compressed-data, and certs-only.  The 
    question is, what is the right way to use this.
    	-	As a hint for IMAP?
    	-	As a content hint for processing?
    Ramsdell stated that he believed this should really reflect the 
    outermost wrapper that must first be processed.  Chris Bonatti stated that he 
    didn't have an answer to this question, but pointed out that the 
    x400wrap and x400transport drafts added some new values of smime-type for 
    signed-x400 and encrypted-x400. While these clearly address more than just 
    the outer wrapper, they distinguish a different service and message spec 
    than S/MIME per se so there is some value.  Indicating that he was an 
    e-mail implementer, DABOO stated that he does not want to have to decode the 
    entire content to know what kind of visual indicator to present, but he 
    does not think that these two things are separate.  Jim Schaad 
    indicated that what brought this issue up is the ambiguity of signed 
    receipts.  In the instance of a signed-receipt that is also 
    encrypted, which smime-type value should be used: the 
    signed-receipt (defined in RFC 2634) or encrypted-data (as per the MSG 
    spec)?  Somebody (Blake?) noted that they have the same issue with the SIP 
    WG, in that they want to easily identify data that contains SIP so that 
    they can further process them.  The chairman noted that he was not sure 
    whether the Application Area should be consulted before deciding this 
    matter. The WG tentatively agreed that the strawman solution is that 
    smime-type is more a display hint than a processing hint, and that we will 
    clarify this in the document.  More discussion on the list is 
       Ramsdell noted that there is a PKIX issue that may require 
    clarifications to the language regarding the 
    subjectKeyIdentifier (SKI), and that he is not clear what the outcome 
    should be.  The problem is that use of the SKI to identify 
    certificates is not sufficiently unique by itself.  The reason for this 
    seems to be that some implementations may issue crappy SKIs that are 
    short, locally incremented identifiers.  We need to add language to 
    clarify that certificate processing when identified with SKI should:
    	-	Be prepared for matching multiple certificates;
    	-	Be prepared for some of those candidate certificates to fail.
    This would help implementations to bullet-proof against failing in what is a 
    predictable scenario.  Russ Housley, the Security Area Director, stated 
    that he agreed with most of this, but indicated that we should preface this 
    new text with the statement that if the recommendations of RFC 3280 are 
    followed (i.e., SKI is the hash of the public key) then the overlap of 
    these identifiers is possible but unlikely.  This text is required mainly 
    because that recommendation is a SHOULD instead of a MUST.
       Ramsdell also indicated that he had made several minor updates to the 
    CERTbis document.  He reported that he has added differences since 3.0 
    certificate profile to the document.  He has also added credits and minor 
    editorial fixes.
       Jim Schaad reported that he has finished the edits of the PKIX 
    version of PSS.  This S/MIME PSS draft should be completed shortly.  He 
    also indicated that the Interoperability Matrix entries for CMS and 
    CMSALG are finished.  He still needs to do some editorial work to clean up 
    the document.  The ESSbis issue is still alive, but there has been no 
    recent movement.
       The Chairman reported speaking to Burt Kaliski of RSA, and noted that the 
    KEM draft is temporarily stalled.  The KEM draft is based on ANSI X9.44, 
    which has not yet stabilized its ASN.1 syntax.  The KEM draft cannot 
    progress to RFC status until relevant X9.44 areas are stabilized.
       The Chairman reported that the GOST draft is being updated and will be 
    posted after the meeting.  The new draft will add normative 
    references to CMS and Russian law.  He noted there are still some 
    additional comments that need to be taken care of. Normative reference to 
    CPALGS is a problem.  The GOST algorithm needs to be described in an 
    international standard, national standard, or RFC.  An 
    informational RFC would be easiest.  Russ Housley stated that he thinks 
    they are aiming to provide such an informative RFC for the Seoul 
    meeting.  Paul Hoffman pointed out that making it an RFC makes things a lot 
    easier than the alternatives.  Ramsdell and Housley agreed.  Another issue is 
    ASN.1 modules.  The -00 draft uses the X.680 version of ASN.1, and needs to 
    switch to X.208-88 to align with the rest of S/MIME. There are also too 
    many modules in the draft.  There were six modules in the -00 version, and 
    will be 5 in -01, but they can still be further merged.
       Jongwook Park from KISA gave a presentation introducing the SEED 
    algorithm.  He noted that SEED is based on a Feistel structure with 16 
    rounds.  It has a 128-bit blocksize, and employs a 128-bit key.  He 
    proposed publishing the SEED algorithm description as an 
    informational RFC prior to the Seoul meeting. All the 
    documentation is available now from 
    http://www.kisa.or.kr/seed/index.html.  He invited comments from the WG.  
    Park also noted that we should watch for feedback from ISO/IEC JTC1 SC27.  
    The Chairman asked whether SEED was currently being considered by ISO.  
    Park indicated that it was.  He noted that he does not attend the ISO 
    meetings, but some of his colleagues do.  Ramsdell asked whether ISO has 
    assigned OIDs for the algorithm.  Park indicated that they have not.  He 
    stated that they were examining the strength of the algorithm, but there had 
    been no results yet.  Russ Housley asked whether SEED was the Korean 
    national algorithm.  Park responded that SEED was mandatory in 


    MSGbis and CERTbis Update
    KEM Draft Status
    GOST status
    Use of the SEED Encryption Algorithm in CMS