Last Modifield: 05/07/2002
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.
| 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. |
| RFC | Status | Title |
|---|---|---|
| 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) |
This message includes the official minutes of the IETF S/MIME Working Group (WG) meeting held at the 55th IETF in November 2002 in Atlanta, GA, USA. Briefing slides will be available from <ftp://ftp.ietf.org/ietf/smime/>. Reported by Jim Schaad. ++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++ Introductions: Russ Housley covered the agenda for the meeting. No changes were made. ++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++ Working Group Status: Russ Housley covered the status of the active documents in the working group. The documents that have changed status since the last meeting are: Published as an RFC: - RFC 3369 - Cryptographic Message Syntax - RFC 3370 - Cryptographic Message Syntax (CMS) Algorithms - RFC 3394 - Advanced Encryption Standard (AES) Key Wrap Algorithm RFC Editors Queue: - There are currently no documents in the RFC Editor Queue IESG - CMS Symmetric Key Management and Distribution - Use of the RSAES-OAEP Transport Algorithm in CMS - Transporting S/MIME Objects in X.400 - Securing X.400 Content with S/MIME - Wrapping an HMAC key with a Triple-DES Key or an AES Key ++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++ Examples Draft: Paul Hoffman was unable to be present, so Russ presented for him. There has been a recent discussion on the list that a triple-wrap example as defined in ESS (RFC 2634) should be added to the draft. John Pawling has volunteered to provide this example. After it is incorporated the document, and a few minor edits are made, the Examples Draft should be ready for working group last call. ++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++ X400 Transport and Wrap Drafts: Chris Bonatti gave the presentation for these two drafts. There were some comments from the IESG on the documents, and some synchronization between the RFC2633bis Draft and X.400 Wrap Draft was needed. The IESG comments have been resolved, and the two S/MIME working documents are now consistent. The X.400 Transport and Wrap Drafts are ready for the IESG. Chris is trying to coordinate a review of the documents by the ITU-T group responsible for X.400, but this should not stop the draft from going to Proposed Standard. Any comments from this group can be incorporated before going to Draft Standard. ++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++ AES Algorithm Draft: Jim Schaad stated that the document has been modified to remove the requirement that AES is not to be used with PKCS #1 v1.5. The document will be submitted as soon as the repository opens, and then the chair will make the working group last call. ++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++ CMS & ESS Interoperability Status: Jim Schaad stated that advancement has been made since the last meeting for CMS interoperability. There are 6 test cases left to complete interoperability testing. These test cases deal with: 1) v2 attribute certificates for SignedData and EnvelopedData; 2) unrecognized SignerInfo structures; 3) unrecognized RecipientInfo structures; and 4) version numbering in EnvelopedData for pwri and/or ori being present as a RecipientInfo. The v2 attribute certificate test cases should be finished soon as a bug is found and fixed in one implementation. There was a discussion dealing with two issues found during interoperability testing. The first dealt with the fact that so far no implementations are known that deal gracefully with unknown RecipientInfo and SignerInfo structures. No discussion was generated from the floor. The second issue dealt with the fact that there is no MUST statement on handling of detached as opposed to embedded content. Both detached content and embedded content are mandated by the S/MIME message specification (RFC 2633) for SignedData, and embedded content is mandated for EncryptedData. Should this be moved into the CMS draft as well? No discussion from the floor ensued. ++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++ Camellia Draft: KATO Akihiro gave the presentation on the draft for Camellia to be used as a content encryption algorithm with CMS. Camellia operations at the same block and key sizes as AES. Camellia will use the AES key wrap algorithm for doing key encryption. The authors are going to be adding a section on SMIMECapabilities before the next revision. Information on Camellia can be gotten at http//info.isl.ntt.co.jp/camellia ++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++ Message Update Draft: Blake Ramsdell was unable to make it to the meeting. Russ presented Blake's slides for him. The current draft was modified to deal with allowing for binary transport internally, signing message headers and using the compression content type. Following the presentation the chair stated that the document should be ready to progress and a last call will be issued shortly. ++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++ Certificate Update Draft: Russ also presented the certificate draft updates for Blake. The changes in the last draft are changes to the wording for email address matching and to deal with the nonRepudiation/digitalSignature bits in the key usage certificate extension. There are still some additional changes are needed to resolve previously submitted comments. Also, there are some TBA areas in the draft. ++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++ IESG status of HMAC Key Wrap draft: Jeff Schiller was asked to give further information about the current status of the HMAC Key Wrap draft which is currently stuck at the IESG. The issue has to do with the fact that the working group requested publication as an Informational RFC, which for advancement purposes is really below Proposed Standard for purposes of advancement. Thus any document that relied on it could not go forward. Russ said that this has been historically what has been done by this working group; document describing algorithms are informational, while documents describing how to use the algorithms are standards track. Jeff is going to attempt to get the problem solved on a basic level, however the working group granted permission to move the document to standards track if it appears that solving the basic problem is going to take too long. ++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++ |