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