2.6.6 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98

Chair(s):

Russ Housley <housley@spyrus.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortel.ca>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:ietf-smime@imc.org
To Subscribe: ietf-smime-request@imc.org
Archive: http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group will define MIME encapsulation of digitally signed and encrypted objects whose format is based on PKCS #7. [1] X.509 Certificates and CRLs as profiled by the existing PKIX Working Group will be used to support authentication and key management. The Working Group will base its work on the S/MIME version 2 specification (available from RSA Data Security), but the Working Group will be free to change any part of that specification. In particular, the Working Group will prepare a new document that allows algorithm independence, based on PKCS #7 1.5.

The message syntax specification, based on PKCS #7 version 1.5, will be expanded to allow additional key signature and key exchange algorithms. The message and certificate specifications will be revised to allow them to become standards. The optional security extensions document will specify protocols that allow for additional security features, such as signed message receipts.

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, particularly in specification of cryptographic algorithms and MIME structure.

[1] RSA Data Security publishes the PKCS Series of documents. RSA Data Security has permitted the IETF to publish them as Informational RFCs as well as to extend and enhance them.

Goals and Milestones:

Nov 97

  

Submit First draft of message syntax specification as an I-D.

Nov 97

  

Submit First draft of S/MIME v3 message specification as an I-D.

Nov 97

  

Submit First draft of S/MIME optional security extensions as an I-D.

Nov 97

  

Submit First draft of S/MIME v3 certificate specification as an I-D

Dec 97

  

WG Last Call on Message Syntax.

Dec 97

  

WG Last Call on Certifiticate Specification.

Dec 97

  

WG Last Call on Message specification.

Jan 98

  

WG Last Call on Optional Security Extensions.

Jan 98

  

Submit Message Syntax I-D to IESG for consideration as a Proposed Standard.

Jan 98

  

Submit S/MIME v3 message specification I-D to IESG for consideration as a Proposed Standard.

Jan 98

  

Submit S/MIME v3 certificate specification I-D to IESG for consideration as a Proposed Standard.

Feb 98

  

Submit S/MIME optional security extensions I-D to IESG for consideration as a Proposed Standard.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2311

  

S/MIME Version 2 Message Specification

RFC2312

  

S/MIME Version 2 Certificate Handling

Current Meeting Report

IETF S/MIME Working Group
Orlando, Florida, USA
9 December 1998

Reported by Jim Schaad

All briefing slides are stored at: ftp://ftp.ietf.org/ietf/smime/.

Introductions - Russ Housley

Russ reviewed the agenda. Nobody objected the agenda.

CMS Draft Discussion - Russ Housley

Russ presented the current status on the CMS draft. The document is currently in Working Group last call and will remain there until the X9.42 draft has finished its last call. The majority of the comments since the last meeting have focused on Section 12. (This is the section on algorithms and key wrapping support.) The comments received to date have been incorporated in draft 10 which should be distributed soon.

Key Wrapping Algorithm: Several changes have been made to the key algorithm and some comments on it have been received since the last WG meeting. The algorithm has been found to be unsecure with stream cipher algorithms and block ciphers in OFB mode. A statement to this effect will be placed in the document.

Russ stated that several people have asked for a modification to the check sum algorithm be made. People are worried about the arithmetic nature of the algorithm. Additionally, there was a question on moving from 16 to 32 bits in size. Russ reviewed the key wrap and unwrap algorithms as part of this discussion.

Several people indicated that they felt better using the left-most bits of a SHA-1 hash rather than the current Fletcher checksum. However, if the change was made, the checksum size should be increased to 32 bits. Jim Schaad raised a potential problem in that moving to 32 bits changed the block alignment. (32 bits of salt and 32 bits of checksum make a full 8 octet Triple-DES or RC2 block, thus a full block of pad will be needed.) After a fair amount of discussion, the WG decided to change the checksum algorithm to the left-most 64 bits of the SHA-1 hash of the key material. This takes advantage of the one-way nature of SHA-1 and provides a longer integrity check value without increasing the size of the wrapped key.

Russ stated that several people has requested that once the CMS drafts are finished a four week rather than the normal two week IETF last call be requested. This request was based on the fact that the algorithms really need to have a wider review before being placed in proposed standard form. The WG concurred.

Russ then asked for any other unresolved issued on CMS.

Jim Schaad brought up the question of placing Subject Key Identifier (SKI) into the SignerInfo structure. Jim proposed that the SKI be added to CMS, however a statement be added to MSG that only the issuer and serial number choice may be used in S/MIME version 3. A discussion followed where two possible uses of SKI would be of use. The first would be to allow for PGP keys to be referenced in a CMS object. The second related to the Certificate Management over CMS (CMC) internet-draft in the PKIX working group. After some discussion the proposal was adopted by the working group.

Denis Pinkas raised an issue that he thought section 5.6 (signature verification process) was confusing and he had posted a message to this effect. Russ requested that he repost the message to the list.

X9.42 Draft Discussion - Eric Rescorla

Eric next presented the changes and plans for the X9.42 draft. Text has been included in the draft to provide a standard way to produce the group parameters for q >= 160. A statement that q must be at least 160 is being included into the draft. With this set of changes the draft should be ready for WG last call.

CERT Draft Discussion - Paul Hoffman (for Blake Ramsdell)

Paul presented this and the CERT draft discussion on behalf of Blake who was unable to make the meeting. Paul stated that only minor changes have been made to the drafts since the last meeting. The most significant of these dealt with making some terms about entities clearer and more consistent. Paul stated that no new draft has been posted since the last working group meeting but one should be expected soon.

An issue was raised that the last paragraph in section 3.1 is now redundant as the NULL Subject DN on end-entity certificates is no longer permitted by the PKIX documents.

MSG Draft Discussion - Paul Hoffman (for Blake Ramsdell)

Paul stated that no significant changes have been made to the MSG draft since the last meeting. The most significant editorial changes have been clarification about attribute counts in section 2.5, text clarification on section 2.5.3 and a change to the Triple-DES reference. An updated draft should be posted soon.

ESS Draft Discussion - Paul Hoffman

Paul stated that no significant changes have been made to the ESS draft since the last meeting beyond the inclusion of the SigAttr section. Paul stated that he would do some rewrites on the introduction to make it easier to find the assorted attributes which have been added to the draft.

Issues raised from the floor on the ESS draft were:

1) Denis Pinkas requested that the Signature Cert attribute be moved from the ESS draft to the CMS draft. He stated that this attribute is needed in order to be able to make a clear statement on signature verification. After some discussion a straw poll was taken on the placement of the attribute with a majority preferring to keep the attribute in the ESS draft.

2) Andrew Farrell stated that section 4.2.2 was missing from the numbering.

3) Andrew Farrell stated that there appeared to be a large amount of redundancy between the processing of secure receipts in the subsections of 4.2.3. Paul explained that his opinion was that the text would be harder to read if the three different cases were collapsed into a single section.

CERTDIST Draft Discussion - Jim Schaad

Jim stated that no significant changes have been made since the last WG meeting. Following the successful progression of the other drafts and final edits to the Security Considerations section the document will move to WG Last Call.

Two issues were raised from the floor:

1. Andrew Farrell raied two content issues: Need an OID for the LDAP schema and section 4.4 has an error in the flow chart.

2. Andrew Farrell requested that an example to be added as a new appendix.

DOMSEC Draft Discussion - Bill Ottaway

Bill stated that changes to the draft included the inclusion of multiple signature types were added to the draft and clarification of the text on parallel and encapsulated signatures were added.

Several issues were raised from the floor:

Eric Rescorla made a statement about a problem with parallel signatures where an entity could remove the originator signature and substitute their own. Bill said he would take this comment under advisement.

Bill then asked for guidance if the draft should go to informational or standard track. Paul Hoffman suggested that the appropriate place may be experimental unless others are going to implement. A straw poll of the group favored moving the draft to experimental. The WG agreed that if a significant number of implementors emerge, then it can be moved to the standards track.

Request: CEK Key Mgmt - Frank Siebenlist

Frank made a presentation about a request to modify CMS to allow for the use of a shared content-encryption key (CEK) without the overhead of wrapping with a key-encryption key (KEK). This would allow session based protocols (such as TLS) to use CMS as a building block. As part of this presentation a set of suggested ASN.1 changes to accomplish this were presented.

Eric Rescorla raised immediate concerns that it is not good practice to re-use an CEK especially in a persistent storage format. Many others agreed this was a problem. Frank responded that the change was only for session-based protocols and session-based protocols all suffered from this re-use "problem".

Jim Schaad presented an alternate method of doing what was desired by the creation of a new KEK algorithm which performed an identity transform from the KEK to the CEK and would require no changes to existing CMS draft. The proposal could then stand on its own merits. A straw poll showed the group favored this approach to the problem.

Open PGP Compatibility - Jon Callas

Jon made an argument that there were some changes that could be made to the CMS, MSG and CERT drafts which would allow for easy use of PGP keys to be used for wrapping CEKs. Specifically, if the MUST on usage of IssuerAndSerialNumber in MSG is relaxed to a SHOULD then the SKI option could reference PGP keys.

Eric Rescorla stated that while this would give a potential way of dealing with PGP keys, the message differences would still not be addressed and questioned if this should not be done all at once.

Paul Hoffman stated that allowing this would lead to backwards compatibility problems with existing S/MIME implementations as they could not correctly verify such signatures.

After some discussion the suggestion was made that a document should be presented to the group which identified all of the incompatibly issues and presented possible solutions that could be used to fix a sufficient set for interoperability. The WG concurred with this approach.

New Samples Document - Paul Hoffman

Paul made a presentation for the creation of a new document providing CMS examples. The overview of the document would be a short introduction, a basic example of each content type and advanced examples of different types. Consistent data on keys would be used through out the entire set of examples. The timing of this document is such that it would not be started until the CMS draft has moved to the RFC editors.

It was suggested that the document include some incorrect examples that flag common implementation errors. Paul agreed to add a section for these.

Paul is only going to coordinate putting this document together. If individuals would like to volunteer to do examples they should contact Paul at phoffman@imc.org.

ACTION ITEMS:
1. Change the Checksum algorithm in CMS (Russ Housley)
2. Add SKI to SignerInfo (Russ Housley)
3. Add SKI restriction to the MSG draft (Blake Ramsdell)
4. Require IssuerAndSerialNumber in SigAttr (Paul Hoffman)

Slides

Certificate Distribution Specification
Cryptographic Message Syntax (CMS)
Domain Security Services Using S/MIME
X9.42 Draft Changes
S/MIME Open Issues