2.6.8 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 10-Nov-97


Russ Housley <housley@spyrus.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>

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 will define MIME encapsulation of digitally signed and encrypted objects whose format is based on PKCS #7. [1] X.509 Certificates and CRLs as profiled by the existing PKIX Working Group will be used to support authentication and key management. The Working Group will base its work on the S/MIME version 2 specification (available from RSA Data Security), but the Working Group will be free to change any part of that specification. In particular, the Working Group will prepare a new document that allows algorithm independence, based on PKCS #7 1.5.

The message syntax specification, based on PKCS #7 version 1.5, will be expanded to allow additional key signature and key exchange algorithms. The message and certificate specifications will be revised to allow them to become standards. The optional security extensions document will specify protocols that allow for additional security features, such as signed message receipts.

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, particularly in specification of cryptographic algorithms and MIME structure.

[1] RSA Data Security publishes the PKCS Series of documents. RSA Data Security has permitted the IETF to publish them as Informational RFCs as well as to extend and enhance them.

Goals and Milestones:

Nov 97


Submit First draft of message syntax specification as an I-D.

Nov 97


Submit First draft of S/MIME v3 message specification as an I-D.

Nov 97


Submit First draft of S/MIME optional security extensions as an I-D.

Nov 97


Submit First draft of S/MIME v3 certificate specification as an I-D

Dec 97


WG Last Call on Message Syntax.

Dec 97


WG Last Call on Certificate Specification.

Dec 97


WG Last Call on Message specification.

Jan 98


WG Last Call on Optional Security Extensions.

Jan 98


Submit Message Syntax I-D to IESG for consideration as a Proposed Standard.

Jan 98


Submit S/MIME v3 message specification I-D to IESG for consideration as a Proposed Standard.

Jan 98


Submit S/MIME v3 certificate specification I-D to IESG for consideration as a Proposed Standard.

Feb 98


Submit S/MIME optional security extensions I-D to IESG for consideration as a Proposed Standard.


No Request For Comments

Current Meeting Report

Minutes of the S/MIME Mail Security (smime) Working Group

The meeting was held on 10 December 1997 in Washington, D.C. Over one hundred people attended. These minutes were written and edited by John Pawling from J.G. Van Dyke & Associates, Inc. (jsp@jgvandyke.com). The chairman and other working group members greatly appreciate John's efforts.

I. Introductions - Russ Housley

Russ reviewed the agenda. Nobody objected to the agenda. He then reviewed the list of the S/MIME WG Internet Drafts (I-D):

Latest Revision

I-D Title



Nov 97

Cryptographic Message Syntax (CMS)



18 Nov 97

Enhanced Security Services (ESS) for S/MIME


20 Nov 97

S/MIME V3 Message Specification (MSG3)



Nov 97

S/MIME V3 Certificate Handling (CERT3)


II. CMS Draft Discussion - Russ Housley

Russ presented several briefing slides regarding the history of and future plans for the CMS I-D. The slides and related discussion are included in the following text.



CMS 00 included:

CMS 01 included:

Future Plans

CMS 02 proposed changes:

Beyond CMS 02

AuthenticatedData object (facilitates Message Authentication Codes)


CMS 02 Proposal 2: Russ explained that the inclusion of a copy of the content encryption key encrypted for the originator in an envelopedData object will ensure that the originator can decrypt the envelopedData object if it is returned for non-delivery. Several WG members objected to the "mandatory" nature of the proposal. A comment was made that there will be one more copy of the content encryption key that can be attacked. Another comment was that it takes additional processing resources to encrypt the key for the originator. Another comment was that there are customers who require that encrypted data must not be able to be decrypted by the originator. Another point was made that other protocols that use CMS might not have the property that the originator could get a "bounced" message. S-HTTP is one example where the originator does not need to have a copy of the content encryption key encrypted for the originator. Jeff Schiller stated that the "MUST implement" requirement means that the implementer must implement the feature, not that the feature must be present in every message. Jeff said that a vendor must implement the "MUST" requirements to claim conformance to the specification, but that the customer can choose not to populate the field. Steve Kent made similar statements. The consensus of the WG was that the requirement must not be included in the CMS I-D, but that it must be included in the MSG3 I-D as a SHOULD requirement. Blake Ramsdell took the action to add the requirement to MSG3.

CMS 02 Proposal 3: Russ proposed that the CMS ASN.1 module should use the 1988 ASN.1 syntax definitions with a few added enhancements (such as BMPString, etc). He stated that he would prefer not to include two modules (one using 1988 rules and another using 1994 rules) in CMS. He stated that he had drafted a CMS module and that it had been successfully parsed using three different ASN.1 compilers. Russ asked if the WG preferred 1988 or 1994 ASN.1 syntax definitions. The silence was deafening. Because the 1994 proponents seemed to be absent, Paul Hoffman stood up for them and stated that their concern (based on message traffic on the S/MIME WG mail list) was that using the 1988 syntax rules with enhancements did not constitute valid ASN.1 definitions. Another WG member stated that the 1994 syntax rules include the "table" format which tightly binds OIDs with ASN.1 definitions (in contrast to 1988 OID/ANY pairs) that an ASN.1 compiler can process in one pass and can check for correctness. Eric Rescorla said that the "table" format is not always a positive feature because there are cases in which the ASN.1 decoding software can decode the object to the point of the OID/ANY pair, but that other modules of the software can decode the ANY based on the value of the OID. The consensus was that the CMS ASN.1 module will use the 1988 ASN.1 syntax definitions with a few enhancements.

CMS 02 Proposal 4: Russ stated that CMS 02 will include definitions for the digestedData and encryptedData objects, but that those objects are not intended for use with S/MIME applications. The MSG3 I-D will not include support for digestedData and encryptedData. They are being added to CMS to support requirements stated by the S-HTTP proponents. The S-HTTP specification needs to point to the CMS I-D because it includes IETF-acceptable "MUST implement" algorithms. Nobody objected to the proposal.

CMS 02 Proposal 5: Russ stated that CMS 02 will include definitions of the PKCS #9 attributes, so that CMS does not have to refer to the RSA PKCS #9 specification. Nobody objected to the proposal.

CMS 02 Proposal 6: The WG agreed that the "MUST implement" algorithms are SHA-1, DSA, Diffie-Hellman (D-H) and 3DES as specified in MSG3. The D-H will be one of the x9.42 variants. The 3DES will use three independent keys and CBC mode. Russ stated that CMS 02 will include placeholders for the algorithm specifications that will include details regarding the use of the "MUST implement" cryptographic algorithms with CMS. After a brief debate regarding which I-D should include the "MUST implement" cryptographic algorithms, it was agreed that the CMS I-D will specify the "MUST implement" algorithms and that the MSG3 I-D will refer to the CMS I-D for the specification of the "MUST implement" algorithms.

III. MSG3 Draft Discussion - Blake Ramsdell

Blake stated that MSG3 is based on the S/MIME Version 2 Message Specification. It has been updated to support "MUST implement" algorithms of SHA-1, DSA, D-H and 3DES. It also includes the RSA algorithms as "SHOULD implement" algorithms. [Note that MSG3 will be modified to refer to the CMS I-D for the specification of the "MUST implement" algorithms.]

Blake stated that the text regarding the Certificate Request message format and certificate generation issues will be moved to CERT3.

Dave Solo asked which I-D will include text regarding the use of separate digital signature (DS) and key management (KM) keys. Blake answered that CERT3 will include that text. Paul Hoffman stated that the security section should include text encouraging the use of separate DS and KM keys.

Jim Schaad stated that the attribute identifying which of a user's certificates should be used for DS and KM should be included. The attribute will be defined as a CHOICE between IssuerandSerialNumber and subjectKeyIdentifier. Blake agreed that the attribute will be included in MSG3.

Jim Schaad stated that MSG3, Section 3.1 should be changed to remove the requirement that the RFC822 "from-field" must be identical to the signer's RFC822 address included in the signer's X.509 certificate. Blake agreed. Eric Rescorla stated that the recipient should be informed if there is a difference. A WG member asked what requirement, if any, is there for an RFC822 name in a KM X.509 certificate. Steve Kent made the point that users may wish to send messages from multiple mailboxes using the same X.509 certificate. Steve went on to say that the receiving agent could display the "from-field" in the normal in-box, but that the signer could be identified in a security-related window. Another WG member stated that the WG should not dictate what the application displays. The WG agreed with this concept. Paul Hoffman terminated the debate by asking that interested parties send a message to the S/MIME WG mail list proposing specific changes to MSG3, Section 3.1.

IV. CERT3 Draft Discussion - Blake Ramsdell

Blake stated that CERT3 refers to the PKIX X.509 Certificate and CRL Profile (PKIX I). CERT3 states that certificate extensions should be used as stated in PKIX I. CERT3 states that certificates should be allowed to include RFC822 addresses. Unless anybody complains, CERT3 will use the certificate chaining strategy described in PKIX I. PKIX I allows NULL issuer and subject DNs, so the issuerAltName and subjectAltName extensions can be used for chaining. Nobody objected to the concepts presented by Blake.

V. ESS Draft Discussion - Paul Hoffman

Paul stated that ESS describes features not included in the S/MIME v2 documents. He stated that some of the additional security features described in ESS can be used in conjunction with S/MIME v2 messages in addition to S/MIME v3 messages. He stated that the addition of ESS features to CMS enables an implementation to meet U.S. Department of Defense (DOD) requirements. He described the additional features as follows:

Signed Receipts: Paul stated that when an originator of a SignedData object verifies the signature of an ESS Signed Receipt returned by the recipient of the SignedData object, then the Signed Receipt verification provides proof to the originator that the recipient received and was able to verify the signature of the SignedData object (content and authenticated attributes). Paul stated that ESS Signed Receipts are not intended to provide any other services. There have been suggestions discussed on the IETF S/MIME mail list that additional services should be provided by ESS Signed Receipts. Paul stated that there are IETF WGs dedicated to calendaring/scheduling (calsch) and electronic commerce interchange (ediint) that are working on similar services, so he does not recommend that those services should be provided by the ESS Signed Receipt. Nobody objected to this concept.

Security Label: Identifies the sensitivity of the encapsulated content. In addition to meeting US DOD requirements, commercial industry needs this capability also. For example, the health care industry needs to label personal medical data. Nobody objected to this concept.

Mail List Expansion History: Provides information in the CMS header to warn ML agents of looping conditions. A WG member asked if the ML information increased the risk of traffic analysis. Paul said yes, but that the benefit gained far outweighed the risk incurred. Nobody objected to the ML concepts included in ESS.

A WG member stated that timestamping should be included in ESS. Another WG member stated that the IETF must design a standard for digital timestamps. It was also stated that there would probably be more than one timestamping service proposed and the S/MIME WG will need to choose the one best suited for S/MIME. Once the IETF proposals are stable, then the S/MIME WG can make that decision. Everybody agreed with this plan.

VI. CRS Draft Discussion - Mike Myers

Background: One of the biggest issues facing the PKIX and S/MIME WGs was the debate of whether the PKCS 10-based CRS or the PKIX Certificate Management Protocol (CMP) would be endorsed by IETF as the standard Internet protocol. The two proposed specifications contained redundant ASN.1 syntaxes for Certificate Request and other formats. Prior to the IETF meetings, there was a proposal to move the CRS work into the S/MIME WG. At the 8 December 97 IETF PKIX WG, it was decided that the CRS work belonged in the PKIX WG rather than the S/MIME WG because the Certificate Request format is not an S/MIME-specific issue, it is a general PKI issue. The ideal situation would be to have a common Certificate Request format (and other related certificate management formats) that can be communicated via various mechanisms (including S/MIME and others).

Mike presented a series of briefing slides regarding the history of CRS. The slides and related discussion are included in the following text.



Current Status of Draft:



Mike stated that the CRS and CMP authors and other interested parties had developed a compromise solution referred to as the "harmonized" Certificate Request format (which has not yet been publicized). The end result of the IETF meetings is that the PKIX WG will publish a separate RFC that includes the "harmonized" Certificate Request and other related protocols. The CMP and CRS I-Ds will be changed to replace their redundant protocols with pointers to the "harmonized" protocols. The CRS I-D will define the use of CMS for protecting the "harmonized" Certificate Request (and other related certificate management protocols). The CERT3 I-D will define how the CRS objects are communicated using MIME. The WG concluded that CERT3 should point to the CRS I-D which will point to the "harmonized" protocol RFC. Other WGs will define how the "harmonized" protocols will be communicated via other mechanisms.

VII. Add CRS to Charter? - Russ Housley

Russ proposed that the S/MIME WG should concur with the PKIX WG decision that the CRS work should stay in the PKIX WG. In other words, the S/MIME WG should not define a Certificate Request format. The S/MIME WG agreed with Russ' proposal.

VIII. Interoperability Discussion - Tim Dean

Secure Interoperability Discussion - Tim Dean

Tim presented a series of briefing slides that are available from http://sostdp.mod.uk/demo1a.html#pct. Tim asked for the S/MIME WG's opinion regarding a proposal to define a strategy for making Message Security Protocol-protected X.400 applications interoperable with S/MIME applications including preserving the originator's signature of the content. Several WG members stated that heterogeneous e-mail is a message format problem, not a security problem. Paul Hoffman stated that there is another IETF WG, MIXER, that is working on X.400-MIME interoperability that may want to deal with the issues raised by Tim, but that these issues should not be debated by the S/MIME WG. However, Jim Craigie pointed out that allowing CMS to carry any kind of data object rather than just MIME entities would be a significant enhancement to the protocol. This would not only make secure interoperability much easier, but also allow direct signing of various objects such as word processor files etc. Russ Housley agreed that it was the intent to allow CMS to be pointed at by other documents for such purposes. Jeff Schiller agreed. Tim asked that any comments be sent to him at t.dean@eris.dera.gov.uk.

IX. Signed Receipt Hashing - John Pawling

John presented a proposal for enhancing ESS, Section 2.4, Signed ReceiptCreation, so that the chain of digests leading to the signedData/Receipt signature value includes digesting the authenticatedAttributes of the original signedData signerInfo requesting the signedData/Receipt and includes digesting the authenticatedAttributes of the signedData/Receipt signerInfo. This will allow the originator of the original signedData object requesting the signedData/Receipt to verify that the recipient received and was able to verify the signature of the original signedData object including the content and authenticatedAttributes. This will also allow the originator of the original signedData object to verify the integrity and authenticity of the authenticatedAttributes of the signerInfo containing the signedData/Receipt signature value. The meeting attendees agreed with this proposal with one minor enhancement recommended by Jim Schaad. A separate message will be sent to the S/MIME WG mail list proposing the exact text for inclusion in ESS, Section 2.4.


SMIME - Secure Interoperability Across Protocol Gateways

Attendees List

go to list

Previous PageNext Page