Current Meeting Report

2.6.4 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/07/2002

R. Housley <>
Security Area Director(s):
Jeffrey Schiller <>
Steve Bellovin <>
Security Area Advisor:
Jeffrey Schiller <>
Mailing Lists:
General Discussion:
To Subscribe:
Description of Working Group:
The S/MIME Working Group has completed five Proposed Standards that comprise the S/MIME version 3 specification. Current efforts build on these base specifications.

The use of Diffie-Hellman Key Agreement as the mandatory to implement key establishment mechanism may expose some implementations to vulnerabilities based on "small subgroup" attacks. An informational document will be prepared describing techniques that can be used to avoid these attacks.

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. An additional suite of 'mandatory to implement' algorithms may be selected.

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

Current methods of publishing certificates in the Directory do not allow the inclusion of secondary support information such as the SMimeCapabilities attribute. A method of publishing certificates along with authenticated secondary support information will be defined.

In some situations it would be advantageous for the CMS RecipientInfo structure to support additional key management techniques, including cryptographic keys derived from passwords. A mechanism to facilitate the definition of additional key management techniques will be defined. S/MIME version 3 permits the use of previously distributed symmetric key-encryption keys. Specifications for the distribution of symmetric key-encryption keys to mmultiple message recipients will be developed. Mail List Agents (MLAs) are one user of symmetric key-encryption keys. The specification will be cryptographic 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.

S/MIME version 3 can be used to protect electronic mail to and from a domain. In such an environment, S/MIME v3 processing is performed by message transfer agents, guards, and gateways in order to provide "Domain Security Services." Mechanisms are needed to solve a number of interoperability problems and technical limitations that arise when domains supporting different security policies wish to interoperate.

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.

Goals and Milestones:
Done  First draft of CMS RecipientInfo extension.
Done  First draft of security label usage specification.
Done  First draft of CAST algorithm specification.
Done  Last call on KEA and SKIPJACK algorithm specification.
Done  Last call on small subgroup attack avoidance
Done  First draft of mail list key distribution.
Done  Last call on certificate distribution specification.
Done  Updated draft of domain security services document.
Done  Last call on CAST algorithm specification.
Done  Submit small subgroup attack avoidance as Informational RFC
Done  Submit KEA and SKIPJACK algorithm specification as Informational RFC.
Done  Last call on security label usage specification.
DEC 99  Last call on CMS and ESS examples document.
Done  Last call on IDEA algorithm specification.
Done  Last call on CMS RecipientInfo extension.
JAN 00  Last call on mail list key distribution.
JAN 00  Submit certificate distribution specification to IESG for consideration as a Proposed Standard.
FEB 00  Submit security label usage specification as Informational RFC.
Done  Submit CAST algorithm specification as Informational RFC.
MAR 00  Submit CMS and ESS examples document as Informational RFC.
MAR 00  Submit CMS RecipientInfo extension to IESG for consideration as a Proposed Standard.
MAR 00  Submit mail list key distribution to IESG for consideration as a Proposed Standard.
Done  Submit IDEA algorithm specification as Informational RFC.
Done  Last call on domain security services document.
SEP 00  Submit domain security services as Experimental RFC.
  • - draft-ietf-smime-seclabel-04.txt
  • - draft-ietf-smime-symkeydist-07.txt
  • - draft-ietf-smime-cms-rsaes-oaep-03.txt
  • - draft-ietf-smime-x400transport-04.txt
  • - draft-ietf-smime-x400wrap-04.txt
  • - draft-ietf-smime-aes-alg-04.txt
  • - draft-ietf-smime-rfc2630bis-08.txt
  • - draft-ietf-smime-cmsalg-08.txt
  • - draft-ietf-smime-aes-keywrap-00.txt
  • - draft-ietf-smime-hmac-key-wrap-00.txt
  • - draft-ietf-smime-rfc2632bis-01.txt
  • - draft-ietf-smime-rfc2633bis-01.txt
  • Request For Comments:
    RFC2312 I S/MIME Version 2 Certificate Handling
    RFC2311 I S/MIME Version 2 Message Specification
    RFC2631 PS Diffie-Hellman Key Agreement Method
    RFC2634 PS Enhanced Security Services for S/MIME
    RFC2630 PS Cryptographic Message Syntax
    RFC2633 PS S/MIME Version 3 Message Specification
    RFC2632 PS S/MIME Version 3 Certificate Handling
    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)

    Current Meeting Report

    This message includes the official minutes of the

    IETF S/MIME Working Group (WG) meeting held at the 54th IETF in July 2002 in Yokohama, Japan.

    Briefing slides will be available from

    Reported by Peter Yee.


    Introductions: Russ Housley covered the agenda for the meeting.
    No changes from the floor were offered or made.

    Introductions Russ Housley
    Working Group Status Russ Housley
    CMSbis Status Russ Housley
    MSGbis Update Russ Housley for Blake Ramsdell
    CERTbis Update Russ Housley for Blake Ramsdell
    X400wrap and X400transport Update Sean Turner for Chris Bonatti
    CMS and ESS Examples Update Russ Housley for Paul Hoffman
    Interoperability Matrix Update Jim Schaad
    AES Update Jim Schaad
    RSA-OAEP Update Russ Housley
    PGP Certificate Support Derek Atkins
    Wrap up Russ Housley


    Working Group Status: Russ covered the current status of the active documents in the working group. Changes in status since the last meeting are as follows.

    Published as an RFC:
    - 3278 April 2002. Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS). S. Blake-Wilson, D. Brown, and P. Lambert.
    - 3114 May 2002. Implementing Company Classification Policy with the S/MIME Security Label. W. Nicholls.
    - 3274 June 2002. Compressed Data Content Type for Cryptographic Message Syntax (CMS). P. Gutmann.

    RFC Editors Queue:
    - rfc2630bis Cryptographic Message Syntax. R. Housley
    - cmsalg Cryptographic Message Syantx (CMS) Algorithms. R. Housley
    - aes-keywrap AES Key Wrap Algorithm. J. Schaad and R. Housley.

    With the IESG for consideration:
    - x400wrap Securing X.400 Content with S.MIME. P. Hoffman, C. Bonatti, and A. Eggen.
    - x400transport Transporting S/MIME Objects in X.400. P. Hoffman and C. Bonnati.
    - symkeydist CMS Symmetric Key Management and Distribution. S. Turner.


    CMSbis Status: About to be published as a Proposed Standard. Blocked from going to Draft Standard until RFC 3280 progresses to Draft Standard.


    MSGbis Update: Changes from -00:
    o Minor editorial work
    o Clarified "certificate managment" vs. "certs-only" (message content has not changed, only clarified).

    Outstanding issues:
    o CompressedData use. Which comes first sign or compress? Should we expand SMIMECapabilities to indicate the compression algorithms that a recipient supports? Current thinking is to add compression as a MAY. Could be supported as a further profile of S/MIME or could use the SMIMECapabilities (which many implementations only handle process in conjunction with encrypted messages). Jim Schaad (Soaring Hawk) does not want compression for signed-only messages. Further, Jim believes that compression should be applied after signing. That is, the SignedData should be compressed.
    o Header field protection. Would like to protect the RFC 2822 headers. To do so, the full 822 messsage is wrapped and protected in S/MIME. Then, outer headers for the S/MIME message are added that suffice for message delivery.
    o Inner binary encoding? Triple-wrapped messages have considerable expansion due to Base-64 encoding for each layer of encapsulation. Is it acceptable only to Base-64 encode the outermost wrapper? S/MIME v2 used Base-64 encoding at each encapsulation because some older clients could not handle a binary transfer encoding type. If we use binary encoding for inner wrappers, there is a problem with some gateways that remove security layers, exposing the contents (such as DOMSEC). If the exposed MIME type is multipart, then the re-encoding could impact signature validation. The use of binary encoding is simply to reduce message expansion. How the inner binary encoding is used can be done by two ways, it can be done as a profile, or it can be communicated through SMIMEcapabilities. Jim Schaad pointed out that RFC 2633 currently requires support for binary encoding. Tim Polk (NIST) argued that it might cause interoperability problems, regardless of what the RFC decrees. Many implementations handle inner binary encoding. All implementers that responded to a S/MIME working group mailing list survey that was conducted several months ago indicated that their code could handle binary encoding. Further, no one expressed concerns in this area.


    CERTbis Update:
    o Must not used v1 Attribute Certificates -- PKIX already mandates v2.
    o MD2 security warning -- should not be used, but there are a few roots that use RSA-MD2
    o Minor editorial work

    Close to last call, so please get your inputs to Blake Ramsdell (Brute Squad Labs) or Russ Housley (RSA Labs), via the mailing list.


    X400wrap & X400transport Update: X.400 Wrap is analgous to the MSG document, and X.400 transport tells how to carry CMS objects via X.400 MTAs.

    The documents are with the IESG, and the IETF Chair has raised a few questions. These questions are answered in new versions that are out to the co-authors. They should be posted soon.

    One major issue:
    o Header field protection
    - Encapsulate the message (including headers) in message/rfc822 and protect that
    - Agree upon rules for merging inner/outer headers (inner protected and 822 headers must match!)
    - Indicator to signal header merging needed

    Documents are moving down the Standards Track, not Informational. The -05 drafts will be released by the authors, hopefully getting these documents closer to moving on.


    CMS and ESS Examples Update: New examples for inclusion in the document have been sent to Paul Hoffman. As soon as they are incorporated, a new version of the document will be posted. All implementers are asked to confirm that the examples produce the expected output.


    Interoperability Matrix Update: Needs to be updated for rfc2630bis and cmsalg (which are in the RFC Editor's Queue).

    No recent implementer updates to the CMS information. The CMS Algorithms portion of the matrix is very close (HMAC/SHA-1 is outstanding).

    The SignedData portion has 6 items to go, and the EnvelopedData portion has 10 items to go.

    Paul Hoffman (IMC) has offered to coordinate interoperability testing


    AES Update: Separated the AES and OAEP drafts. The AES Keywrap is in the RFC Editor's Queue. One open issue remains in the AES for CMS draft. The mailing list constituency seems to want to allow RSA PKCS#1 v1.5 to wrap an AES key. Jim Schaad does not want to allow this pairing.

    o Keep MUST NOT (disallow this pairing)
    o Change MUST NOT to MAY (with author's comment against doing the MAY)
    o CHANGE to MAY and update SMIMECapabilities to allow for pairing information

    Those present felt that MUST NOT was preferred, but the mailing list will be polled again for a final input. The draft will be posted at the end of the week, and once this one decision is made, the document will be ready for working group last call.


    RSAES-OAEP Update: Separated from the merged AES-OAEP document. Other separate but somewhat related documents are AES for CMS, RSA-KEM key transport, and RSA-PSS digital signature. The current (-03) draft of RSAES-OAEP was posted June 2002. Russ went over the structure of the new draft. A couple of questions were raised:

    o Is it okay to use the same RSA public/private key for RSAES-OAEP and other things.
    -- Not suggested.
    o Is RSAES-OAEP with SHA-1 secure for key transport of AES keys?
    -- SHA-1 used with 1024-bit RSA public key provides the equivalent of 80-bit symmetric key, with respect to signatures. This comparison is not so straightforward for key transport. However, Burt Kaliski and others feel that the signature relationship is a low watermark for key transport, so for AES key transport, SHA-1 is not suggested. Thus, SHA-256, SHA-384, and SHA-512 will be added to ASN.1 module and suggested for use, but leave SHA-1 as the MUST implement. Also, the updated draft will require RSA keys to be at least 1024 bits.

    Working group last call, with the additions suggested above, would come in August 2002.


    PGP Certificate Support: Derek Atkins (IHTFP Labs) suggested that with many PGP Certificates out there and many S/MIME clients, the combination of the two might be useful. Essentially, this would be a binding of PGP keys to be used in S/MIME messages (the converse is being worked in the PGP working group).

    In a straw poll, only one person thought that the support for PGP certificates should not be investigated. Many others thought that an internet-draft should be developed.



    CMS Interop Matrix
    AES in CMS
    CMS-X.400 Drafts: Status & Issues