Last Modified: 2003-01-23
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.
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 RFC 2632 and RFC 2633.
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) document.
In some situations it would be advantageous for the CMS RecipientInfo structure to support additional key management techniques, including cryptographic keys derived from passwords. Also, a mechanism to facilitate the definition of additional key management techniques will be defined.
Compressing data prior to encryption or signature has a number of advantages. Compression improves security by removing known data patterns, improves throughput by reducing the amount of data which needs to be encrypted or hashed, and reduces the overall message size. Enabling S/MIME version 3 to use compression will provide all of these advantages.
S/MIME version 3 permits 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.
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.
As part of S/MIME version 3, CMS is used to provide security to the message content. 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.
Perform necessary interoperability testing to progress the S/MIME version 3 specifications to Draft Standard. Due to the dependency of the CMS specification on the PKIX certificate and CRL profile, the timeline for the actual progression is impossible to estimate.
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. | |
MAR 00 | Submit mail list key distribution to IESG for consideration as a Proposed Standard. | |
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. | |
AUG 02 | Last call on CMS and ESS examples document. | |
SEP 02 | Submit CMS and ESS examples document as Informational RFC | |
OCT 02 | Sumbit update to RFC 2633 as Proposed Standard | |
OCT 02 | Sumbit update to RFC 2632 as Proposed Standard | |
OCT 02 | Last call on RSA PSS algorithm specification | |
NOV 02 | Last call on RSA KEM algorithm specification | |
DEC 02 | Sumbit AES algorithm specification as Proposed Standard | |
DEC 02 | Submit RSA OAEP algorithm specification as Proposed Standard | |
JAN 03 | Submit RSA PSS algorithm specification as Proposed Standard | |
FEB 03 | Submit RSA KEM algorithm specification as Proposed Standard |
RFC | Status | Title |
---|---|---|
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 |
Here are the minutes for the San Francisco meeting. Cheers - spt -------------------------------- Minutes for the S/MIME Meeting IETF 56 March 18, 2003 Agenda: 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 3394 Advanced Encryption Standard (AES) Key Wrap Algorithm. RFC Editors Queue: - symkeydist CMS Symmetric Key Management and Distribution With the IESG: - 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 - Use of the AES Encryption Algorithm in CMS. Progression to Draft Standard: Need to have two interoperable implementations (see report below) and all referenced documents advance to Draft Standard. For CMS to advance this means RFC 3280 (Certificate Profile) and RFC 3281 (V2 Attribute Certificate Profile) need to advance first. Russ then resigned as the chair of the S/MIME working group due to his promotion to the position of Security Area Director on the IESG. The new co-chairs of the working group are Blake Ramsdell (blake@brutesquadlabs.com) and Sean Turner (turners@ieca.com). Blake and Sean chaired the balance of the meeting. Message Update and Certificate Update Drafts: Blake Ramsdell gave a presentation on the progress of these two documents. The message draft has had a number of small changes between the -02 and -03 drafts. The document was put into working group last call after the last meeting. The comments on the list have not yet been incorporated into a published draft but that should be done soon. The certificate draft has had some minor changes in the extended key usage description and should go into working group last call in the near future. Examples Draft: Paul Hoffman said that there have been some new examples submitted for the draft; however these contained some personal email addresses so Paul has asked that they be regenerated. Areas of the document that do not currently have examples have been removed. When the new examples are placed in the document it should be ready for working group last call. CMS Interoperability Status: Jim Schaad stated that advancement has been made since the last meeting for CMS interoperability. Four items need to be tested, but implementers have been found for SignedData. The document describing the results of the interoperability testing has been started. This document should be ready for publishing before the next meeting. During the process of developing the matrix an error was discovered in the CMS ASN.1 module, an update has been submitted to the RFC Editor to supply the missing OIDs from the module. Eventually, an update to the RFC will be needed, perhaps when the document progresses to Draft Standard. RSA PSS: Jim Schaad presented two issues with the RSA PSS draft. The first dealt with whether the key identifier and signature identifier should use the existing OIDs or whether new ones should be assigned. The second dealt with PSS parameter comparisons. Paul Hoffman raised a concert about the reason for having the PSS draft, a second signature algorithm (DSS) is already documented by the working group. Russ Housley and others indicated that having a backup was the main reason, and this permitted a backup within the RSA family of algorithms. Blake Ramsdell then raised a concern over whether the working group is going to become a location for anybody to create a document for their favorite algorithm. Russ Housley indicated that this was within the scope of the group's charter. If interested in the RSA PSS outcome working group members are directed to comment on the PKIX mailing list (ietf-pkix@imc.org). SIP and SIPPING: Rohan Mahy, one of the co-chairs for the SIP working group, gave a presentation on how SIP/SIPPING are in the process of using S/MIME and CMS in the SIP protocol for providing origin authentication, integrity and confidentiality security services. These were added in a hurry to RFC 3261 just before adoption. Rohan was asking to get some help both for providing implementation assistance and advise on what should be specified in future documents from the groups. Camellia Draft: KATO Akihiro gave the presentation on the draft for Camellia to be used as a content encryption algorithm with CMS. Draft -01 contains two additional sections, one for S/MIME Capabilities and one for Key Wrap algorithm details. Some comments have been made on the -01 draft, after these are address the document should be ready for working group last call. Information on Camellia can be obtained at http//info.isl.ntt.co.jp/camellia. ESS Document Updates: Jim Schaad gave a brief description of a problem that has been identified with the ML Expansion History update in the ESS document. The problem is that this signed attribute currently addresses two different problems, the detection of loops during ML expansion and changing receipt generation behavior. This means that a work flow application cannot easily change the receipt behavior without appearing to be an MLA. The proposal is to split these two different requirements into separate signed attributes. An MLA would make use of both new attributes, but the work flow application would only make use of one of them. An update the ESS document (RFC 2634) is needed. Summary: - CERTbis, MSGbis, Examples, and Camellia drafts will undergo working group last call as soon as next versions are published. - ESS draft to be updated to address workflow issue. - SIP/SIPPING issues to be addressed by S/MIME mailing list. - RSA PSS signatures will be adopted as described in PKIX. |