Current Meeting Report
2.5.7 S/MIME Mail Security (smime)
NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It
may now be out-of-date. Last Modified:
Russ Housley <firstname.lastname@example.org>
Security Area Director(s):
Jeffrey Schiller <email@example.com>
Marcus Leech <firstname.lastname@example.org>
Security Area Advisor:
Jeffrey Schiller <email@example.com>
To Subscribe: firstname.lastname@example.org
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
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
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
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
OpenPGP Working Group in areas where the work of the two groups
Goals and Milestones:
|Done||  || First draft of CMS RecipientInfo extension.|
|Done||  || First draft of security label usage specification.|
|Done||  || Last call on small subgroup attack avoidance|
|Done||  || First draft of CAST algorithm specification.|
|Done||  || Last call on KEA and SKIPJACK algorithm specification.|
|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.|
Request For Comments:
|RFC2311|| ||S/MIME Version 2 Message Specification
|RFC2312|| ||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|| ||Methods for Avoiding the 'Small-Subgroup' Attacks on
the Diffie-Hellman Key Agreement Method for S/MIME
|RFC2876|| ||Use of the KEA and SKIPJACK Algorithms in CMS
|RFC2984||PS||Use of the CAST-128 Encryption Algorithm in CMS
|RFC3058|| ||Use of the IDEA Encryption Algorithm in CMS
|RFC3125||E ||Electronic Signature Policies
|RFC3183||E ||Domain Security Services using S/MIME
|RFC3126|| ||Electronic Signature Formats for long term electronic
|RFC3185||PS||Reuse of CMS Content Encryption Keys
|RFC3217|| ||Triple-DES and RC2 Key Wrapping
|RFC3211||PS||Password-based Encryption for SMS
|RFC3218|| ||Preventing the Million Message Attack on CMS
Current Meeting Report
This message includes the official minutes of the IETF S/MIME Working Group (WG) meeting held at the 53nd IETF in March 2002 in Minneapollis, MN, USA. Briefing slides will be available from <ftp://ftp.ietf.org/ietf/smime/>. Reported by Jim Schaad and Russ Housley.
Introductions: Russ Housley covered the agenda for the meeting.
No changes were made.
Introductions Russ Housley
Working Group Status Russ Housley
CMS Update Status Russ Housley
MSG and CERT Update Status Russ Housley for Blake Ramsdell
X400wrap and X400transport Chris Bonatti
Interoperability Matrix Jim Schaad
CMS and ESS Examples Paul Hoffman
Key Encapsulation Russ Housley
AES and RSA-OAEP Jim Schaad
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:
- Password-based Encryption for CMS is now RFC 3211
- RSA Million Message Attack is now RFC 3218
- Triple-DES and RC2 Key Wrapping is now RFC 3217
RFC Editors Queue:
- Use of ECC Algorithms in CMS
- Compressed Data Content Type for CMS
With the IESG for consideration:
- AES Key Wrap Algorithm
- CMS Symmetric Key Management and Distribution
- X400 Key Wrap
- X400 Key Transport
- CMS Update (a.k.a. rfc2630bis)
- CMS Algorithms
CMS Updates: The rfc2630bis and CMSalg documents were updated in February to address issues raised by the IESG. These changes should address all of the issues, but we are still waiting for a response from the IESG. The rfc2630bis document relies on the Son-of-RFC2459 and ac509prof drafts; both documents are in the RFC Editor's queue. The updated CMS documents should be able to be published as soon as the IESG approves the document.
S/MIME Message and Certificate Updates: Blake Ramsdell was unable to attend the meeting, so Russ presented the material that Blake prepared. The -00 draft of the updates was recently published. This draft included the algorithm updates required by the removal of mandatory algorithms from rfc2630bis.
Items to be addressed in upcoming versions of this document are:
- Header leakage issues: Specify the means to protect the subject and other RFC 822 header items be protected by encryption and signature operations, and specify the merging of duplicate items.
- Clarifications of multipart/signed message construction: Several people have requested clarifications to this text.
- New issues: If there are any other issues, then they need to be raised on the list now.
X.400 Wrap and X.400 Transport: Chris Bonatti discussed the status of these two drafts. The authors are currently responding to a set of issued raised in IETF Last Call. The issues are:
- What references to MIXER [RFC 2156] are needed. Given the differences between the X.400 and Internet mail communities, the authors are not planning any major changes. However, they will explain what is possible and what is not possible.
- Allow the ITU-T to see the draft before it progresses. Paul Hoffman objected; it causes an indeterminate delay. Once it is published as an RFC, it can be given to the ITU-T for comment. If necessary, updates can occur during progression from Proposed Standard to Draft Standard.
- Merging of wrapped RFC 822 headers and RFC 822 headers on the message. This issue is similar to the issue in the rfc2633bis updates. The authors of the two drafts will coordinate these updates to make them compatible.
- The draft should address unprotected X.400 content in an SMTP transport. The authors are planning to address this issue in an updated draft.
The authors are planning to address these issues, except ITU-T review, in an upcoming draft. Hopefully, the IESG will consider these adequate responses.
Interoperability Matrix: Jim Schaad briefly discussed the current state of the matrix. With the advancement of the CMS drafts, the matrix needs to be reviewed for potential changes. The major current blocking issue is still the lack of a Version 2 Attribute Certificate. If anyone has one, please share it.
Jim is going to start looking at the issues that need to be addressed for the rfc2632bis and rfc2633bis drafts.
CMS/ESS Examples: Paul Hoffman briefly discussed the current state. New examples are being prepared by Jim to deal with the fact that two of the users have the same RSA private key. Once these are posted, please verify the examples.
Key Encapsulation: Russ presented a briefing on a new key management technique called "key encapsulation". This technique allows for RSA and Diffie-Hellman to be modeled in the same manner. For RSA this is known as RSA-KEM or Simple RSA. For RSA a random value (R) is encrypted in the recipient's public key, and then a key derivation function is applied to R to get the KEK. This technique is currently being presented to the IEEE P1363 and ANSI X9F1 standards bodies.
The suggestion is that we also adopt this for use with AES.
AES and RSA-OAEP Update: Russ and Jim spoke to this draft. Both of them think that going to RSA-KEM for AES is a good idea assuming that no patent issues surface. As a byproduct of this decision the RSA-OAEP draft would be revived and published as a historical RFC (there is at least one implementation).
The issues that need to be addressed before this can be resolved are:
- An AES based KDF needs to be defined. (Using AES for the KDF allows for hardware with just RSA and AES primitives.)
- Responses from the other standards bodies needs to be obtained, including estimates of how long it would take to standardize this algorithm.
- The ASN.1 structures and details need to be worked out.
The discussion of this proposal included the following:
- Charlie Kaufman had questions about the patent status of the approach. Russ replied that he did not know of any patents, but if any were found then he would recommend using RSA-OAEP rather than RSA-KEM. If anyone has any knowledge of patents in this area, please let us know.
- Paul Hoffman stated that based on talking to S/MIME vendors, he does not believe there is any current pressing need to publish AES the document. The performance increase resulting from a migration from Triple-DES to AES are not required since servers are not currently CPU bound. There is a major desire from the hardware vendors that IPsec and S/MIME use the same AES modes so only one set of hardware need to be designed.
- Jim Schaad brought up the fact that delay could potentially allow for the adoption of some new modes for parallelization and integrity checking. Numerous people mentioned the fact that there are major patent issues in the new modes.
Wrap Up: Russ Housley asked if there were any other issues to discuss. No additional issues were raised, and the working group meeting was adjourned.
Key Encapsulation: A New Paradigm for Public-Key Encryption
S/MIME CMS-X.400 Drafts: Status & Issues
Cryptographic Message Syntax (CMS) Status
S/MIME Working Group Status
S/MIME CERT and MSG