This message includes the minutes of the IETF S/MIME Working Group
(WG) meeting held on 15 July 1999 in Oslo, Norway. All briefing slides
are 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. It was identical to that publicized prior to the
meeting except that the DOMSEC Draft Discussion was cancelled and Russ
substituted for several of the presenters who were unable to attend the
meeting. Nobody objected to the agenda.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RFC 2630-2634 Status - Russ Housley
The following IETF S/MIME v3 Proposed Standards are available at
http://www.ietf.org/rfc/:
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
To become Internet Draft Standards, the aforementioned documents must
meet the following requirements:
1) Exist as Proposed Standards for 6 months.
2) Each MUST and SHOULD requirement must be implemented by at least two
independent implementations such that they are interoperable.
Russ requested that all S/MIME v3 implementors provide a description of the
S/MIME v3 features that are supported by their implementation.
Paul Hoffman stated that RFC 2632 is dependent on RFC 2459 (Internet X.509
Public Key Infrastructure Certificate and CRL Profile), so RFC 2632 can not
become a Draft Standard until RFC 2459 becomes one. Similarly, RFC 2633 is
dependent on RFC 2632 and RFC 2634 is dependent on RFC 2633. Therefore, RFC
2459 must become a Draft Standard before RFC 2632, RFC 2633 or RFC 2634 can
become Draft Standards. Paul noted that there are still unresolved issues
with RFC 2459. Russ stated that neither RFC 2630 nor RFC 2631 are
dependent on the portions of RFC 2459 that are unresolved.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Charter Revision - Russ Housley
Russ reviewed the following proposed changes to the S/MIME WG charter that
he had previously sent to the mail list.
==============================================================
Small Subgroup Attacks:
The use of D-H 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.
Proposed Milestones:
History: First "Methods for Avoiding the "Small-Subgroup" Attacks on the
Diffie-Hellman Key Agreement Method for S/MIME" Internet-Draft (I-D)
published.
Aug 1999: Last call.
Nov 1999: Submit Informational RFC.
==============================================================
Additional Algorithms
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.
Proposed Milestones:
History: First "CMS KEA and SKIPJACK Conventions" I-D published.
First " Incorporation of IDEA encryption algorithm in S/MIME" I-D
published.
Aug 1999: KEA and Skipjack last call.
Nov 1999: KEA and Skipjack Informational RFC.
Dec 1999: IDEA last call.
Mar 2000: IDEA Informational RFC.
==================================================================
CMS and ESS Examples
To aid implementors, documents containing example output for CMS and ESS
will
be collected and published.
Proposed Milestones:
History: First "Examples of S/MIME Messages" I-D published.
Dec 1999: Last call.
Mar 2000: Informational RFC.
Russ asked that implementors provide interesting invalid cases in addition
to valid cases.
==================================================================
CERTDIST
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.
Proposed Milestones:
History: First "Certificate Distribution Specification" I-D published.
Sep 1999: Last call.
Jan 2000: Proposed Standard RFC.
==================================================================
Password-based Key Management
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.
Proposed Milestones:
History: First "Password-based Encryption for S/MIME" I-D published.
Dec 1999: Last call.
Mar 2000: Proposed Standard RFC.
==================================================================
Mail List Key Distribution
S/MIME version 3 supports encrypted mail lists. Specifications for the
distribution of symmetric mail list keys to mail list agents (MLAs) and
message recipients will be developed. The specification will be
cryptographic algorithm independent.
Proposed Milestones:
Sep 1999: First Mail List Key Distribution I-D will be published.
Jan 2000: Last call.
Mar 2000: Proposed Standard RFC.
Russ stated that an editor is needed for this document. He stated that this
I-D will document the distribution of pre-placed symmetric keys that can be
used to process CMS KEKRecipientInfo. He noted that this capability can be
used for purposes other than to support mail lists.
==================================================================
Security Label Usage
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 corporations will
be used as examples.
Proposed Milestones:
Jul 1999: First Security Label Usage I-D will be published.
Nov 1999: Last call.
Feb 2000: Informational RFC.
==================================================================
DOMSEC
S/MIME version 3 can be used to protect electronic mail to and from a
domain. "Domain Security Services" result when the S/MIME v3 processing is
performed by message transfer agents, guards or gateways. Mechanisms are
needed to solve a number of interoperability problems and technical
limitations that arise when domains supporting different security policies
wish to interoperate.
Proposed Milestones:
History: First "Domain Security Services using S/MIME" I-D published.
Jul 2000: Last call.
Sep 2000: Experimental RFC.
Sean Turner asked if the proposed charter could be changed to allow I-Ds to
be submitted that document environments other than those described in the
DOMSEC I-D. Russ stated that he would edit the text in the charter
regarding DOMSEC so that it is more generic to allow other I-Ds to be
submitted.
==================================================================
Charter Wrap-Up
Russ asked if any attendees knew of any issues, had comments or wished to
discuss any related topics. He asked if the attendees believed that the
revised charter was ready for the Security Area Directors and IESG.
Paul Hoffman requested that text be added to the charter that allows work to
be performed related to adding other options for mandatory-to-implement
strong encryption algorithms.
Jim Schaad asked if the WG should consider replacing D-H with RSA as the
mandatory-to-implement key management algorithm once the RSA patent expires.
Russ added that the RSA patent expires in about a year.
An attendee expressed his opinion that the RSA algorithm should be
deprecated from the S/MIME v3 specifications altogether.
Another attendee stated that European software uses the RSA algorithm
because the RSA patent doesn't apply outside of the US.
Andrew Farrell requested that the name of the Mail List Key Distribution I-D
be changed to "Previously-Distributed Symmetric Keys". Nobody objected.
Paul Hoffman recommended that the WG should consider replacing D-H with RSA
as the mandatory-to-implement key management algorithm, but not to associate
any milestones with the work.
Russ stated that he will send out a revised draft charter.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Avoiding Small Subgroups - Russ Housley
Robert Zuccherato generated the "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for S/MIME" I-D. Russ
stated that the I-D has not has not been discussed much on the mail list.
The WG is obligated to generate this I-D to address the subject
vulnerabilities. He strongly recommends that implementors read the I-D so
that they are aware of the vulnerabilities. He asked how many attendees
have read the I-D. Only 6 people raised their hands. Russ asked that the
WG members review and provide comments to the document.
Tony Mione stated a comment to the I-D. Russ asked him to send his
comment to the mail list, and he did so. See Tony's 15 July 1999 message
sent to the list, subject: "Quick comment on the Small Subgroup Attack
draft".
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CERTDIST Draft Discussion - Jim Schaad
Jim stated that he has only received comments from Russ to the 25 February
1999 Certificate Distribution (CERTDIST-03) I-D.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CMS/ESS Examples - Paul Hoffman
Paul stated that the following companies have been participating in the
generation of the "Examples of S/MIME Messages" I-D: Microsoft, Worldtalk,
Baltimore, SPYRUS and J.G. Van Dyke & Associates (VDA). He stated that the
June draft includes placeholders for examples from ESS. He requested that
the WG members review the I-D and provide comments. He is planning to
establish an "Examples" mail list for people to exchange information
regarding interoperability testing. The document will include some
incorrect examples that flag common implementation errors including
explanations of the mistakes. Russ stated that he is especially looking
for folks who have implemented the AuthenticatedData, EncryptedData
and/or DigestedData content types.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Security Policies and Labels - Russ Housley
Russ stated that Weston Nicolls is developing an I-D that will document the
security policies of Whirlpool, Caterpillar and Amoco. The draft will
document how the ESSSecurityLabel can be used to implement those
corporations' security policies.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
S/MIME Freeware Library (SFL) - John Pawling
The SFL is a freeware implementation of RFC 2630 and RFC 2634. It uses the
Crypto++ freeware library to implement RFC 2631. It provides functions to
support the use of RFC 2632 and RFC 2633. The goal of the SFL is to provide
a reference implementation of RFC 2630 and RFC 2634 to encourage their
acceptance as Internet Standards. VDA is developing the SFL.
The SFL protects any type of data (not just MIME). It is algorithm
independent. It is used with external crypto libraries that provide the
crypto algorithms. It uses the VDA-enhanced SNACC freeware library to
perform all ASN.1 encoding (including DER) and decoding of CMS and ESS
objects as well as certificates, CRLs, etc. All SFL source code is provided
(all code is C++).
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 v3.0 and Crypto++ v3.0 libraries. VDA is currently enhancing the SFL
to work with the Fortezza Cryptologic Interface Library and SPYRUS SPEX/
Library.
VDA provides several test utilities along with the SFL including:
- Test driver to build and process a variety of CMS/ESS messages;
- Test utility that processes and displays contents of MIME encoded messages
containing single body part or multi-part CMS/ESS components; and
- Test utility to generate key material, certificates (such as D-H) and
CRLs.
Version 1.0 SFL was released in June 1999. It was tested on MS Windows
95/NT, Sun Solaris 2.6 and Linux. It was tested using the mandatory and RSA
algorithm suites. VDA continues to enhance the SFL.
The SFL has been used to exchange signedData and envelopedData messages with
MS Internet Explorer Outlook Express v4.01 and Netscape Communicator 4.X.
Signed messages have been exchanged with RSA S/MAIL, WorldTalk and Entrust
S/MIME v2 products. S/MIME v3 interoperability testing between SFL and
Microsoft includes all envelopedData features such as using Ephemeral-Static
D-H pairwise key with 3DES-wrapped and RC2-wrapped content encryption keys.
RSA-signed signedData messages have also been exchanged. The majority of
the ESS features have been tested. S/MIME v3 interoperability testing also
performed with Baltimore, Inc. VDA plans to participate in the IETF S/MIME
WG interoperability testing including providing CMS/ESS messages for
inclusion in the S/MIME "Examples of S/MIME Messages" document.
Organizations can use the SFL as part of their applications without paying
any royalties or licensing fees (see SFL Public License). VDA-enhanced
SNACC ASN.1 software and SFL documents are freely available to everyone at:
http://www.jgvandyke.com/services/infosec/sfl.htm. All other portions of
the SFL are available at:
http://www.armadillo.huntsville.al.us/software/smime and are export
controlled as per U.S. Government Export Administration Regulations (see:
http://www.bxa.doc.gov/Encryption/Default.htm).
The IMC has established an SFL mail list to: distribute information
regarding SFL releases; discuss SFL-related issues; and provide a means for
SFL users to provide feedback, comments, bug reports, etc. Subscription
information for the imc-sfl mailing list is at IMC SFL web page:
http://www.imc.org/imc-sfl.
An attendee asked if there was any way that the SFL could be obtained from
outside the U.S. John stated that the vendor would need to obtain an export
license and referred him to the aforementioned U.S. Government Export
Administration Regulations web page. Several attendees then discussed how
the SFL could be distributed outside the U.S. such as publishing the source
code in a book.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Wrap Up - Russ Housley
None of the attendees had any other comments or issues.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ACTION ITEMS:
1. Tony Mione will send his comment regarding the Avoiding Small Subgroup
Attacks I-D to the mail list.
2. ALL S/MIME v3 Implementors: Provide a description to Russ of the S/MIME
v3 features that are supported by your software.
3. ALL S/MIME v3 Implementors: Provide valid and invalid sample data to Paul
Hoffman for inclusion in the "Examples of S/MIME Messages" I-D.
4. Russ will send the revised charter to the mail list.
====================================================================
John Pawling, Director - Systems Engineering, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc., a Wang Government Services Company
====================================================================