Last Modified: 2003-10-13
The Cryptographic Message Syntax (CMS) (RFC 3369) 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 CERT and MSG (RFC 2632 and RFC 2633). Building on the CMS CompressedData content type specified in RFC 3274, the update to MSG will specify conventions for message compression, in addition to message signature and encryption.
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) (RFC 2634) document.
CMS, and thus S/MIME version 3 and later, permit 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.
In S/MIME version 3 and later, CMS is used to provide security to the message content if an Internet mail message. However, 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.
The working group will perform necessary interoperability testing to progress the S/MIME specifications to Draft Standard. The CMS specification depends on the RFC 3280, the PKIX certificate and CRL profile. This profile must progress to Draft Standard before CMS and the other S/MIME specification can progress to Draft Standard. Assuming timely progress by the PKIX Working Group, the S/MIME specification can start progressing to Draft Standard toward the end of 2003.
| 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. | |
| 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. | |
| Done | Submit mail list key distribution as a Proposed Standard | |
| Done | Submit X.400 CMS wrapper specification as a Proposed Standard | |
| Done | Submit HMAC key wrap description as Proposed Standard | |
| Done | Submit RSA OAEP algorithm specification as Proposed Standard | |
| Done | Sumbit AES algorithm specification as Proposed Standard | |
| Done | Submit X.400 transport as a Proposed Standard | |
| Done | Last call on CMS and ESS examples document | |
| Apr 03 | Sumbit update to MSG as Proposed Standard | |
| Apr 03 | Sumbit update to CERT as Proposed Standard | |
| Done | First draft of RSA KEM algorithm specification | |
| May 03 | Submit CMS and ESS examples document as Informational RFC | |
| Jun 03 | Last call on RSA PSS algorithm specification | |
| Jul 03 | Last call on RSA KEM algorithm specification | |
| Sep 03 | Submit RSA PSS algorithm specification as Proposed Standard | |
| Oct 03 | Submit RSA KEM algorithm specification as Proposed Standard | |
| Oct 03 | Final S/MIME version 3.1 interoperability matrix | |
| Nov 03 | Request advancement of CMS Algorithms to Draft Standard | |
| Nov 03 | Request advancement of CMS to Draft Standard | |
| Dec 03 | Request advancement of ESS to Draft Standard | |
| Dec 03 | Request advancement of CERT to Draft Standard | |
| Dec 03 | Request advancement of MSG to Draft 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 |
| RFC3537 | PS | Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES)Key |
| RFC3560 | PS | Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS) |
| RFC3565 | PS | Use of the Advanced Encryption Standard (AES)Encryption Algorithm in Cryptographic Message Syntax (CMS) |
IETF 58th Meeting Hilton Hotel - Minneapolis, Minnesota SMIME WG 11 November 2003, 1700-1800 INTRODUCTION The meeting was chaired by Blake Ramsdell of Brute Squad Labs. The other co-chair, Sean Turner of IECA, was unable to attend. Approximately 40 participants were in attendance. The Chairman introduced the agenda. There were no comments on the agenda from the WG. He acknowledged that Chris Bonatti agreed to serve as note-taker. He asked for an official XMPP scribe, but there were no volunteers. So the Chairman suggested that anybody using XMPP act on their own recognizance to highlight important statements over that service. WG STATUS The Chairman gave an update of the status of WG activities. He reported the following: There are two newly completed RFCs: - RFC 3560: Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS), Russ Housley, July 2003. - RFC 3565: Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS), Jim Schaad, July 2003. Reported that four I-Ds were approved and were now in the RFC Editor's Queue: - draft-ietf-smime-camellia-05 - draft-ietf-smime-symkeydist-09 - draft-ietf-smime-x400wrap-09 - draft-ietf-smime-x400transport-09 WG Last Call coming up again on: - draft-ietf-smime-rfc2632bis-04 (Son-of-CERT) - draft-ietf-smime-rfc2633bis-06 (Son-of-MSG) - draft-ietf-smime-examples-12 Up and coming drafts include: - draft-ietf-smime-cms-rsa-kem-01 - draft-ietf-smime-gost-00 New draft coming in soon: - draft-park-cms-seed-00 Completed milestones - Submittted x400wrap and x400transport drafts Open Milestones - Complete rfc2632bis and rfc2633bis - Complete examples draft - Develop draft on RSA PSS algorithm Longer Term - WG Last Call on RSA KEM - Submit RSA KEM - Final S/MIME version 3.1 interoperability matrix New Milestones - SEED - GOST EXAMPLES Paul Hoffman reported on the update to the CMS and ESS Examples draft. He noted that major revision was performed since Vienna. Essentially we admitted that we were in denial about a lot of the examples, and so rethought the scope so that it took at least two working implementations to include the case. Thus many examples were deleted. There are still some outstanding comments from Jim Schaad noting some bugs in the code. These should be resolved shortly. He noted that comments are still welcome. At least one comment outstanding. MSGbis and CERTbis Blake Ramsdell reported as the editor of MSGbis and CERTbis drafts. He noted numerous changes from Jim Schaad (mostly editorial) had been integrated into the document. He noted that he still needs to clear up the "I-D Nits" issues (i.e., splitting references, etc.). He also noted that he is waiting for a secondary validation of hex dump. Jim Schaad is looking at this, but additional comments from others would be helpful. He noted that there was a new issue on definition of smimeCapabilities attribute values for the RC2 algorithm. It is not clear that these are defined anywhere. Ideally, we would like to have this elsewhere, but since it's kind of an afterthought we're going to have to squeeze it into MSG. Another new issue that has been discussed on the list is the guidance text on selection encryption algorithm. There was some obsolete language that dealt with weaker algorithms. Ramsdell indicated that he was revising text to update the decision tree to lead you instead to 3DES. Another new issue was clarification of the semantics of the smime-type subtype. The smime-type is indicated an attribute on the Content-Type MIME header. Current values defined in MSG include signed-data, enveloped-data, compressed-data, and certs-only. The question is, what is the right way to use this. - As a hint for IMAP? - As a content hint for processing? Ramsdell stated that he believed this should really reflect the outermost wrapper that must first be processed. Chris Bonatti stated that he didn't have an answer to this question, but pointed out that the x400wrap and x400transport drafts added some new values of smime-type for signed-x400 and encrypted-x400. While these clearly address more than just the outer wrapper, they distinguish a different service and message spec than S/MIME per se so there is some value. Indicating that he was an e-mail implementer, DABOO stated that he does not want to have to decode the entire content to know what kind of visual indicator to present, but he does not think that these two things are separate. Jim Schaad indicated that what brought this issue up is the ambiguity of signed receipts. In the instance of a signed-receipt that is also encrypted, which smime-type value should be used: the signed-receipt (defined in RFC 2634) or encrypted-data (as per the MSG spec)? Somebody (Blake?) noted that they have the same issue with the SIP WG, in that they want to easily identify data that contains SIP so that they can further process them. The chairman noted that he was not sure whether the Application Area should be consulted before deciding this matter. The WG tentatively agreed that the strawman solution is that smime-type is more a display hint than a processing hint, and that we will clarify this in the document. More discussion on the list is possible. Ramsdell noted that there is a PKIX issue that may require clarifications to the language regarding the subjectKeyIdentifier (SKI), and that he is not clear what the outcome should be. The problem is that use of the SKI to identify certificates is not sufficiently unique by itself. The reason for this seems to be that some implementations may issue crappy SKIs that are short, locally incremented identifiers. We need to add language to clarify that certificate processing when identified with SKI should: - Be prepared for matching multiple certificates; - Be prepared for some of those candidate certificates to fail. This would help implementations to bullet-proof against failing in what is a predictable scenario. Russ Housley, the Security Area Director, stated that he agreed with most of this, but indicated that we should preface this new text with the statement that if the recommendations of RFC 3280 are followed (i.e., SKI is the hash of the public key) then the overlap of these identifiers is possible but unlikely. This text is required mainly because that recommendation is a SHOULD instead of a MUST. Ramsdell also indicated that he had made several minor updates to the CERTbis document. He reported that he has added differences since 3.0 certificate profile to the document. He has also added credits and minor editorial fixes. PSS STATUS Jim Schaad reported that he has finished the edits of the PKIX version of PSS. This S/MIME PSS draft should be completed shortly. He also indicated that the Interoperability Matrix entries for CMS and CMSALG are finished. He still needs to do some editorial work to clean up the document. The ESSbis issue is still alive, but there has been no recent movement. KEM STATUS The Chairman reported speaking to Burt Kaliski of RSA, and noted that the KEM draft is temporarily stalled. The KEM draft is based on ANSI X9.44, which has not yet stabilized its ASN.1 syntax. The KEM draft cannot progress to RFC status until relevant X9.44 areas are stabilized. GOST STATUS The Chairman reported that the GOST draft is being updated and will be posted after the meeting. The new draft will add normative references to CMS and Russian law. He noted there are still some additional comments that need to be taken care of. Normative reference to CPALGS is a problem. The GOST algorithm needs to be described in an international standard, national standard, or RFC. An informational RFC would be easiest. Russ Housley stated that he thinks they are aiming to provide such an informative RFC for the Seoul meeting. Paul Hoffman pointed out that making it an RFC makes things a lot easier than the alternatives. Ramsdell and Housley agreed. Another issue is ASN.1 modules. The -00 draft uses the X.680 version of ASN.1, and needs to switch to X.208-88 to align with the rest of S/MIME. There are also too many modules in the draft. There were six modules in the -00 version, and will be 5 in -01, but they can still be further merged. SEED STATUS Jongwook Park from KISA gave a presentation introducing the SEED algorithm. He noted that SEED is based on a Feistel structure with 16 rounds. It has a 128-bit blocksize, and employs a 128-bit key. He proposed publishing the SEED algorithm description as an informational RFC prior to the Seoul meeting. All the documentation is available now from http://www.kisa.or.kr/seed/index.html. He invited comments from the WG. Park also noted that we should watch for feedback from ISO/IEC JTC1 SC27. The Chairman asked whether SEED was currently being considered by ISO. Park indicated that it was. He noted that he does not attend the ISO meetings, but some of his colleagues do. Ramsdell asked whether ISO has assigned OIDs for the algorithm. Park indicated that they have not. He stated that they were examining the strength of the algorithm, but there had been no results yet. Russ Housley asked whether SEED was the Korean national algorithm. Park responded that SEED was mandatory in |