2.6.10 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


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:



First draft of CMS RecipientInfo extension.



First draft of security label usage specification.



Last call on small subgroup attack avoidance



First draft of CAST algorithm specification.



Last call on KEA and SKIPJACK algorithm specification.



First draft of mail list key distribution.



Last call on certificate distribution specification.

Nov 99


Last call on security label usage specification.



Updated draft of domain security services document.



Last call on CAST algorithm specification.



Submit small subgroup attack avoidance as Informational RFC



Submit KEA and SKIPJACK algorithm specification as Informational RFC.

Dec 99


Last call on CMS RecipientInfo extension.

Dec 99


Last call on CMS and ESS examples document.



Last call on IDEA algorithm specification.

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 security label usage specification as Informational RFC.



Submit CAST algorithm 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 mail list key distribution to IESG for consideration as a Proposed Standard.



Submit IDEA algorithm specification as Informational RFC.

Jul 00


Last call on domain security services document.

Sep 00


Submit domain security services as Experimental RFC.

Request For Comments:






S/MIME Version 2 Message Specification



S/MIME Version 2 Certificate Handling



Cryptographic Message Syntax



Diffie-Hellman Key Agreement Method



S/MIME Version 3 Certificate Handling



S/MIME Version 3 Message Specification



Enhanced Security Services for S/MIME



Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME



Use of the KEA and SKIPJACK Algorithms in CMS



Use of the CAST-128 Encryption Algorithm in CMS



Use of the IDEA Encryption Algorithm in CMS

Current Meeting Report

This message includes the official minutes of the IETF S/MIME Working Group (WG) meeting held on 21 March 2001 in Minneapolis, Minnesota, USA. Briefing slides will be available from <ftp://ftp.ietf.org/ietf/smime/>. These minutes were reviewed by the briefing presenters. Reported by John Pawling.


Introductions - Russ Housley

Russ reviewed the agenda as follows. Nobody commented on the agenda.

Introductions Russ Housley
Working Group Status Russ Housley
IPR Statements Russ Housley
Interoperability Matrix Jim Schaad
CMS and ESS Examples Paul Hoffman
Symmetric Key Distribution Sean Turner
X.400 and CMS Chris Bonatti
Reuse of Content Encryption Keys Steve Farrell
AES and RSA-OAEP Jim Schaad
Elliptic Curve Crypto Simon Blake-Wilson
Mandatory to Implement Algorithms Russ Housley
S/MIME Freeware Library John Pawling
Wrap up Russ Housley


S/MIME Working Group Status - Russ Housley

Russ listed the RFCs generated by the S/MIME WG:
RFC 2630 Cryptographic Message Syntax (CMS), 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
RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME, R. Zuccherato, March 2000. [Informational]
RFC 2876 Use of the KEA and SKIPJACK Algorithms in CMS, J. Pawling, July 2000. [Informational]
RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS, C. Adams, October 2000.
RFC 3058 Use of the IDEA Encryption Algorithm in CMS. S. Teiwes, P. Hartmann, and D. Kuenzi, February 2001. [Informational]

Russ outlined the requirements for advancing the standards track RFCs from Internet Proposed Standards to Internet 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
4) Draft Standards cannot reference Proposed Standard RFCs or Experimental RFCs, so the aforementioned RFCs are blocked until the PKIX Certificate and CRL Profile "Son-of-RFC 2459" Internet-Draft (I-D) (draft-ietf-pkix-new-part1-05.txt) progresses to Draft Standard.

Russ stated that Jim Schaad has developed an interoperability matrix for RFCs 2630 through 2634. The interoperability matrix is posted at <http://www.imc.org/ietf-smime/interop-matrix.html>. The matrix indicates which features have been successfully tested. So far, only Jim Schaad and Getronics Government Solutions have provided input to the interoperability matrix. Jim has provided input regarding the capabilities of the Microsoft S/MIME v3 implementation. Getronics has provided input regarding the capabilities of the S/MIME Freeware Library (SFL) including interoperability testing conducted with Microsoft.

Russ noted that Paul Hoffman (IMC) has offered to coordinate interoperability testing and to enhance the "Examples of S/MIME Messages" I-D.


IPR Statements - Russ Housley

Russ presented a briefing regarding Intellectual Property Rights (IPR) notices that have been provided to the IETF that may be related to implementing features described in the S/MIME specifications. The main goal of this briefing was to inform working group members of the existence and location of these IPR statements.

Russ began with a disclaimer that he is not a patent attorney and warned that implementers should not make development decisions based on his presentation. He stated that each implementer MUST have their own patent attorney review the relevant documents. He further stated that the opinions expressed in his briefing are his own and do not necessarily reflect the opinion of his employer, RSA Security.

Russ briefed that some techniques for efficiently implementing cryptographic algorithms have been patented and that many of these patent holders have not chosen to submit IPR statements to the IETF. He stated that he is only addressing the patents identified in IPR statements posted on the IETF Page of IPR Notices <http://www.ietf.org/ipr.html>. He re-iterated that implementers MUST do their homework before selecting a particular technique.

RSA Security IPR <http://www.ietf.org/ietf/IPR/RSA> states that the RSA public-key cryptosystem Patent expired on 20 September 2000.

RSA Security IPR <http://www.ietf.org/ietf/IPR/RSA-MD-all> states that implementations of the MD2, MD4, and MD5 message-digest algorithms, including implementations derived from the reference C code in RFC 1319, RFC 1320, and RFC 1321, may be made, used, and sold without license from RSA Security for any purpose.

U.S. National Institute of Standards and Technology (NIST) IPR <http://www.ietf.org/ietf/IPR/DSA-NIST> states that they have made the Digital Signature Algorithm (DSA) patent available royalty-free to users worldwide.

Certicom IPR <http://www.ietf.org/ietf/IPR/CERTICOM-ECDSA> states that they believe that they have patents issued or pending that relate to Elliptic Curve DSA (ECDSA) as follows: point compression, public key validation (including domain parameter validation), and computational techniques. They are willing to offer a non-exclusive license under reasonable and non-discriminatory terms and conditions, providing the applicant provides a similar grant for the applicant's relevant patents (if any) and respects Certicom's other intellectual property.

Certicom IPR <http://www.ietf.org/ietf/IPR/CERTICOM-SMIME-1> states that they have U.S. Patent No. 5,933,504 issued regarding Diffie-Hellman (D-H) Small Subgroup Attacks. They are offering a royalty-free license for the restricted field of use of Ephemeral-Static (E-S) D-H as specified in the S/MIME specifications (i.e. RFC 2631). The Certicom license does not address fields of use other than E-S D-H. Other algorithms require a separate license. The Certicom license requires reciprocal grant to licensee's patents (if any) in same field of use.

IBM IPR <http://www.ietf.org/ietf/IPR/IBM-diffie-hellman.html> states that they have U.S. Patent No. 5,953,420 issued regarding D-H. Where there is a necessary dependence upon this patent to implement the algorithms, IBM will provide a non-exclusive license under reasonable and non-discriminatory terms and conditions, in accordance with IBM's usual licensing practices. Russ' personal opinion is that this patent does not apply to the Ephemeral-Static (E-S) D-H algorithm as described in RFC 2631.

Don Hall IPR <http://www.ietf.org/ietf/IPR/HALL-SMIME> states that he has U.S. Patent No. 5,126,728 issued regarding Security Labels. Nonexclusive licenses, on relevant patent claims, will be made openly available for a reasonable fee, without discrimination. Russ' personal opinion is that this patent does not apply to the security labeling as described in RFC 2634.


Interoperability Matrix - Jim Schaad

Jim briefed that he is still working with the S/MIME Freeware Library and Microsoft S/MIME v3 implementations to build and process examples of the features documented in the interoperability matrix for RFCs 2630 through 2634. Other organizations that have developed S/MIME v3 capabilities are requested to participate. If an organization has already performed tests that fulfill a particular requirement, then the results should be included in the matrix. Please submit input to Jim at jimsch@exmsft.com.


CMS and ESS Examples - Paul Hoffman

Paul stated that he had distributed a new release of the "Examples of S/MIME Messages" I-D <draft-ietf-smime-examples-06.txt>, 25 February 2001, that includes corrected sample data generated by Getronics using the SFL. He stated that the document needs further input and testing. He asked that other organizations that have developed S/MIME v3 capabilities should please participate. He invited people to provide comments regarding errors in the document. He acknowledged that there are still errors in some of the test data that must be fixed. He stated that since nobody had provided a sample of an EnvelopedData using RC2/40 for content encryption using a previously-distributed key-encryption key, that he would eliminate that section from the document. When Paul stated that nobody had provided any sample AuthenticatedData objects, Jim Schaad volunteered to provide those examples. Chris Bonatti questioned the value of including AuthenticatedData objects in the document that only Jim Schaad could build and process. The consensus was that was better than nothing.


Symmetric Key Distribution - Sean Turner

Sean stated that he had distributed a new release of the S/MIME Symmetric Key Distribution I-D, <draft-ietf-smime-symkeydist-03.txt>, 2 March 2001. Sean noted that Jim Schaad provided significant comments to the symkeydist-02 I-D that Sean incorporated into the symkeydist-03 I-D.

Sean briefed the following changes included in symkeydist-03:
- Reorganized requirements (Each component has mandatory and optional support requirements).
- Removed restriction that only Group List (GL) Owner (GLO) is allowed on unmanaged lists.
- Added new field to GLRekey to support rekey of all outstanding keys.
- Added ASN.1 module.
- Added text for "Using the Group Key".
- Added date to GLKRefresh to support getting a range of previously distributed keys.
- Modified GLProvideCert and GLUpdateCert so they are the same syntax.
- Removed strict requirement for encrypting outbound messages if inbound messages were encrypted.
- ktri instead of kari RecipientInfo choice.
- Added checks for the GLO and GL member to make sure the GL's certificate was used to sign the response.

Sean stated that he is incorporating comments to symkeydist-03 regarding using the new Certificate Management Messages over CMS (CMC) structures. Also, some object identifiers (OID) need to be defined.


X.400 and CMS - Chris Bonatti

Chris presented a briefing regarding the "Transporting S/MIME Objects in X.400" I-D, <draft-ietf-smime-x400transport-01.txt> and "Securing X.400 Content with S/MIME" I-D, <draft-ietf-smime-x400wrap-01.txt> both distributed in November 2000. Both drafts are proposed for the IETF Standards Track. Paul Hoffman is the primary editor for both drafts and will be delivering an "02" version of both drafts once he has incorporated comments.

The x400wrap I-D specifies how to protect X.400 content with CMS objects. It is roughly analogous to RFC 2633 and refers to RFC2633 when applicable. Chris believes that the "02" version will be ready for S/MIME working group last call.

The x400transport I-D specifies how to package CMS objects for transport by X.400 Message Transfer Agents (MTA). It is separate from the X.400 wrapping draft to encourage use of RFC 822/MIME content in X.400 communities.

One outstanding issue is the X.400 Transport of the "certs-only" format. RFC 2633 specifies a convention for identifying a message that contains a "degenerate" SignedData structure that contains no encapsulated content, but is sent merely for the purpose of conveying certificates or CRLs. The "certs-only" convention was omitted from the -01 X.400 Transport draft because the RFC 2633 convention was not applicable and it was unclear whether Public Key Cryptography Standard (PKCS) 10 requests would be used in the X.400 environment. Discussion with some in the X.400 community yielded a proposal to identify certs-only messages via the encoded-information-types (EITs) field in the X.400 envelope. Chris' proposed solution was to add clarifying text to the X.400 Transport document. This approach was discussed on the mailing list and appeared to be acceptable.

A comment was sent to the mailing list that the "certs-only" message was misnamed because it could include certificates and/or Certificate Revocation Lists (CRL). Chris made the point that if the x400transport I-D is changed, then RFC 2633 should also be changed to be consistent. He further stated that this is a real issue because CRLs are being conveyed in operational S/MIME messages today.

Paul Hoffman expressed his opinion that the name of the message should be changed to clarify the contents. He stated that a similar misnomer had created problems in the IPSEC environment because implementations were not expecting CRLs to be included in an ASN.1 encoded object and crashed when they were included.

Jim Schaad expressed his concern that we may be setting a precedent for defining new S/MIME types for every new type of S/MIME message that is defined (such as CMC). Jim asked if the plan was to define other S/MIME types.

Chris replied that he did not think that it was necessary to create a new S/MIME type for every variation of S/MIME message.

Jim asked why it is necessary for certs-only messages.

Chris stated that RFC 2633 defined a different S/MIME type so that applications would know to process it differently.

Jim stated that S/MIME applications include special processing rules for some types of S/MIME messages such as signed receipts and certs-only. His opinion is that we only need to identify those messages with special S/MIME types that require special processing.

Chris agreed with Jim's statement and further stated that the x400transport I-D should be consistent with RFC 2633 regarding identification of messages that require special processing.

Russ stated that in X.400, content types are expressed as an OID; however, MIME uses a structure that permits subtypes. The X.400 use of an OID does not permit subtypes.

Jim asked if we planned to define OID values for other MIME subtypes.

Russ pointed out that signed receipts require special processing, so they should also have a special X.400 type.

Chris stated that he will draft proposed text regarding the certs-only issue for inclusion in the x400transport I-D.


Reuse of Content Encryption Keys - Steve Farrell

Steve presented a briefing regarding the "Reuse of CMS Content Encryption Keys" I-D, <draft-ietf-smime-rcek-01.txt>, February 2001. The rcek I-D specifies how to set up a shared secret key using asymmetric crypto (using EnvelopedData) and then to re-use the content encryption key (CEK) to derive the Key Encryption Key (KEK) of the next message.

Steve briefed the changes included in the rcek-01 I-D:
- Key Derivation Function (KDF) changed to use PKCS #5 v2 KDF.
- Removed error attribute.
- Added ASN.1 module.
- Regarding comment that bit-reversal breaks DES parity bits, so use byte reversal instead.
- Received comments to use other KDFs such as X9.63/p1363a or TLS PRF. Steve decided to stick with PKCS #5.
- Received comments regarding attribute syntax: Separate vs. single attribute. Steve decided to stick with separate attributes.

Russ pointed out that the PKCS #5 ASN.1 syntax uses 1993 ASN.1 features, so Steve must convert the module to use 1988 ASN.1 syntax and include it in the rcek I-D.

Paul Hoffman asked why others recommended other KDFs.

Steve stated that he believed that the PKCS #5 KDF is the way to go.

Simon Blake-Wilson stated that he believes that the X9.63 KDF is more appropriate and efficient. They are planning to use S/MIME on a wireless device using scripts so efficiency is important to them.

Steve disputed the statement that the X9.63 KDF is significantly more efficient than the PKCS #5 KDF.

Steve briefed that he still needs to add the following:
- Security consideration documenting the scenario in which msg2 is sent to subset of msg1.
- Text describing combinations of attributes (sent new "conformance" text to list).
- More motivation and "when-to-use" text.
- Security considerations describing flip-flop issue (will add text from list).
- Needs OIDs for attributes.
- "Same" algorithms (Text on list)
- CEKMaxDecrypts default & max (default: 1, max: 2^32)
- Comment ASN.1 module

Russ conducted a straw poll of the meeting attendees to obtain their opinion regarding the following options for the rcek KDF:
1) X9.63/P1363a
2) TLS
3) PKCS #5
There were 3 votes for option 1, no votes for option 2 and 4 votes for option 3.

Russ recommended that rcek should continue to use PKCS #5 KDF unless somebody could present a good reason for using another KDF.

Russ asked that people examine the aforementioned byte-reversal issue.

Russ stated that the last call period would be re-started because of the magnitude of the changes.


AES and RSA-OAEP in CMS - Jim Schaad

Jim presented a briefing regarding the "Use of the Advanced Encryption Algorithm in CMS" (aes-alg) I-D. The I-D specifies how to incorporate the Advanced Encryption Standard (AES) into CMS as an additional algorithm for symmetric encryption. Jim stated that the next version of the aes-alg document will also specify how to incorporate the RFC 2437 PKCS #1 v2.0 Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport method of key management into CMS as an additional algorithm. The "Use of the RSAES-OAEP Key Transport Algorithm in CMS" I-D will be eliminated because the information will be included in the aes-alg I-D. The aes-alg I-D will describe the conventions for using the RSAES-OAEP key transport algorithm and AES content encryption algorithm with the CMS enveloped-data, encrypted-data and authenticated-data content types.

Jim stated that the S/MIME v3 specifications will be written to state that compliant implementations will use RSAES-OAEP (rather than PKCS #1 v1.5) as the key transport algorithm when AES is used as the content encryption algorithm.

Jim noted that the aes-alg I-D does not include an AES key wrap algorithm, but that he expects that will be provided by July 2001.
He is still waiting for input from NIST which should be provided during June or July 2001.

Jim noted that he would like to add signature algorithms for use with SHA-256 to the document. This is dependent on the following events:
- PKCS #1 v2.1 Probabilistic Signature Scheme (PSS) being standardized and OIDs issued
- SHA-256 being standardized
- DSA-SHA-256 Key sizes and OIDs being issued

Tim Polk stated that NIST is working on a DSA specification for use with SHA-256. They are discussing the use of PSS/RSA with SHA-256. He believes that they will have a SHA-256/PSS specification ready before August 2001.

Simon Blake-Wilson stated that he was concerned that the formats of the certificates containing RSA public keys for use with RSA PKCS #1 v1.5 and RSAES-OAEP are identical. He was trying to make the point that it is good cryptographic practice to employ a given key pair in only one scheme. This avoids the risk that vulnerability in one scheme may compromise the security of the other, and may be essential to maintain provable security. For example, RSAES-OAEP by itself would resist attack, but an opponent could exploit a weakness in the implementation of RSAES-PKCS #1 v1.5 to recover messages encrypted with either scheme. There was much discussion regarding this point.

Russ Housley pointed out RSA is working to ensure that the RSA algorithms are consistently specified in the various documents.

Russ recommended that the strengthened key management be specified in one I-D and DSA in another.

Tim Polk stated that the PKIX working group will be specifying how to sign certificates using the new algorithms.


Elliptic Curve Cryptography (ECC) - Simon Blake-Wilson

Simon presented a briefing regarding the "Use of ECC Algorithms in CMS" I-D, <draft-ietf-smime-ecc-03.txt>, 2 March 2001. He briefed that ECC may offer savings in terms of bandwidth, computation, and storage. He stated that ECC savings may increase as key sizes increase.

Simon briefed that EC-based algorithms are documented in the following specifications:
- Elliptic Curve Diffie-Hellman (ECDH) (from draft ANSI X9.63)
- ECDSA (from ANSI X9.62)
- ECMQV (from draft ANSI X9.63)
- Equivalent specifications in FIPS 186-2, IEEE P1363, SEC 1

Simon briefed that EC-based algorithms can be used with CMS as follows:
- SignedData using ECDSA
- EnvelopedData using Ephemeral-Static ECDH
- EnvelopedData and AuthenticatedData using 1-pass ECMQV

Notes regarding ECC I-D:
- SignedData provides message digest, ECDSA starts with the message.
- Key derivation function uses X9.63.
- AuthenticatedData and multiple recipients.
- Efficiency for AuthenticatedData.
- Key wrap for AuthenticatedData.

To promote interoperability, the ECC I-D documents the following:
- Recommended algorithms
- Recommended curves
- Use of SMIMECapabilities signed attribute
- Examples

Simon proposed the following plan for the ECC I-D:
- address any comments from meeting
- update ECDH/ECMQV reference?
- issue updated draft
- submit for WG last call


Mandatory to Implement Algorithms - Russ Housley

Russ briefed that the PKIX WG is not going to select a mandatory to implement algorithm for certificates, so the S/MIME WG is free to pick a single signature algorithm for certificates and messages.

Russ reviewed the straw poll conducted at the December 2000 S/MIME WG meeting which asked attendees of their opinion regarding supporting two mandatory-to-implement signature algorithm: DSA and RSA (PKCS #1 v1.5). Russ was concerned about the proposal to mandate that all implementations must sign using both of these signature algorithms because their key generation processes are very different. He proposed that implementations must be able to verify signatures on certificates and messages using both the DSA and RSA (PKCS #1 v1.5) signaturealgorithms; however, implementations are only required to generate signatures on messages using at least one of the signature algorithms.

Tim Polk stated his support for Russ' proposal because it may be practical for implementations that use smart cards to only implement a single signing algorithm due to the limitations of the smart card token.

Russ conducted a straw poll of the meeting attendees to obtain their opinion regarding the following options for the "MUST implement" signature algorithm:
1) sign and verify using both PKCS#1 v1.5 RSA and DSA
2) sign using one algorithm, verify using both (i.e. Russ' proposal)
An overwhelming majority of the meeting attendees voted for option 2.

Al Arsenault asked if RSA OAEP should be used instead of RSA PKCS #1 v1.5.

Russ stated that RSA OAEP had been proposed at previous meetings and on the mail list, but was rejected by many implementers. He noted that Eric Rescorla had posted the "Preventing the Million Message Attack on CMS" on the mail list on 18 March 2001. Concerns have been expressed regarding the use of RSA PKCS#1 v1.5 by automated messaging applications such as a Mail List Agent. Eric's document describes the concerns regarding RSA PKCS#1 v1.5 and some possible countermeasures.

John Pawling asked if the change to use RSA PKCS#1 v1.5 as the mandatory to implement key management algorithm was dependent on the acceptance of the "Preventing the Million Message Attack on CMS" I-D. Russ answered that as long as the work was progressing that the change could be made (similar to RFC 2631 and the Small Subgroup Attack).

Paul Hoffman asked if the change in the algorithms would case the S/MIME version number to change (ex: v3.1). John Pawling made the point that the CMS ASN.1 syntax is not changing, just the algorithms used with that syntax. He further stated that the algorithms in an instance of a CMS object are clearly indicated by OIDs populated in that object, so a version number change is not required. Russ agreed and made the point that the RFCs would change, but the S/MIME version number would still be 3. Nobody disagreed with Russ.

Russ also stated that he believes that the algorithm information should be separated from the CMS specification into a separate RFC as has been done with the new PKIX specifications. Nobody disagreed with Russ.

In summary, the meeting attendees overwhelmingly agreed on the following set of mandatory to implement algorithms:
Signature: DSA and RSA (PKCS #1 v1.5) as per Russ' proposal
Message digest: SHA-1
Key Management: RSA (PKCS #1 v1.5)
Encryption: Triple-DES


S/MIME Freeware Library (SFL) - John Pawling

John briefed regarding the SFL which is a freeware implementation of RFCs 2630 and 2634 developed by Getronics Government Solutions. The SFL can be used with the Crypto++ freeware library to implement RFC 2631. The SFL provides functions to support use of RFCs 2632 and 2633. It has been tested on the RedHat Linux, Windows NT/98/00 and Solaris 2.7 operating systems. The SFL maximizes crypto algorithm independence. It has been used with the RSA BSAFE v4.2, Crypto++ v3.2, Fortezza CI and SPYRUS SPEX/ libraries. Getronics has developed the capability for the SFL to use any security library that provides a PKCS #11 interface.

Getronics has used the SFL to perform a significant amount of S/MIME v3 interop testing. Getronics tested the majority of features in RFCs 2630, 2631 and 2634 as well as some of the features in RFCs 2632 and 2633. Getronics used the SFL to successfully process and produce the majority of features documented in "Examples of S/MIME Messages". SFL-generated data was included in the Examples I-D such as: signed receipts, countersignatures, security labels, equivalent security labels, mail list information and signing certificate attributes.

S/MIME v3 interoperability testing between the SFL and Microsoft successfully tested almost all CMS/ESS features using mandatory, RSA and Fortezza algorithm suites. For example, successful signed receipt interoperability testing was performed between the SFL and Microsoft. Getronics verified that the SFL can produce and process the majority of features documented in Jim Schaad's S/MIME v3 interoperability matrix. Complete test drivers and test data are available with the SFL.

Getronics delivered the v1.9 SFL in February 2001 that included improved PKCS #11 capabilities (tested with GemPlus, DataKey and Litronic PKCS #11 libraries). It also included AES content encryption (as per aes-alg-00) and key wrap based on CMS Triple-DES key wrap algorithm (this may need to be changed when the AES key wrap algorithm is included in the aes-alg I-D). It also included an Enhanced SNACC library that increases performance and decreases memory usage.

John provided information regarding the Certificate Management Library (CML) that is a freeware implementation of X.509 v3 certification path verification as specified in the 2000 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 complies with the majority of the RFC 2459 requirements. In February 2001, Getronics delivered the v1.9 CML enhanced to support the 2000 X.509 certificate policy processing requirements.

John provided information regarding the Getronics-developed Access Control Library (ACL) that provides Rule Based Access Control using security labels and authorizations conveyed in either X.509 Attribute or public key certificates. He also discussed the Getronics Enhanced SNACC ASN.1 library that implements the Distinguished Encoding Rules (DER).

For all of the Getronics freeware libraries, unencumbered source code is freely available to all. Getronics freeware can be used as part of applications without paying any royalties or licensing fees. There is a public license associated with each Getronics freeware library.

The Getronics freeware libraries are available at:
SFL: <http://www.getronicsgov.com/hot/sfl_home.htm>
CML: <http://www.getronicsgov.com/hot/cml_home.htm>
ACL: <http://www.getronicsgov.com/hot/acl_home.htm>
SNACC: <http://www.getronicsgov.com/hot/snacc_home.htm>

The Internet Mail Consortium (IMC) has established SFL, CML and Enhanced SNACC mail lists. John pointed out that SFL/CML/Enhanced SNACC messages should be sent to the IMC lists and should not be sent to the IETF mail lists.


Wrap Up - Russ Housley

Russ asked if there were any other issues to discuss. The meeting attendees were silent.

Meeting adjourned.


Use of ECC Algorithms in CMS
CMS-X.400 Drafts
Mandatory to Implement Algorithms
Posted IPR Statements
S/MIME Working Group Status
S/MIME Freeware Library
AES Encryption Draft
SMIME Symmetric Key Distribution -03