2.6.7 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 03-Feb-00


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.


Request For Comments:







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



S/MIME Version 2 Message Specification



S/MIME Version 2 Certificate Handling



Cryptographic Message Syntax



Enhanced Security Services for S/MIME



Diffie-Hellman Key Agreement Method



S/MIME Version 3 Certificate Handling



S/MIME Version 3 Message Specification

Current Meeting Report

This message includes the minutes of the IETF S/MIME Working Group meeting held on 29 March 2000 in Adelaide, Australia. All briefing slides will be stored at: ftp://ftp.ietf.org/ietf/smime/. These minutes include comments from the briefing presenters.
Reported by John Pawling.

Introductions - Russ Housley

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

Introductions Russ Housley
Working Group Status Russ Housley
Security Policies and Labels Russ Housley
CERTDIST Draft Discussion Jim Schaad
Symmetric Key Distribution Sean Turner
DOMSEC Draft Discussion Bill Ottaway
Interoperability Matrix Jim Schaad
CMS/ESS Examples Paul Hoffman
Crypto Algorithm Documents Russ Housley
E-mail Addresses & Certificates Greg Colla
S/MIME Freeware Library John Pawling
Electronic Signature Formats John Ross
Wrap up Russ Housley


S/MIME Working Group 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
RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the
Diffie-Hellman Key Agreement Method for S/MIME.
R. Zuccherato. March 2000. [Informational]

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
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-01.txt) progresses to Draft Standard.

Russ stated that Jim Schaad has developed an interoperability matrix for RFCs 2630 through 2634. Once completed, the matrix will indicate which features have and have not been implemented. So far, Microsoft and J.G. Van Dyke and Associates (VDA) have provided input to the interoperability matrix. Russ asked that other organizations that have developed S/MIME v3 capabilities should contribute to the matrix.

Russ stated that testing of the example data included in the "Examples of S/MIME Messages" I-D is providing informal inputs for the matrix. Paul Hoffman stated that that other code bases also need to be tested. He welcomed feedback from novice developers. He has offered to coordinate interoperability testing. In the past, Paul has coordinated face-to-face SecureConnect interoperability events. He believes that future interoperability testing will not be face-to-face, but will be supported via a bulletin board or e-mail. He will announce any S/MIME inter events on the S/MIME WG mail list. Those events will be discussed in detail on the S/MIME developers mail list <imc-smime-dev@imc.org>


Mapping Company Classification Policy to the S/MIME Security Label
- Russ Housley

The "Implementing Company Classification Policy with the S/MIME Security Label" I-D, <draft-ietf-smime-seclabel-00.txt>, December 1999, was authored by Weston Nicolls. It is planned that the document will become an Informational RFC. It describes how the ESS Security Label can be used to implement an organizational security policy. It includes three organizational examples: Whirlpool, Caterpillar and Amoco. One use of this document is to provide sample policies for interoperability testing.

The document includes the security policy for Amoco Corporation as follows:
- Confidentiality: General, Confidential, Highly Confidential
- Integrity: Minimum, Medium, Maximum

It includes the security policy for Caterpillar Inc as follows:
- Confidentiality: Public, Confidential Green, Confidential Yellow, Confidential Red

It includes the security policy for Whirlpool Corporation as follows:
- Confidentiality: Public, Internal, Confidential
- Additional marks at discretion of owner:
- Privacy Marks?
- Security Categories?
- Do they require access control?

Way Forward:
- Support interoperability testing
- Need to assign Object Identifiers: IETF values for this document and testing
- Organizations assign their own

After discussion with Weston Nicolls, who could not be present at this meeting, three object identifiers were assigned to permit the Whirlpool, Caterpillar and Amoco security policies to be used in interoperability testing. These object identifiers are not the ones that will be used by the companies, rather they are intended for testing. The object identifiers are:

- S/MIME Working Group Object Identifier Registry
- id-smime OBJECT IDENTIFIER ::=

- Test Security Policies Arc
- id-tsp OBJECT IDENTIFIER ::= { id-smime 7 }

- Test Security Policies
- id-tsp-TEST-Amoco OBJECT IDENTIFIER ::= { id-tsp 1 }
- id-tsp-TEST-Caterpillar OBJECT IDENTIFIER ::= { id-tsp 2 }
- id-tsp-TEST-Whirlpool OBJECT IDENTIFIER ::= { id-tsp 3 }


CERTDIST Draft Discussion - Jim Schaad

Jim discussed the Certificate Distribution Specification I-D <draft-ietf-smime-certdist-04.txt>, October 20, 1999. The CERTDIST I-D was submitted for S/MIME WG "last call" for comments on 22 October 1999. Jim stated that he received comments regarding the following topics:
- LDAP Directory Attribute layout
- Additional arguments against CERTDIST Section 2 (current methods of publishing certificates)
- miscellaneous minor comments

Jims stated that he plans to publish an updated version of the CERTDIST I-D soon.


Symmetric Key Distribution - Sean Turner

Sean discussed the S/MIME Symmetric Key Distribution I-D, <draft-ietf-smime-symkeydist-00.txt>, December 20, 1999. He stated that the design goals are to provide a transport independent mechanism for distribution of symmetric keys to a group of users. The mechanism must use RFC 2630. It must maximize the reuse of existing group/list management techniques (listserv, majordomo, etc). Seam explained the diagrams included in the I-D.

Sean stated that he did not know of any patents regarding the secure distribution of symmetric keys. He asked if anybody else knew of any patents. Nobody replied.

Paul Hoffman pointed out that the majordomo mail list server software does not support all mail list features. He stated that the SYMPA mail list server includes a database and rich set of features.

Paul also pointed out that customers ask him on a monthly basis for secure mail list capabilities, so he knows that there are real requirements for these capabilities.


DOMSEC Draft Discussion - Bill Ottaway

Bill presented a briefing regarding the "Domain Security Services Using S/MIME" I-D <draft-ietf-smime-domsec-04.txt>. He stated that there are minor differences between the -03 and -04 drafts as follows:
- DOMSEC signatures are now added by encapsulation only. (Used to allow parallel signatures).
- Allows order of third party signature application to be known.
- More secure.
- Section four re-written to aid understanding

Bill discussed the proposed solution to an issue raised during the December 1999 S/MIME WG meeting. From those minutes: "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. "Bill proposes that the original domain naming conventions should be preserved. Bill briefed that the users "must always rely on the CA to police naming conventions."

Bill addressed Jim's other comment by adding text to the case when no originator signature is present to state that the eContentType will be id-data as specified in CMS. However, the eContent will contain the unsigned message instead of being left empty as suggested in CMS (section 2). This allows the DOMSEC signature to cover the message which does not have an originator signature.

Bill stated that an object identifier must be obtained for the id-signatureType attribute. He believes that the document is ready for working group last call.


Interoperability Matrix - Jim Schaad

Jim developed an interoperability matrix for RFCs 2630 through 2634. Jim has documented the features supported by Microsoft. VDA provided input to Jim regarding the capabilities of the S/MIME Freeware Library (SFL). VDA also provided input regarding interoperability testing conducted between the SFL and Microsoft. Jim asked for others to submit input to him at jimsch@nwlink.com. Jim also pointed out that there are some minor comments/questions to the RFCs that accompany the matrix.


Examples of S/MIME Messages - Paul Hoffman

Paul stated that the "Examples of S/MIME Messages" I-D needs more input. He stated that VDA had tested the samples in the document and was planning to provide further sample data for inclusion in the document. He stated that the document is valuable because it includes the ASN.1 encoded examples. He stated that there is sample data that can be extracted using a Perl script that is also included in the document.


S/MIME WG Cryptographic Algorithm Specification - Russ Housley

Russ briefed that the current S/MIME WG charter states: "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."

Russ briefed that the following I-Ds document the use of crypto algorithms with RFC 2630:

- <draft-ietf-smime-cast-128-01.txt>

- <draft-ietf-smime-cmskea-04.txt>

- <draft-ietf-smime-cms-rsaes-oaep-00.txt>

- <draft-ietf-smime-ecc-00.txt>

- <draft-ietf-smime-idea-02.txt>

Russ said that the following question was raised on the S/MIME WG mail list: "Should the specifications be published as Standards Track RFCs or Informational RFCs?" Russ stated that "mandatory-to-implement" algorithms will be published as Standards Track RFCs. He pointed out that the current S/MIME WG charter also states that complete algorithm specifications will be published as Standards Track RFCs.

Jeff Schiller stated that he believes that all drafts describing the details of a crypto algorithm must be Informational because the IETF cannot control the definition of the crypto algorithms. Jeff further stated that he believes that all documents describing how crypto algorithms can be used with an IETF protocol can be Standards Track because the IETF can control the use of the crypto algorithms. He further stated that all documents describing how secret or proprietary crypto algorithms can be used can not be Standards Track.

Russ applied Jeff's recommendations to the aforementioned list of I-Ds:


Application of Attribute Certificates (AC) in S/MIME - Greg Colla

Greg's briefing addressed the topic of checking the e-mail address of the signedData signer against the e-mail address in the signer's certificate.

Greg briefed that there are problems with binding the subject's e-mail address with the subject's public key in an X.509 public key certificate such as:
- Multiple e-mail addresses
- Maintenance of e-mail addresses
- Security Proxy (a proxy signs and decrypts on behalf of many users)
- Privacy/Spam

Greg briefed the following requirements:
- Address Aliasing: Associate a single entity with multiple e-mail addresses, with a single PKC.
- Secure Proxying: Associate multiple entities, each with their own e-mail address, with a common PKC.
- Address Sharing: Associate multiple entities, each with their own PKC, with a single e-mail address.

Greg proposed the following:
- Maintenance of e-mail addresses limits S/MIME usability
- ACs can be used to cryptographically bind e-mail addresses with PK certificates
- E-mail ACs provide a flexible solution for maintaining e-mail addresses
- Supplements current infrastructure
- Localized modifications required to S/MIME components to use E-mail Acs
- E-mail ACs can be used to solve other S/MIME limitations

Greg summarized by stating that his proposal provides a strategy for removing email addresses from PK certificates. Greg's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding his proposal.

Paul Hoffman stated that there are not many deployed ACs and that most companies have not implemented ACs. Paul stated his concern that the AC proposal will add confusion to and delay the deployment of S/MIME v3. He stated that ACs can be used in the future to solve problems. Greg Colla rebutted that they face these problems today (i.e. associated with binding e-mail addresses with public keys).

Jim Schaad stated the following comments/questions regarding Greg's proposal:
1) Two directory lookups will be required for each recipient of an encrypted message. This added time delay will decrease overall performance.
2) How does this help keep email addresses private? People will mail ACs in messages. A "spam harvester" could obtain the e-mail addresses out of messages in transit or out of the directory.
3) Solves internal/external problem.
4) Favors this approach for gateway address identification.
5) Agrees with Paul Hoffman's comments regarding adding confusion.

An attendee stated that CAs issue certificates and ISPs issue addresses. He asked whether Greg's proposal assumes that these two entities work closely together. Greg answered that an ISP could use an RA to create certificates. A system administrator could generate the AC. He made the point that the public key certificate generation is much more important.

Another attendee stated that he doesn't agree that including e-mail addresses in certs is a problem.


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. The SFL can be used with the Crypto++ freeware library to implement RFC 2631. The SFL 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.

John briefed that on 14 January 2000, the U.S. Department of Commerce published revisions to the Export Administration Regulations that changed the U.S. Government's encryption export policy. In accordance with these revised regulations, the unencumbered SFL source code is now freely available to everyone at:
Organizations can use the SFL as part of their applications without paying any royalties or licensing fees. There is a public license associated 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 developing the capability for the SFL to use any security library that provides a PKCS #11 interface.

John stated that VDA had used the SFL to perform a significant amount of S/MIME v3 interop testing. VDA tested the majority of features in RFCs 2630, 2631 and 2634 as well as some of the features in RFCs 2632 and 2633.

VDA used the SFL to successfully process and produce the majority of features documented in "Examples of S/MIME Messages". A summary of the test results was sent to the S/MIME WG examples mail list <ietf-smime-examples@imc.org>. Complete test drivers and test data is available with the SFL.

S/MIME v3 interoperability testing between the SFL and Microsoft successfully tested almost all signedData and envelopedData features using mandatory, RSA and Fortezza algorithm suites. For example, the SFL (using Crypto++) exchanged E-S D-H-protected envelopedData with Microsoft. Almost all of the ESS features were tested. For example, successful signed receipt interoperability testing was performed between the SFL and Microsoft.

VDA verified that the SFL can produce and process the majority of the features documented in Jim Schaad's S/MIME v3 interoperability matrix. John sent the matrix to which VDA added the SFL test results to Jim Schaad for incorporation into the master S/MIME WG matrix. VDA developed sample objects that illustrate each feature in the matrix that the SFL supports. Complete test drivers and test data are available with the SFL.

SFL interoperability testing is automated through use of test drivers and configuration files so it can be easily repeated and modified by VDA or independently by a third party. A third party could enhance the test drivers or incorporate them in an application such as an S/MIME interoperability testing auto-responder which organizations could use to test their S/MIME implementations.

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 also discussed the VDA-enhanced SNACC Abstract Syntax Notation One (ASN.1) library that implements the Distinguished Encoding Rules (DER).

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


ETSI Electronic Signature Formats - John Ross

John briefed regarding electronic signature formats for long-term electronic signatures as part of the ETSI Electronic Signature Infrastructure Standardisation.

John briefed that Special Task Force (STF) 155 includes:
Task 1: Policies for Certificate Service Providers (CSP).
- Policy Requirements on CSP issuing Qualified Certificates
Task 2: Electronic Signature Formats
- ETSI ES 201 733 & this Informational RFC
Task 3: Profile for Qualified Certificates
Task 4: Profile for TimeStamping Services

John discussed the "Electronic Signature Formats for long term electronic signature" I-D, <draft-ietf-smime-esformats-00.txt>. John briefed that this document is proposed as an Informational RFC. It defines the format of an electronic signature that can remain valid over long periods. It includes features which can provide evidence as to its validity even if the signer later attempts to deny (repudiate) the validity of the signature.

John stated that the contents of this Informational RFC will be technically equivalent to ETSI ES 201 733 V.1.1.1 Copyright (C). He noted that the authors do not provide the IETF with any rights other than to publish as an Internet-Draft.

John briefed that this document builds on other IETF standards such as RFC 2630 and RFC 2459. It will also build on coming standards such as the PKIX Timestamping protocol and PKIX AC profile.

John discussed the proposal to split the draft document into two RFCs: one RFC dealing only with ES formats, the other one dealing only with a Signature Policy format. In such a case, the basis of this split will be, sections 6 and annex C will be removed from this document and placed in another RFC dealing with Signature policies. Also, the signature policy ASN.1 will be removed the current ASN.1 modules in annex A and placed in a new ASN.1 module in the other RFC dealing with Signature Policies. A separate OID for the Signature Policy arc would ease separation.

Denis Pinkas made the point that the SigningCertificate signed attribute provides information about the signer and indicates the signer's AC that indicates which role the signer used to sign the data.

The point was made that the Signature policy Identifier attribute is used by the signer to indicate the signature policy under which he is signing. The Signature policy Identifier attribute will contain a hash of the signature policy. The esformats-00 I-D provides further details regarding the definition and use of signature policies.

John made the point that the esformats-00 I-D must be equivalent ETSI ES 201 733 V.1.1.1, so major changes can't be made to the esformats-00 I-D.

Sean Turner asked how the ETSI Electronic Signature format relates to the timestamping work being done in the PKIX WG. Denis Pinkas answered that the ETSI Electronic Signature work uses CMS and will build on the PKIX Timestamping protocol.

Mike Myers asked if the PKIX Data Validation and Certification Server (DVCS) Protocols would satisfy the ETSI Electronic Signature requirements. Peter Sylvester said that the DVCS protocol could include the ETSI Electronic Signature information. Denis stated the protocols could be used together, but don't have to be.

Sean Turner asked if the S/MIME WG cared about the contents of the esformats-00 I-D, since they can't change it anyway. John Ross replied that the signature policy portion of the I-D can be changed, but that the Electronic Signature format can not be changed. John welcomed input to the signature policy portion of the I-D.

Russ Housley asked if the signature policy portion of the I-D was covered under the ETSI copyright. John Ross said that it was. He further stated that they are working on getting the copyright rules relaxed regarding this topic. ETSI may split the ES 201 733 V.1.1.1 document into two parts to be consistent with a split in the esformats-00 I-D. A straw poll of the attendees favored splitting the esformats-00 I-D.


Wrap Up - Russ Housley

Russ stated that the "Use of the CAST-128 Encryption Algorithm in CMS" I-D was in working group last call. Jim Schaad stated that he had provided comments to the document. Russ stated that a new draft of the I-D will be submitted for IETF-wide last call.

Russ stated that he would like to issue last call for the "Password-based Encryption for S/MIME" I-D. Jim Schaad stated that he had provided significant comments to the document. John Pawling pointed out that several people had questioned why the I-D defined yet another key wrapping algorithm. Russ said that Peter Gutmann needs to address these comments on the mail list. Russ pointed out that the process of transforming a password to a key would be documented in a separate RFC.

Russ discussed the "Compressed Data Content Type for S/MIME" I-D. Peter Gutmann sent a message to the S/MIME WG mail list asking: "Does anyone have any further thoughts on compression as a CMS content type vs a MIME type?" Russ said that the S/MIME WG needed to make a decision regarding Peter's question. Paul Hoffman stated that compression has been discussed on the MIME mail list, but it has not been standardized. He said that the issue needs to get resolved. Russ stated that Jeff Schiller recommended that the S/MIME WG "just do it" because the issue needs to be resolved for efficiency purposes. Russ took a straw poll and only three people expressed an opinion.


Application of Attribute Certificates in S/MIME
S/MIME Cryptographic Algorithm Specifications
Domain Security Services Using S/MIME
Electronic Signature Formats for long term electronic signatures
Mapping Company Classification Policy to the S/MIME Security Label
SMIME: Symmetric Key Distribution
VDA Security Services Freeware Libraries Update
S/MIME Working Group Status