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 . 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. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++