2.6.9 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01


Russ Housley <rhousley@rsasecurity.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.



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.



Last call on security label usage specification.

Dec 99


Last call on CMS and ESS examples document.



Last call on IDEA algorithm specification.



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



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 8 August 2001 in London, England. Briefing slides will be available from <ftp://ftp.ietf.org/ietf/smime/>. The briefing presenters have reviewed these minutes. Reported by Rich Nicholas.


Introductions - Russ Housley

Russ welcomed the attendees and presented the working group's agenda as follows.

Introductions Russ Housley
Working Group Status Russ Housley
Interoperability Matrix Jim Schaad
CMS and ESS Examples Paul Hoffman
Updates to CMS Russ Housley
Updates to CERT & MSG Blake Ramsdell
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
S/MIME Gateway Protocol Blake Ramsdell
NIST S/MIME Activities Mike Chernick
XML Electronic Signature Syntax Denis Pinkas
CSP and Time Stamps Denis Pinkas
S/MIME Freeware Library Rich Nicholas
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]

In addition to the RFCs, the following three documents are in the RFC Editor's queue:

esformats Electronic Signature Formats for long term electronic signatures. D. Pinkas, J. Ross, and N. Pope.
espolicies Electronic Signature Policies. J. Ross and N. Pope.
seclabel Implementing Company Classification Policy with the S/MIME Security Label. W. Nicolls.

The seclabel document is on hold in the editor's queue pending the PKIX Attribute Certificate Profile, so the seclabel document can cite it as a reference. The PKIX Attribute Certificate Profile was recently sent to the RFC editor.

Russ outlined the requirements for advancing the standards track RFCs from Proposed Standards to 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 <draft-ietf-pkix-new-part1-08.txt> progresses to Draft Standard. Son-of-RFC 2459 is presently with the Security Area Director, awaiting IETF Last Call.

Regarding requirement #3, Jim Schaad has developed an interoperability matrix for CMS, Diffie-Hellman, MSG, CERT, and ESS documents. The interoperability matrix is posted on the IMC web site at the following URL: <http://www.imc.org/ietf-smime/interop-matrix.html>. Paul Hoffman offered to coordinate interoperability testing and compile CMS and ESS Examples document.

Blake Ramsdell noted that the Examples of S/MIME Messages Internet-Draft is a very large document and asked if there is a precedent for such a large document. Paul Hoffman answered that there are larger RFCs, but there is no document that he has ever found like the examples document. Blake restated his question as are we approaching it the right way, is there a protocol that has been profiled as extensively as this? Paul answered that no, not that he's aware of.


Interoperability Matrix - Jim Schaad

Jim briefed on the status of the interoperability matrix. The matrix was updated to reflect the new CMS and CMS Algorithms Internet-Drafts. CMS now has 96 MUST statements and 79 optional requirements or "features." Of those requirements, implementations have demonstrated interoperability of 56% of the MUST statements and 48% of the features. In the CMS Algorithms draft, there are now 46 MUST statements and 15 optional features. Of those, interoperability has been successfully demonstrated with 93% of the MUST statements and 93% of the optional features.

For the other unchanged specifications:
RFC 2631, Diffie-Hellman, only 1 of the 13 requirements has passed interoperability testing.
RFC 2632, CERT, 16 of the 21 requirements have passed.
RFC 2633, MSG, 17 of the 61 requirements have passed.
RFC 2634, ESS, 27 of the 81 requirements have passed.


CMS and ESS Examples - Paul Hoffman

Paul briefly discussed status of the "Examples of S/MIME Messages" Internet-Draft <draft-ietf-smime-examples-06.txt>, 25 February 2001. Paul stated that an updated draft was not posted prior to the Internet Draft cut-off due to time constraints. An updated version of the document is forthcoming that includes changes that have been discussed on the ietf-smime-examples mail list. Only John Pawling and Jim Schaad have provided active input on the examples. Paul knows there are many more S/MIME implementations out there and requests the other S/MIME implementers provide feedback as to whether their software can process the examples, both positive or negative. The feedback can either be public on the ietf-smime-examples mail list or privately to Paul.


Updates to CMS - Russ Housley

Russ presented the status of CMS. CMS is being split into two documents, with the algorithms being moved into a separate document. The proposed revision to CMS, <draft-ietf-smime-rfc2630bis-01.txt>, has been discussed on the mail list. A new draft will be forthcoming once the two remaining issues have been resolved. The CMS Algorithms draft, <draft-ietf-smime-cmsalg-01.txt>, has been discussed on the mail list as well. A new draft will be released when the RFC2630bis open issues are addressed. Russ hopes that these issues will be resolved during this meeting.

The two remaining open issues are:
1. Should CMS specify any mandatory to implement algorithms?
2. Are version numbers handled correctly?

Regarding issue #1, a protocol cannot say:
"Implementations of the CMS MUST support the mandatory to implement algorithms specified in [CMSALG], or its successor." There are two possible alternative remedies: either preserve the MUST and SHOULD statements for algorithms in CMS, or remove the algorithm-specific requirements from CMS. Russ presented the pros and cons of both alternatives. Requiring mandatory to implement algorithms ensures that protocols that employ CMS can inherit the algorithms from CMS without further specification. Removal of mandatory to implement algorithms makes the CMS protocol stable, but places the burden of algorithm specification on protocols that employ CMS. Russ noted that this second alternative is similar to the PKIX Certificate and CRL Profile and that RFC 2633 already includes necessary statements for S/MIME. Russ noted that this issue has been discussed on the mail list, but only a few people have expressed an opinion.

Paul Hoffman stated this is mostly a political issue, not a technical one, so he hasn't expressed an opinion. Another working group member noted that protocol implementers and users typically have different agendas and users of CMS implementations might feel more strongly about the need to require specific algorithms to promote interoperability.

Russ polled the working group members as to which alternative they preferred. The majority preferred the second alternative to require no mandatory algorithms in CMS.

Russ then presented the following example to illustrate issue #2:
Current EnvelopedData version processing:
IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present)) OR
(any RecipientInfo structures include pwri) OR
(any RecipientInfo structures include ori)
THEN version is 3
IF (originatorInfo is present) OR
(unprotectedAttrs is present) OR
(any RecipientInfo structures are a version other than 0)
THEN version is 2
ELSE version is 0

Currently, the version number in a complex structure like EnvelopedData is set to ensure that all subordinate components can be decoded in a single pass. The outer version number indicates to the application if it can decode all of the inner subcomponents. The alternative is to let the version number in each subordinate component handle changes within that component. Based on discussions on the list, many implementations are not prepared for decode errors after the higher-level version check.

Jim Schaad noted that based on discussions on the list, Peter Gutmann's implementation is the only one to check the EnvelopedData version prior to decoding. Most other implementations attempt to decode the entire structure and only check the version number if a decode error occurs. Other working group members noted that whether an implementation encounters an error decoding the EnvelopedData or checks the version number prior to decoding, the result is the same. The version number at least gives information as to the cause of the decode error which is useful for debugging.

Russ polled the working group members as to which alternative they preferred. Only a few members expressed a preference, so Russ left the issue open.

Blake Ramsdell noted that there are quite a lot of optional features in CMS. He asked whether those optional features could be moved from the base CMS document into a third CMS protocol document. The consensus was that it was not worth doing that at this time, but could be done at the next level (when the documents go from proposed standards to draft standards).


Updates to CERT & MSG - Blake Ramsdell

Blake briefed the status of the updates to RFCs 2633 and 2632. Blake noted that new versions of both RFCs are forthcoming and outlined the changes.

Changes to RFC 2633 (MSG):
RFC 2633 2633bis


Individual alg specs CMS Alg

Changes to RFC 2632 (CERT):
RFC 2632 2632bis

Jim Schaad asked if the requirement for MD2 could be eliminated. Paul Hoffman suggested that the MD5 requirement should be changed to SHOULD rather than MAY, but that MD2 could be left as a MAY, or dumped.

A question was asked whether the MUST DSA statement in 2632bis required applications to implement DSA or rather, only if the application implements DSA, that it be implemented in accordance with CMS Alg. The member was particularly concerned about constrained mobile devices not being able to implement DSA. The answer from Blake, and seconded by Russ, was that at a previous working group meeting it was decided that compliant applications must be capable of verifying signatures signed using both algorithms.

Jim asked if 2632bis should reference the PKIX algorithms Internet-Draft or CMS Alg? Blake answered that it will be changed to refer to the PKIX algorithms document.


Symmetric Key Distribution - Sean Turner

Sean briefed the status of the S/MIME Symmetric Key Distribution Internet-Draft, <draft-ietf-smime-symkeydist-05.txt>. Working group Last Call was issued on 1 May 2001. No comments were received on the list, some comments were sent directly to Sean. Almost all of the comments received were editorial. Based on the comments, the following changes were made:

- Moved section "Using the Group Key" (section 8) to section 1.3
- Clarified language for the conformance table in section 3.1
- Restricted Attribute Certificates to be version 2
- Made SKDAlgRequest syntax NULL
- Added information pointing out that there are multiple ways to wrap SignedData or EnvelopedData (to MIME wrap or not)
- Modified wording in section 4
- Copied wording from CMS Algs about symmetric key generation
- Expanded wording in Security Considerations

One of the suggestions was to change the name. Sean suggested "CMS Symmetric Key Management and Distribution." No one objected to the name change.

Sean asked whether the document needed to recycle through working group Last Call. Russ answered no; it is ready to go forward to the Area Directors.


X.400 and CMS - Chris Bonatti

Chris presented the status of the CMS X.400 Internet-Drafts. New versions of both "Securing X.400 Content with S/MIME", <draft-ietf-smime-x400wrap-03.txt>, and "Transporting S/MIME Objects in X.400," <draft-ietf-smime-x400transport-03.txt> were distributed on 19 July 2001.

The x400wrap document specifies how to protect X.400 content with CMS objects. It is roughly analogous to RFC 2633 (MSG). The changes incorporated into the -03 version include:

- Altered the requirements for CMS options (2.2 and 2.3) to align with the mandatory algorithms agreed for the Draft Standard work.

- Deleted from section 2.3 the statement that: The size of the private key is determined during key generation. This statement is algorithm specific and not pertinent to the topic at hand. The same comment may be raised against 2633bis.

- Clause 2.4.2 was updated to clarify the requirement in terms of MAY/SHOULD/MUST. The same comment may be raised against 2633bis.

- Text of 3.2 through 3.4 to remove intervening layers ContentInfo wrappers.

- Revised text of 3.2.1, 3.3.1, and 3.4.1 to reflect correct values of smime-type parameters as per the discussion on the mailing list.

A single editorial bug is known to exist in the -03 version: The second paragraph 3.2.1 needs to be updated to specify the smime-type parameter be set to "signed-x400" instead of "signed-data." This typo is minor has been discussed on the list.

The x400transport document specifies how to package CMS objects for transport by X.400 Message Transfer Agents (MTAs). It is separate from the X.400 wrapping draft to encourage use of RFC 822/MIME content in X.400 communities. The changes incorporated into the -03 version include:

- Clarified and corrected text of 2.3 describing how to forward CMS objects in X.420 IPMS messages.

- Assigned OID values for EITs in section 2.5.

- New text was added in section 2.6 to address use of X.400 EoS that may have impact on use of CMS security.

-- MTS Conversion Services: Does not apply to CMS content, but could result in destruction of the message or breaking the signature function. Conversion Prohibition EoS SHOULD be selected.

-- Message Redirection Services: The enveloped-data type requires an instance of RecipientInfo for each intended recipient or alternate recipient. Some types of redirection are not subject to originator control. If ORAR is used, an appropriate RecipientInfo element SHOULD be generated.

-- DL Expansion: The enveloped-data type requires processing by a secure mail list expander as described in ESS. When transporting CMS objects within an X.400 environment, the DL Expansion Prohibited service SHOULD be selected.

Chris believes both documents are ready for working group Last Call. Russ agreed to initiate working group Last Call once the typo is fixed in the X400wrap document.

Jim Schaad commented that a couple of small issues remain in both documents. Paul Hoffman believes these new issues need to be resolved, incorporated into new versions of the documents, and then sent to the mail list.


AES and RSA-OAEP in CMS - Jim Schaad

Jim presented a briefing on the updates to the "Use of the AES Encryption Algorithm and RSA-OAEP Key Transport in CMS" Internet-Draft, <draft-ietf-smime-aes-alg-02.txt>. The new draft includes the following changes:

- Removed the AuthenticatedData section. Since RSA is a key transport mechanism, there was no way to authenticate who sent the key.

- Added an AES overview.

- Added place holder examples for the key wrap algorithm -- awaiting Object Identifiers from NIST.

- Added AES EncryptedData section.

Jim listed the following work items as things left to be done:

- Get key wrap algorithm OID assigned by NIST

- Once done, complete AES key wrap examples

- Add ASN.1 appendix to define a couple of ASN.1 items that RFC 2437 omits.

- Resolve password recipient info key wrap issues

Other algorithms that may be added to the document at a later date include the RSA Probabilistic Signature Scheme (PSS) algorithm and the SHA-2 hash algorithm. The specification of the PSS algorithm has not progressed, and its OID and definitions are still unspecified. The SHA-2 algorithm details for use with DSA have not been released by NIST at this time. Use of SHA-2 with RSA is awaiting specification of the PSS algorithm.

Blake asked when would the working group know anything about SHA-2? Jim answered that the issue was brought up with RSA at the last working group and nothing has been done since. Russ commented that PSS is still being coordinated with the various communities that will use it. Russ was asked if PSS will be specified in a PKCS document and he answered that yes it would.

A comment was made that the SHA-2 draft has been out for a long time. Jim clarified that the question was when will the DSA key sizes and OIDs for DSA with SHA-2 be known. Mike Chernick noted that NIST completed the specification of SHA-256, but he didn't know when the DSA specification would be updated.


Elliptic Curve Cryptography - Simon Blake-Wilson

Simon presented a brief synopsis of the state of the "Use of ECC Algorithms in CMS" Internet-Draft, <draft-ietf-smime-ecc-06.txt>, 7 May 2001. The document has completed both working group Last Call and IETF Last Call.

Russ took an action to follow up with the Area Directors on this document and the others (rcek and domsec) that are awaiting the ADs attention.

Simon noted that three independent implementers have conducted interoperability testing. Simon is currently working on an examples draft.


S/MIME Gateway Protocol - Blake Ramsdell

Blake briefed the working group on the "S/MIME Gateway Protocol", Internet-Draft, <draft-ramsdell-enc-smime-gateway-00.txt>, 12 July 2001. The protocol specifies how to use S/MIME to perform server-to-server (gateway) encryption between cooperating domains. The Massachusetts Health Data Consortium led the development of the protocol and its prototyping in order to comply with the United States Health Information Protection Act (HIPA). Six S/MIME server vendors, Tumbleweed, Baltimore Technologies, DICA, Vanguard, Tenfour, and VIASEC participated in the effort. Deloitte & Touche conducted an independent interoperability test and evaluation of the vendor products.

Blake asked the working group what should be done with the specification. Currently it is an independent Internet-Draft under his name. Should it be a working group work item? Should it be considered a profile of DOMSEC?

Russ asked the working group members, who read the document? Only a couple of members had read it. Paul Hoffman commented that this document is an important document since it increases the use of S/MIME, but without having to burden users with the details and complexity. Paul recommends that all working group members read the document and encourage similar use of S/MIME wherever possible.

A comment was made that if this document is to be made a working group work item that it should be aligned with DOMSEC. Also, if encryption is the only service provided by this solution, isn't this solution vulnerable to a man-in-the-middle attack? Blake responded by noting that the key management for this solution is handled outside the document.

The same individual asked Paul why SMTP over TLS was not considered. Paul answered that SMTP/TLS is ok, but it's point-to-point, so if multiple SMTP hops are involved, each hop would require a separate TLS session. In general, Paul felt that S/MIME implementations are more widely available then implementations of SMTP over TLS.

A comment was made that the man-in-the-middle attack mentioned earlier isn't an issue since the To addressee's domain is used to find the correct certificate for the intended recipient.

Russ asked if Bill Ottaway had looked at DOMSEC in comparison with Blake's document. Bill had not. Russ requested Bill post a comparison to the list and the working group can go from there.


NIST S/MIME Activities - Mike Chernick

Mike briefed the working group on the current S/MIME activities at the U.S. National Institute of Standards and Technology (NIST). Mike described the mission of his group as "to accelerate deployment of secure interoperable S/MIME products." They are currently working on three major projects: an in-house laboratory, the S/MIME v3 client profile, and an internet-based S/MIME test facility.

The first purpose of the S/MIME v3 profile is to identify the subset of S/MIME v3 specifications that helps to assure interoperability, promotes secure communications at reasonable cost, and serves as a basis for test development. The second purpose of the profile is to serve as guidance for COTS product procurement and development. The profile is relatively short (17 pages) and is currently out for public comment until mid-September 2001. The profile is available at the following URL:

The profile specifies the mandatory parts of RFCs 2630, 2632, and 2633, except Diffie-Hellman key agreement not required. The mandatory CMS algorithms are required, plus the profile requires support for both RSA (V1.5, RFC 2313) and DSA (FIPS 186-2) digital signatures. Key sizes of at least 1024 bits for RSA and DSA are required. Use of Diffie-Hellman keys and derivation of KEKs as defined in RFC 2631 is encouraged but NOT required.

The profile requires selected features from RFC 2634, Enhanced Security Services, including Signed Receipts processing: request (non-third party) signed receipt, generate signed receipt upon request, and match signed receipt to original message. The profile also requires that the mlExpansionHistory attribute MUST be processed.

The profile has the following message generation requirements:
- Send "clear" signed messages that include generation of SignerInfo, SMIMECapabilities Attribute, and sending of user certs and CRLs
- Send encrypted message
- Send signed and encrypted messages
- Send to multiple recipients

The profile requires clients to support receiving and processing both "clear" and "opaque" signed messages and receiving and decrypting messages sent to multiple recipients.

The profile requires implementations to construct certification paths between accepted trust points and the sender's or intended recipient's certificates. Tests will include paths with multiple CA certificates. Testing will require use of LDAP and the processing of the standard directory attributes (RFC 2587). The profile requires that client perform path validation in accordance with RFC 2459, Section 6.

Mike was asked if the profile will be changed to require son-of-RFC2459, rather than RFC 2459. Mike answered yes. In general, the profile will be updated to require the latest version of the various specifications, as practical.

The automated S/MIME test facility is currently being developed by NIST using the Getronics S/MIME Freeware Library (SFL) as reference implementation. The test facility will test scenarios to cover S/MIME v3 profile requirements and options, but NOT out-of-scope S/MIME features. The test facility will ensure conformance of vendor implementations to S/MIME v3 client profile. Information and instructions will be available over the web; SMTP will be used for testing. The automated test facility will support both originator and recipient roles, but will require "human scoring" and self-scoring for some tests. The automated test facility will help identify ambiguities and errors in IETF specifications, the NIST profile, and the SFL reference code.

Some notes about the automated S/MIME test facility are:
- Objective testing wherever possible
- Anonymous testing possible
- Results only to remote tester
- All required communications through e-mail
- Not publishing remote tester's certificates and CRLs
- Using test policy OIDs

Mike also presented the test facility architecture and walked through several sample scenarios.

More information about the NIST S/MIME group can be found on their web site: http://csrc.nist.gov/pki/smime

Mike was asked if people outside the United States will be able to use the automated test facility, and answered yes. Blake Ramsdell asked if successful tests would be published. Mike answered that test results may possibly be published. Blake asked if the purpose of this testing is to test and certify S/MIME products for the U.S. government, in addition to FIPS 140? Mike answered that the purpose of this testing is to encourage interoperable implementations, and is much more informal than FIPS 140. Blake asked for clarification if there will be a requirement for U.S. government agencies to only use products that pass the NIST S/MIME testing. Mike answered certainly not at this point -- that is not their intention.

Simon asked how the algorithm recommendations in the S/MIME v3 profile relate to FIPS 186? Mike answered that the algorithms are aligned with FIPS 186. Tim Polk seconded that answer and noted that the profile allows optional algorithms such as AES, to position the profile for the future.

Russ asked if a U.S. federal agency could require, in a procurement document, S/MIME implementations that pass this testing. Tim clarified that an agency could require S/MIME implementations that match the profile. Tim suggested that one way a vendor could demonstrate profile compliance would be to pass the conformance tests. Tim stated that NIST will not perform any product testing nor certify any results.

As a follow-up, Simon asked if there will be a FIPS 186-3, that permits PKCS v1.5? Tim answered yes. Simon also asked if we can make assumptions about what the FIPS on key management is going to say? Tim answered no, key management is much earlier in its evolution, and is subject to change.

A comment was made that this testing seems to be geared to vendors performing vendor testing. Publishing results would be useful to users.

Paul commented that publishing results while useful, can be dangerous due to misleading information being provided. He recommends general comments be published rather than specific product results. Mike agreed that NIST won't publish specific results, only statistical summaries.


Reuse of Content Encryption Keys - Steve Farrell

Steve briefed the status of the "Reuse of CMS Content Encryption Keys" Internet-Draft, <draft-ietf-smime-rcek-04.txt>, 28 May 2001. Steve noted that there is no status to report -- the working group has finished with it. IETF Last Call was completed on 23 June 2001 and the document is with the Area Directors.

Russ took an action to check with the ADs to determine the status of the document.


ETSI ESI Working Group - Denis Pinkas

Denis briefed the working group on several draft European Telecommunications Standards Institute (ETSI) Electronic Signature & Infrastructure (ESI) working group documents that are out for public review and comment. Comments are requested by September 2001. The documents are freely available from: http://www.etsi.org/sec/el-sign.htm

The three draft documents are:
- XML Advanced Electronic Signatures (XAdES)
- Policy Requirements for CAs
- Policy Requirements for Time-Stamping Authorities

The first document, XML Advanced Electronic Signatures, provides, for XML data, the same functionality as the Electronic Signature format specification, which uses CMS (i.e. ASN.1), but instead of using CMS uses the XMLDigSig specification with additions. In the same way CMS uses signed attributes and unsigned attributes, XAdES uses SignedSignatureProperties and UnsignedSignatureProperties. In addition, it also uses SignedDataObjectProperties since multiple portions of an XML document can be globally signed by one signer. It can be seen as an "xmlElSign", i.e. an equivalent to CMS in the XML world for signatures (encryption features are not supported). The work has been done with close coordination with W3C.

The second document, Policy Requirements for CAs, is based on TS 101 456 and defines policy requirements for CAs issuing Qualified Certificates and specifies policy requirements for CAs supporting public key certificates used to support:

- electronic signatures,
- digital signatures,
- encryption,
- key exchange and
- key agreement mechanisms.

Comments to this document are particularly sought on the following points:

- A number of requirements have been selected for defining different quality levels, where each level should represent a consistent set of requirements related to threats and risks involved with the environment of the service. This has critical effects of the sensitivity of the service with regard to cost or/and security.

- Are these levels appropriate from a market point of view or would other level(s) be more useful?

- Comments based on different business scenarios would help in order to address wide segments of practical applications.

The last document, Policy Requirements for Time-Stamping Authorities, is primarily targeted to support a Time-Stamping Service adequate for Qualified Signatures, but can also be used in other contexts. Comments to this document are particularly sought on the following points:

- One baseline policy has been introduced, however the TSA has the possibility to define its own policy by adding enhancements to the baseline policy. How can this be done?

- Naming convention for identifying the TSA.

- Verification of a time-stamp beyond the end of the validity period of the certificate of the TSA.

On the last issue, typically two things must be done:

- New TST MUST be applied before the end of the validity period of the certificate, so that it can remain valid.

- The CRL (or an OCSP response) from the CA that has issued the TSA certificate MUST also be captured, to prove that the time-stamp was still valid when the additional TST was applied.

Question: What if the key is compromised?

Denis: Certificate will be revoked on CRL, so time stamp applied by revoked cert will be invalid.

To avoid re-applying a time stamp every time a TSA certificate is due to expire (for example, five years), this could be avoided if:

- Key generation and public key certification is done correctly,
- The private key is zeroized at the end of the validity period of the certificate, and
- No backup of the private key is ever done.

The private key is very unlikely to be compromised, even beyond the end of the validity period of the certificate of the TSA.

A TST would remain verifiable beyond the end of the validity period of the certificate of the TSA, if it can be known/proven that:

- the TSA private key has not been compromised at any time during the validity period of the certificate, and beyond,

- the hash algorithms used in the TST exhibits no collisions,

- the key size of the signature algorithm under which TST has been signed is still beyond the reach of cryptographic attacks (as well as the signature algorithm itself).

However, there is no guidance on how these conditions can be met in practice. PKIX-1 says: The certificate validity period is the time interval during which the CA warrants that it will maintain information about the status of the certificate. An extension to the PKIX / X.509 model, might be appropriate, e.g., by mandating the CA to handle the revocation status of TSA certificates beyond the end of their validity period.

More specifics on these issues can be found by reading the documents, which are available at: http://www.etsi.org/sec/el-sign.htm

Question: Regarding the time stamping authority. What if cryptography advances and the algorithms are no longer secure?

Denis: A second time stamp should have been applied before the vulnerabilities with the first time stamp algorithms are found or exploited.

Stefan Santesson: Why would revocation information need to be maintained after certificate expiration?

Denis: Once compromised, time stamps with any dates can be generated and can no longer be trusted. Therefore, revocation information must be published even after expiration.

Comment: The date when TSA's key was compromised is important. If a client verifies a time stamp before the key is compromised, time stamp could still be considered valid since it was known to be valid prior to revocation of the TSA's certificate.

Denis: The client's verification process cannot be trusted by a third party. It's better to just apply more than one time stamp, as that is more secure than relying on a single time stamp.


CMS Version Issue Revisited - Russ Housley

Russ decided to revisit the CMS version issue again. Russ asked the question differently:

1. Who objects to the current approach?
2. Who objects to changing the approach to where the subordinate components handle the version number and the implementations are required to gracefully handle decode errors?

A comment was made that a third question, "Who doesn't care?" should also be asked.

Russ asked the three questions with almost no response to the first two questions. The working group members that responded answered only to the third question, that they don't care.

Russ noted that the working group did not give him much guidance on this issue.


S/MIME Freeware Library (SFL) - Rich Nicholas

Rich presented a brief overview of the SFL, a freeware implementation of RFCs 2630 and 2634 developed by Getronics Government Solutions. Rich described the various Getronics freeware security libraries and a high level architecture depicting their relationship. The libraries are:

- S/MIME Freeware Library

-- Implements S/MIME v3 CMS/ESS security protocol.

-- Provides ESS features: security labels, signed receipts, secure mail list info, signing certificate.

- Certificate Management Library

-- Validates PKIX X.509 v3 certification paths & CRLs.

-- Provides local cert/CRL storage functions.

-- Provides remote directory retrieval via LDAP.

- Access Control Library

-- Provides Rule Based Access Control using security labels and authorizations conveyed in either X.509 Attribute or public key certificates.

- Enhanced SNACC ASN.1 library provides 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 SFL is freeware implementation of RFC 2630 (CMS) and RFC 2634 (ESS). When used with the Crypto++ library, the SFL implements RFC 2631 Ephemeral-Static (E-S) Diffie-Hellman (D-H) Key Agreement Method. The SFL supports RFC 2632 (Certificate Handling) and RFC 2633 (Message Specification). The goal of the SFL is to provide a reference implementation of RFCs 2630 & 2634 to encourage acceptance as Internet Standards.

The SFL:
- Can be used to protect any type of data (not just MIME)
- Maximizes crypto algorithm independence
- Successfully used by many commercial vendors

Getronics has used the SFL to perform a significant amount of S/MIME v3 interoperability 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 document 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 most CMS/ESS features.

Rich presented the current status of the various Getronics freeware libraries:

- SFL v1.10 (relesaed April 2001):

-- Tested on RedHat Linux, Windows NT/98/00, Solaris 2.7.

-- Fixed bugs in v1.9 SFL and accompanying CTILs.

-- Added support for SHA-256 use with RSA (use with DSA TBD).

- CML v1.9.2 (released July 2001)

-- Fixed bugs in v1.9 CML.

- Enhanced SNACC v1.3 R6 (released April 2001) fixed bugs.

- Access Control Library v1.6 (released May 2001)

-- Supports multiple Clearance attributes in an X.509 attribute certificate or public key certificate.

Major new releases planned for September 2001.

The Internet Mail Consortium (IMC) has established SFL, CML and Enhanced SNACC mail lists. Rich 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. No additional issues were raised.

Meeting adjourned.


S/MIME Freeware Library
Status of CMS-X.400 Drafts
NIST S/MIME Activities
Cryptographic Message Syntax (CMS) Status
S/MIME Working Group Status
Request for comments from the ETSI ESI working group
CMS Interop Matrix
S/MIME Symmetric Key Distribution