2.6.5 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99

Chair(s):

Russ Housley <housley@spyrus.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>

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 has completed five Proposed Standards that comprise the S/MIME version 3 specification. Current efforts build on these base specifications.

The use of Diffie-Hellman Key Agreement as the mandatory to implement key establishment mechanism may expose some implementations to vulnerabilities based on "small subgroup" attacks. An informational document will be prepared describing techniques that can be used to avoid these attacks.

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. An additional suite of 'mandatory to implement' algorithms may be selected.

To aid implementers, documents containing example output for CMS will be collected and published. Some of the examples will include structures and signed attributed defined in the Enhanced Security Services (ESS) document.

Current methods of publishing certificates in the Directory do not allow the inclusion of secondary support information such as the SMimeCapabilities attribute. A method of publishing certificates along with authenticated secondary support information will be defined.

In some situations it would be advantageous for the CMS RecipientInfo structure to support additional key management techniques, including cryptographic keys derived from passwords. A mechanism to facilitate the definition of additional key management techniques will be defined. S/MIME version 3 permits the use of previously distributed symmetric key-encryption keys. Specifications for the distribution of symmetric key-encryption keys to mmultiple message recipients will be developed. Mail List Agents (MLAs) are one user of symmetric key-encryption keys. The specification will be cryptographic 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.

S/MIME version 3 can be used to protect electronic mail to and from a domain. In such an environment, S/MIME v3 processing is performed by message transfer agents, guards, and gateways in order to provide "Domain Security Services." Mechanisms are needed to solve a number of interoperability problems and technical limitations that arise when domains supporting different security policies wish to interoperate.

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.

Goals and Milestones:

Jul 99

  

First draft of CMS RecipientInfo extension.

Jul 99

  

First draft of security label usage specification.

Aug 99

  

Last call on small subgroup attack avoidance

Aug 99

  

First draft of CAST algorithm specification.

Aug 99

  

Last call on KEA and SKIPJACK algorithm specification.

Sep 99

  

First draft of mail list key distribution.

Sep 99

  

Last call on certificate distribution specification.

Nov 99

  

Updated draft of domain security services document.

Nov 99

  

Last call on security label usage specification.

Nov 99

  

Last call on CAST algorithm specification.

Nov 99

  

Submit small subgroup attack avoidance as Informational RFC

Nov 99

  

Submit KEA and SKIPJACK algorithm specification as Informational RFC.

Dec 99

  

Last call on IDEA algorithm specification.

Dec 99

  

Last call on CMS and ESS examples document.

Dec 99

  

Last call on CMS RecipientInfo extension.

Jan 00

  

Last call on mail list key distribution.

Jan 00

  

Submit certificate distribution specification to IESG for consideration as a Proposed Standard.

Feb 00

  

Submit CAST algorithm specification as Informational RFC.

Feb 00

  

Submit security label usage specification as Informational RFC.

Mar 00

  

Submit CMS and ESS examples document as Informational RFC.

Mar 00

  

Submit CMS RecipientInfo extension to IESG for consideration as a Proposed Standard.

Mar 00

  

Submit IDEA algorithm specification as Informational RFC.

Mar 00

  

Submit mail list key distribution to IESG for consideration as a Proposed Standard.

Jul 00

  

Last call on domain security services document.

Sep 00

  

Submit domain security services as Experimental RFC.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2311

  

S/MIME Version 2 Message Specification

RFC2312

  

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

Current Meeting Report

Introductions - Russ Housley

Russ reviewed the agenda as follows. Nobody objected to the agenda.

Introductions Russ Housley
RFC 2630 - 2634 Status Russ Housley
Charter Revision Russ Housley
Small Subgroup Attack Mike Just
CERTDIST Draft Discussion Jim Schaad
DOMSEC Draft Discussion Bill Ottaway
CMS/ESS Examples Paul Hoffman
Security Policies and Labels Weston Nicolls
KEA and SKIPJACK Algorithms John Pawling
CAST-128 Algorithm Carlisle Adams
Elliptic Curve Algorithms Paul Lambert
ETSI Electronic Signatures Denis Pinkas
S/MIME Freeware Library John Pawling
Wrap up Russ Housley

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

RFC 2630-2634 Status - Russ Housley

Russ outlined the strategy for advancing the following RFCs from Internet Proposed Standards to Internet Draft Standards:
RFC 2630 Cryptographic Message Syntax, R. Housley, June 1999
RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999

The aforementioned documents must meet the following requirements to become Draft Standards:
1) Meet requirements documented in RFC 2026
2) Stable, mature, and useful specification
3) At least two independent and interoperable implementations from different code bases

Stable, Mature, and Useful:

Russ noted that no significant errors had been reported to the aforementioned RFCs.

Implementations:

Way Forward:

Paul Hoffman stated that another requirement for a Proposed Standard to become a Draft Standard is that all normative references to other RFCs must refer to Draft Standards. RFC 2632 includes a normative reference to RFC 2459 (Internet X.509 Public Key Infrastructure Certificate and CRL Profile), so RFC 2632 can not become a Draft Standard until RFC 2459 becomes one. Russ agreed with Paul's statement that a Draft Standard cannot include a normative reference to a document that has not achieved at least Draft Standard status. Russ agreed that since RFC 2632 relies on RFC 2459, then RFC 2459 will have to become a Draft Standard before or at the same time as RFC 2632.

Paul pointed out that each requirement must be implemented by at least two independent code bases such that they are interoperable, but a single code base does not need to implement all of the requirements. Russ agreed that the entire set of requirements could be implemented by a variety of sources. The matrices being initiated by Jim Schaad will indicate which features have and have not been implemented.

John Pawling asked if there were any plans to change the Attribute Certificate (AC) syntax used in RFC 2630. Currently, RFC 2630 imports the AC syntax from the 1997 X.509 Recommendation, but the draft IETF PKIX Attribute Certificate Profile Internet Draft specifies a different AC syntax. Russ pointed out that if RFC 2630 imported the AC syntax from the PKIX AC Profile, then RFC 2630 could not achieve Draft Standard status until the PKIX AC Profile achieved that status (which Russ believes will be at least six months). Russ stated that he believed that RFC 2630 should continue to import the AC syntax from the 1997 X.509 Recommendation because the other AC syntax is still not stable. He stated that the new features of the new AC syntax don't apply to RFC 2630. The new AC syntax allows for binding attributes to arbitrary objects identified by object identifiers. John pointed out that a new CMS specification could be drafted in the future which could include the new AC syntax once it is stable. Nobody disagreed with Russ' statement that the RFC 2630 AC syntax should not be changed.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Charter Revision - Russ Housley

Russ stated that the following work items have been approved since the July S/MIME working group meeting:

Russ stated that there is another proposed addition: CMS Compressed Proposed Standard RFC. 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. The proposed schedule is as follows: Oct 1999 - First Compression I-D. Jan 2000 - Compression Last Call. Apr 2000 - Compression Proposed Standard RFC.

Russ stated that both IETF Security Area Directors have expressed support for this addition.

Russ asked if any attendees knew of any issues, had comments or wshed to discuss any related topics, and no one raised anything. Russ asked if there were any patent concerns, and no one raised any patent concerns.

Paul Hoffman stated that the previous IP Compression working group had already worked on a compression standard and that the previous MIME working group had purposely avoided the issue of compression. Russ asked if the meeting attendees approved the addition of compression. The majority approved.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Small Subgroup Attack - Mike Just

Mike stated that there had not been a new draft of the "Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME" I-D since the last meeting. One minor comment was received regarding wordsmithing.

Russ asked if the attendees believed that the I-D was ready for working group last call. Nobody objected, so Russ asked that the aforementioned comment be incorporated into a new I-D and then that I-D would be submitted for last call. Russ asked that people please carefully review the I-D.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CERTDIST Draft Discussion - Jim Schaad

Jim discussed the Certificate Distribution Specification I-D (CERTDIST-04), October 20, 1999. He stated that "directory people" had criticized CERTDIST, but had not proposed an alternate solution. Russ noted that the directory folks were complaining because certificates are stored in the directory twice within different attributes. He said that they are concerned that the certificates stored within the two attributes will be different. He also said that they proposed that SupportedAlgorithms could be used. Jim pointed out that the SMIMECapabilities signed attribute could be used to point to a certificate rather than storing the entire certificate. Jim also stated that the method proposed in CERTDIST allows each certificate to claim different algorithm preferences.

Carlisle Adams asked if the SMIMECapabilities signed attribute is supposed to be tied to a specific certificate. Jim answered that SMIMECapabilities must be tied to a specific key management certificate.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

DOMSEC Draft Discussion - Bill Ottaway

Bill presented a briefing regarding the Domain Security Services Using S/MIME I-D (DOMSEC-03). Bill provided an overview of the DOMSEC concepts and the new features. The new features included: Naming conventions for signing and encryption, and the creation of a NULL signature when there is no originator signature present. Bill's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes the details regarding the issues and proposed solution for each new feature. Bill's goal is that DOMSEC should achieve RFC status in 2000. He would like DOMSEC to describe a solution that will work for a wide variety of organizations. He has received significant feedback from Baltimore, but would like to hear feedback from others.

Jim Schaad recommended that the domain name should be exactly matched. Jim also pointed out that RFC 2630 states that the content type should be id-data when there are no signers of a signedData object.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CMS/ESS Examples - Paul Hoffman

Paul stated that there has been much progress with the "Examples of S/MIME Messages" I-D and that almost all of the examples have been provided for incorporation into the document. He stated that there needs to be more testers of the sample data. He asked that folks please publicize their progress with verifying the sample data. Paul asked if there was any interest in a PKIX Examples Document. There was not much interest shown by the attendees.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Security Policies and Labels - Weston Nicolls

Weston stated that he is developing an I-D that will document the security policies of Whirlpool, Caterpillar and Amoco. The draft will describe how the ESSSecurityLabel can be used to implement those corporate security policies. It is planned that the document will be an Informational RFC.

Weston stated that he has been provided with classification policies for:

Jim Schaad pointed out that an example security policy is needed to populate sample ESSSecurityLabel attributes to be included in the "Examples of S/MIME Messages" I-D. The implication of Jim's statement is that one of the security policies described in Weston's document could be used to populate sample ESSSecurityLabel attributes to be included in the "Examples of S/MIME Messages" I-D.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

KEA and SKIPJACK Algorithms - John Pawling

John presented the CMS KEA and SKIPJACK Conventions I-D (CMSKEA-02), 29 July 1999. The goal of CMSKEA is to promote interoperability between implementations using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithms with the RFC 2630 enveloped-data and encrypted-data content types. CMSKEA describes a profile for using SKIPJACK and KEA with CMS. It describes modes, key lengths, object identifiers and parameter formats associated with the use of SKIPJACK and KEA with CMS. J.G. Van Dyke and Associates (VDA) has used the S/MIME Freeware Library with the Fortezza Cryptologic Interface (CI) Library and Fortezza Card to successfully perform interoperability testing with Microsoft. This testing verifies the correctness of the CMSKEA I-D.

The "FORTEZZA Card\CI Library Usage With CMS KEA SKIPJACK I-D" text file (available from http://www.jgvandyke.com/services/infosec/sfl.htm) contains hints for using the FORTEZZA Card and FORTEZZA CI Library to meet the CMSKEA requirements.

Russ pointed out that CMSKEA is planned to be an Informational RFC. He stated that he would like to issue the working group last call for CMSKEA. Nobody objected.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CAST-128 Algorithm for S/MIME - Carlisle Adams

Carlisle discussed the "Use of the CAST-128 Encryption Algorithm in S/MIME" I-D, September 1999 (cast-128-00). He stated that this is a short, simple specification. It documents how to use CAST-128 as a content encryption algorithm and a key encryption algorithm. The relevant algorithm object identifiers and parameters are specified.

Carlisle stated that there are patents issued and pending regarding the CAST design procedure, but CAST-128 (described in RFC 2144) may be used by anyone for any purpose without paying any royalties or obtaining any licenses as stated in www.ietf.org/ipr.html. He stated that there is no encumbrance in using CAST-128. The same is true for CAST-256 (RFC 2612).

Russ pointed out that the CAST-128 document is planned to be on Standards Track. He stated that he would like to issue the working group last call for the document as soon as possible. Nobody objected.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Elliptic Curve Algorithms - Paul Lambert

Paul briefed the "Elliptic Curve S/MIME" I-D, October 1999 (ECC-00). He stated that the EC algorithms support digital signatures and key management. EC Diffie-Hellman (D-H) is based on ANSI X9.63 and EC Digital Signature Algorithm is based on ANSI X9.62. Paul stated that there is one issue. The I-D includes two recommendations for ECDH: one-pass D-H and cofactor D-H. Paul recommends that the S/MIME working group pick one or the other, but not both. Paul's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the EC S/MIME I-D.

Paul Hoffmann stated his concerns about the patent issues regarding the EC algorithms. He stated that the IPR for the EC algorithms is insufficient for the WG to decide what to do.

Paul Lambert stated that Certicom has patents and patent applications that may cover the specification and will include a pointer to the IPR statement in the EC S/MIME I-D.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

ETSI Electronic Signatures - Denis Pinkas

Denis briefed the "European Electronic Signature Standardisation Initiative". He stated that the European Community plans to vote on the EESSI directive. The directive will cover anything in digital form that can prove the identity of the signer. The goal is to specify technology and standards that are equivalent to a manual signature. The ETSI definition provides "Evidence in a digital form than can be processed to get confidence that some commitment has been explicitly endorsed under a signature policy, at a given time, by a signer under an identifier, e.g. a name or a pseudonym, and optionally a role." The ETSI draft Standard builds upon RFC 2630 and RFC 2634. It defines new signed and unsigned attributes. The Electronic Signature uses signed attributes defined in RFC 2630, RFC 2634 and the draft ETSI standard including: - signature policy ID (reference and hash) (new),

Denis also briefed regarding the role of time stamping in the EESSI. His briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the EESSI.

An attendee asked how the verifier can prove the signer's physical location. Denis said that the EESSI specification replicates the services provided by the paper hard copy which is no authentication of the signer's location value.

Phillip Hallam-Baker stated that the requirement for the signer to state her location is bogus and is not required in the United Kingdom.

An attendee stated that a 760-bit signing key could be compromised in 20 years, so the time stamp signature could be compromised too. Denis said that an authority can re-sign the time stamps with a longer length key or could apply two stamps.

Chris Bonatti asked if the signature policy is selected by the signer, what guarantee is there that the verifier will recognize the signature policy. Denis said that the verifier will look for specific values.

An attendee asked whether there will be a signature policy distribution point from which people could obtain defined policies. Denis said that service might be provided by the International Chamber of Commerce.

An attendee asked if XML would be more useful to describe the signature policy than ASN.1. Denis said that ASN.1 will be used for now, but XML may be used in the future. Phillip Hallam-Baker stated that XML is better for future use.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME Freeware Library (SFL) - John Pawling

John provided an update briefing regarding the SFL which is a freeware implementation of RFC 2630 and RFC 2634. It uses the Crypto++ freeware library to implement RFC 2631. It provides functions to support use of RFC 2632 and RFC 2633. The goal of the SFL is to provide a reference implementation of RFC 2630 and RFC 2634 to encourage their acceptance as Internet Standards. VDA is developing the SFL.

The SFL implements the optional RFC 2634 security services such as signed receipts, security labels, mail list information, signing certificate attribute and equivalent security labels. It has been used with the RSA BSAFE v4.2, Crypto++ v3.1, Fortezza CI and SPYRUS SPEX/ libraries. VDA is now developing the capability for the SFL to use any security library that provides a PKCS #11 interface.

Version 1.3 of the SFL was released in October 1999. It was tested on MS Windows 95/NT and Sun Solaris 2.6. It was tested using the mandatory and RSA algorithm suites. VDA continues to enhance the SFL.

Organizations can use the SFL as part of their applications without paying any royalties or licensing fees (see SFL Public License). All source code is provided. The VDA-enhanced SNACC ASN.1 software is freely available at http://www.jgvandyke.com/services/infosec/sfl.htm. All other portions of the SFL are available at: http://www.armadillo.huntsville.al.us/software/smime and are export controlled as per U.S. Government Export Administration Regulations (see: http://www.bxa.doc.gov/Encryption/Default.htm).

John also provided information regarding the Certificate Management Library (CML) that is a freeware implementation of X.509 version 3 certification path verification as specified in the 1997 X.509 Recommendation (except Delta CRLs are not implemented). The CML: validates X.509 certification paths and CRLs; provides local certificate/CRL storage functions; and provides remote directory retrieval via LDAP. The CML uses the Certificate Path Development Library (CPDL) developed by Cygnacom Solutions to robustly build certification paths including cross certificates. The CML complies with the majority of the RFC 2459 requirements. Organizations can use the CML as part of their applications without paying any royalties or licensing fees (see CML Public License). All CML source code is provided. CML is available at: http://www.armadillo.huntsville.al.us/software.

John's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the SFL and CML.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Wrap Up - Russ Housley

Russ discussed the work item proposing the use of password-based key management for file encryption. This is documented in the "Password-based Encryption for S/MIME" I-D. The proposal uses PKCS #5 techniques. Russ stated that the working group needs to decide if that proposal will be accepted. He encouraged people to read the document and provide comments.

Bob Jueneman stated his concern with the processing of name forms. Bob is concerned that not all applications display all address spec texts. He stated that they may omit, abbreviate or truncate the address spec text. He believes that this should be a joint work item between the PKIX and S/MIME working groups. He stated that properly supporting the address spec requirements is important. He recommends that we allow the use of a personal name form that precedes the address spec. For example, a husband and wife may share an e-mail address, but use different certificates.

Paul Hoffman stated that RFC 822 includes a third option that allows comments to be included in parentheses. The third option must be included in any solution. He agreed that this issue needs to be resolved.

Bob Jueneman also stated his concern regarding using the same object identifier to indicate two-key triple-DES and three-key triple-DES. He believes that separate object identifiers must be used for export control reasons. Two-key triple-DES may be exportable, but 3-key triple-DES may not be exportable. He said that 168-bit keys (112 effective) need a separate object identifier.

Paul Hoffman stated that his understanding is that two-key is 80-bit and three-key is 112 bit (effective). He does not believe that the object identifier should be changed.

Russ asked if it would be acceptable to examine the contents of the key to determine if the first and third keys are the same. Bob said that he has to enforce that they are the same. Russ said that it seems to be a receive-side issue, since the send-side controls the formation of the keys. Russ asked if the receive side could examine the keys and stop processing if the first and third keys are different.

Paul Hoffman noted the creation of the S/MIME developers mail list for discussing implementation of S/MIME. The new list is a good place to send sample S/MIME messages for interoperability testing. The list is called imc-smime-dev@imc.org. To subscribe, send a message to imc-smime-dev-request@imc.org with the single word "subscribe" in the body of the message.

Russ noted that members of the S/MIME mail list don't necessarily need to use S/MIME-enabled e-mail products.

Meeting adjourned.

Slides

Agenda
CAST-128 for S/MIME
S/MIME Working Group Charter Revision
S/MIME Working Group RFC Status
draft-ietf-smime-small-subgroup-01.txt
Elliptic Curve S/MIME
Mapping Company Classification Policy to the S/MIME Security Label
CMS KEA and SKIPJACK Conventions I-D (cmskea)
VDA Security Services Freeware Libraries
EESSI : the European Electronic Signature Standardisation Initiative