NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-00
Chair(s):
Russ Housley <housley@spyrus.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Mailing Lists:
General Discussion:ietf-smime@imc.org
To Subscribe: ietf-smime-request@imc.org
Archive: http://www.imc.org/ietf-smime/
Description of Working Group:
The S/MIME Working Group has completed five Proposed Standards that comprise the S/MIME version 3 specification. Current efforts build on these base specifications.
The use of Diffie-Hellman Key Agreement as the mandatory to implement key establishment mechanism may expose some implementations to vulnerabilities based on "small subgroup" attacks. An informational document will be prepared describing techniques that can be used to avoid these attacks.
The Cryptographic Message Syntax (CMS) is cryptographic algorithm independent, yet there is always more than one way to use any algorithm. To ensure interoperability, each algorithm should have a specification that describes its use with CMS. Specifications for the use of additional cryptographic algorithms will be developed. An additional suite of 'mandatory to implement' algorithms may be selected.
To aid implementers, documents containing example output for CMS will be collected and published. Some of the examples will include structures and signed attributed defined in the Enhanced Security Services (ESS) document.
Current methods of publishing certificates in the Directory do not allow the inclusion of secondary support information such as the SMimeCapabilities attribute. A method of publishing certificates along with authenticated secondary support information will be defined.
In some situations it would be advantageous for the CMS RecipientInfo structure to support additional key management techniques, including cryptographic keys derived from passwords. A mechanism to facilitate the definition of additional key management techniques will be defined. S/MIME version 3 permits the use of previously distributed symmetric key-encryption keys. Specifications for the distribution of symmetric key-encryption keys to mmultiple message recipients will be developed. Mail List Agents (MLAs) are one user of symmetric key-encryption keys. The specification will be cryptographic algorithm independent.
S/MIME version 3 supports security labels. Specifications that show how this feature can be used to implement an organizational security policy will be developed. Security policies from large organizations will be used as examples.
S/MIME version 3 can be used to protect electronic mail to and from a domain. In such an environment, S/MIME v3 processing is performed by message transfer agents, guards, and gateways in order to provide "Domain Security Services." Mechanisms are needed to solve a number of interoperability problems and technical limitations that arise when domains supporting different security policies wish to interoperate.
The S/MIME Working Group will attempt to coordinate its efforts with the OpenPGP Working Group in areas where the work of the two groups overlap.
Goals and Milestones:
Done |
|
First draft of CMS RecipientInfo extension. |
Done |
|
First draft of security label usage specification. |
Done |
|
Last call on small subgroup attack avoidance |
Done |
|
First draft of CAST algorithm specification. |
Done |
|
Last call on KEA and SKIPJACK algorithm specification. |
Done |
|
First draft of mail list key distribution. |
Done |
|
Last call on certificate distribution specification. |
Nov 99 |
|
Last call on security label usage specification. |
Done |
|
Updated draft of domain security services document. |
Done |
|
Last call on CAST algorithm specification. |
Done |
|
Submit small subgroup attack avoidance as Informational RFC |
Done |
|
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. |
Done |
|
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. |
Done |
|
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. |
Done |
|
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. |
Internet-Drafts:
· Domain Security Services using S/MIME
· Use of the IDEA Encryption Algorithm in CMS
· Password-based Encryption for S/MIME
· Use of ECC Algorithms in CMS
· Compressed Data Content Type for S/MIME
· Implementing Company Classification Policy with the S/MIME Security Label
· S/MIME Symmetric Key Distribution
· Electronic Signature Formats for long term electronic signature
· Use of the RSAES-OAEP Transport Algorithm in CMS
· Electronic Signature Policies
· Reuse of CMS Content Encryption Keys
· Transporting S/MIME Objects in X.400
· Securing X.400 Content with S/MIME
Request For Comments:
RFC |
Status |
Title |
RFC2311 |
S/MIME Version 2 Message Specification | |
RFC2312 |
S/MIME Version 2 Certificate Handling | |
RFC2630 |
PS |
Cryptographic Message Syntax |
RFC2631 |
PS |
Diffie-Hellman Key Agreement Method |
RFC2632 |
PS |
S/MIME Version 3 Certificate Handling |
RFC2633 |
PS |
S/MIME Version 3 Message Specification |
RFC2634 |
PS |
Enhanced Security Services for S/MIME |
RFC2785 |
Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME | |
RFC2876 |
Use of the KEA and SKIPJACK Algorithms in CMS | |
RFC2984 |
PS |
Use of the CAST-128 Encryption Algorithm in CMS |
This message includes the minutes of the IETF S/MIME Working Group (WG) meeting held on 13 December 2000 in San Diego,
California. Briefing slides will be available from <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 commented on the agenda.
Introductions Russ Housley
Working Group Status Russ Housley
Interoperability Matrix Jim Schaad
CMS and ESS Examples Paul Hoffman
Security Policies and Labels Weston Nicolls
Symmetric Key Distribution Sean Turner
Domain Security (DOMSEC) Bill Ottaway
X.400 and CMS Chris Bonatti
Reuse of Content Encryption Keys Steve Farrell
Advanced Encryption Standard Jim Schaad
RSA-OAEP and RSA-PSS John Linn
RSA as a MUST implement Blake Ramsdell
E-Signature Formats using CMS John Ross
E-Signature Formats using XML Denis Pinkas
S/MIME Freeware Library John Pawling
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 (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
The aforementioned documents must meet the following requirements to advance 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 (I-D) (draft-ietf-pkix-new-part1-03.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 and have not been successfully tested. So far, 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 theS/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. He asked that other organizations that have developed S/MIME v3 capabilities should please participate.
Russ said he would submit that proposal to the S/MIME WG mail list.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Interoperability Matrix - Jim Schaad
Jim discussed the interoperability matrix for RFCs 2630 through 2634. He has documented the successful completion of two-way interoperability testing for the following number of clauses in each RFC. He has not completely updated the results based on all interop testing performed:
RFC Clauses Tested
=========================
2630 49 of 96
2631 0 of 13
2632 16 of 21
2633 17 of 61
2634 27 of 81
More details regarding RFC 2630 testing:
Signed Data - 24 of 25
Enveloped Data - 11 of 25
Digested Data - 0 of 4
Encrypted Data - 0 of 4
Authenticated Data - 0 of 16
Other MUST Implement Requirements - 15 of 25
TOTAL - 49 of 96
More details regarding RFC 2634 testing:
Triple Wrap - 3 of 5
Signed Receipts - 19 of 41
Security Labels - 5 of 11
Equivalent Labels - 0 of 12
Mail List - 0 of 12
TOTAL - 27 of 81
Jim asked for others to submit input to him at jimsch@exmsft.com.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Examples of S/MIME Messages - Paul Hoffman
Paul stated that he had distributed a new release of the "Examples of S/MIME Messages" I-D <draft-ietf-smime-examples-05.txt>, November 2000, that includes additional sample data generated by Getronics using the SFL. He stated that the document needs further input and testing. He noted that Jim Schaad is testing all of the samples included in the document. John Pawling recommended that a triple-wrapped sample message should be added to the document. Jim has already generated several triple-wrapped messages and will provide them to Paul for inclusion in the document.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Mapping Company Classification Policy to the S/MIME Security Label - Weston Nicolls
Weston stated that he had distributed a new release of the "Implementing Company Classification Policy with the S/MIME Security Label" I-D, <draft-ietf-smime-seclabel-02.txt>, October 2000. He noted that his goal is for the document to become an Informational RFC. It provides examples of how the RFC 2634 ESSSecurityLabel feature can be used to support an organization's security policy. The document includes classification policies and example security labels for the Amoco, Caterpillar and Whirlpool corporations. It includes an example security category syntax and samples. It also includes Clearance attribute examples that include a subject's authorizations.
Russ Housley proposed that Last Call for this document should be completed by January 2001. Nobody objected.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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-02.txt>, October 2000. Sean noted that Jim Schaad provided significant comments to the symkeydist-01 I-D that Sean incorporated into the symkeydist-02 I-D.
Sean stated that two messages were added: GLProvideCert and GLUpdateCert. The GLDistributionMethod message was removed. The GLInfo, GLOwner, and GLMember syntaxes were modified to include "address" information. There were many changes made to more closely align with RFC 2797 Certificate Management Messages over CMS. He added text to explain how many and when rekey messages are distributed. The rekey defaults were fixed.
Sean stated that he still needed to add a conformance clause and an Abstract Syntax Notation One (ASN.1) module. He also needs to verify correctness of RFC 2797 error behavior.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
DOMSEC Draft Discussion - Bill Ottaway
Bill presented a briefing regarding the "Domain Security Services Using S/MIME" I-D <draft-ietf-smime-domsec-07.txt>, November 2000. He made several minor changes as a result of e-mail exchanges with Jim Schaad on the S/MIME WG mail list.
He added a section regarding Mail List Agents (MLA) that addresses the situation in which an MLA will remove the 'domain signature' when the signature encapsulates a mlExpansionHistory attribute and/or a envelopedData type. He briefed the solution to this problem which is documented in domsec-07 in Section 5, "Applying a Domain Signature when Mail List Agents are present". He stated that the he believes that the outstanding issues have been resolved and that the DOMSEC I-D should be submitted for last call.
Russ Housley proposed that the DOMSEC document is ready for S/MIME WG Last Call. The intent is for this document to be published as an Experimental RFC. Russ proposed that the S/MIME WG Last Call should close on 10 January 2001. Nobody objected.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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. The x400wrap I-D specifies how to protect X.400 content with CMS objects. It is roughly analogous to RFC 2633 and refers to RFC 2633 when applicable. It minimizes the use of MIME encodings to reduce overhead. He briefed the proposed wrapping strategy. He discussed the object identifiers used, MIME heading parameters and detached signature form. He has already incorporated comments submitted by Bill Ottaway and Graeme Lunt.
Chris noted that products generally do not support encapsulating content types other than data (such as signed-data or enveloped-data). Jim Schaad challenged that statement and noted that the Microsoft, SFL and Peter Gutmann's cryptlib S/MIME v3 implementations do support encapsulating content types other than data.
The x400transport I-D specifies how to package CMS objects for transport by X.400 Message Transfer Agents (MTA). It discusses the scenario in which the CMS encapsulated content is an RFC 822 MIME message. It states that the outer MIME wrapper is not generally necessary in X.400. It also states that circumstances may exist when the outer MIME wrapper is desirable such as when a gateway into an SMTP transport is part of the architecture. Chris discussed the object identifiers used, packaging the CMS object in the X.400 content and that messages that only contain certificates are not supported. He has incorporated comments submitted by Bill Ottaway.
Blake Ramsdell asked about support for messages that only contain certificates. Chris responded that messages that only contain certificates are supported, but they can't be identified as such in the wrapper.
Chris recommended that these I-Ds be placed on the standards track and asked for feedback from the WG. Russ Housley and Jeff Schiller agreed with Chris' recommendation.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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-00.txt>, September 2000. The rcek I-D specifies how to set up a shared secret key using asymmetric crypto (using EnvelopedData object) and then to re-use the content encryption key (CEK) to derive the Key Encryption Key (KEK) of the next message. It defines attributes for inclusion in EnvelopedData objects that indicates that the CEK is to be re-used and the maximum number of times that it can be re-used.
Steve noted that the I-D specifies a key derivation scheme for the re-use of CEKs when the KEK and CEK algorithms must be different. The I-D defines a new attribute for this case. It also documents a new key derivation function with the property that it only requires the use of the CEK encryption algorithm. The function is documented in the rcek I-D, "Using different CEK and KEK algorithms" section. Blake Ramsdell recommended that Steve examine the Public Key Cryptography Standard (PKCS) #5 v2 key derivation function as an alternative to defining a new function.
Steve stated that the outstanding issues are how much to specify failure cases and the proposed key derivation scheme. He would like to do one more version and then submit it to WG last call. He recommended that this I-D be placed on the standards track.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Advanced Encryption Standard (AES) in CMS - Jim Schaad
Jim presented a briefing regarding the "Use of the Advanced Encryption Algorithm in CMS" I-D, <draft-ietf-smime-aes-alg-00.txt>, November 2000. The aes-alg I-D specifies how to incorporate AES into CMS as an additional algorithm for symmetric encryption. Jim briefed that the proposed AES parameters are as follows:
Block Size - Fixed at 16 bytes
Key Size - 128, 192 or 256 bits
Proposed MUSTs 128 and 256 bits
Jim noted that the aes-alg I-D does not include an AES key wrap algorithm. He proposes to include 256-bit key wrap algorithm as the only MUST-implement requirement. Paul Hoffman asked if Jim knew the difference in performance between using 256-bit versus 128-bit keys. Jim responded that the 256-bit key wrap takes a longer amount of time, but he didn't know the exact difference.
Regarding key management, the I-D specifies that compliant implementations MUST support key transport using the PKCS #1 v2.0 Optimal Asymmetric Encryption Padding (RSA with OAEP) technique. It also specifies that compliant implementations MAY support key agreement using Ephemeral-Static (E-S) Diffie-Hellman (D-H) with modifications. It also specifies that compliant implementations MAY support symmetric key-encryption key management.
Paul Hoffman commented that he believes that if the S/MIME WG specifies the use of both 128- and 256-bit keys, then customers will always demand 256-bit keys to achieve maximum security. He is concerned that the use of 256-bit keys will be a significant performance hit. For example, he believes that using 256-bit keys will drastically impact the performance of secure mail lists. He asked if the WG should consider only specifying the use of 128-bit keys.
Jim responded that the certificate processing required to obtain a recipient's valid public key far exceeds the performance difference between using 128- and 256-bit keys.
An attendee pointed out that companies couldn't sell 128-bit implementations because they have already been advertising the use of larger key sizes with Triple-DES.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RSA-OAEP and RSA-PSS - John Linn
John presented a briefing regarding the potential use of RSA-based encryption and signature algorithms in conjunction with CMS and S/MIME. He stated that many S/MIME products currently use the PKCS #1 v1.5 (RFC 2313) RSA algorithm that defines encryption and signature algorithms using ad hoc padding. PKCS #1 v1.5 RSA is specified as an optional algorithm in RFC 2630 (CMS). John described the PKCS #1 v1.5 padding formats and usage (his briefing slides provide details). He then described the Bleichenbacher adaptive chosen cipher text attack on PKCS #1 v1.5 encryption padding. The attack requires information from hundreds of thousands of decryptions, indicating whether correct padding resulted. A successful attack yields the result of a specific decryption. It does not yield the originator's private RSA key. Countermeasures include protocol-level means to ensure that information on decryptions is not available to attackers (constraints on returned information; randomize key, continue upon detected pad error) and improved, plaintext-aware padding (OAEP) in the cryptographic layer. More details are available in RSA Laboratories Bulletin #7 in <http://www.rsalabs.com/bulletins>.
PKCS #1 v2.0 (RFC 2437) defends against encryption padding attacks using OAEP in conjunction with the RSA algorithm. It can be used with CMS as described in the "Use of the RSAES-OAEP Key Transport Algorithm in CMS" I-D, <draft-ietf-smime-cms-rsaes-oaep-02.txt>. John stated that recent theoretical results on strengths and assumptions of OAEP proofs have been discussed in the cryptographic research community, and have reinforced the conclusion that the OAEP properties remain strong for use with RSA. He pointed out that OAEP offers attractive properties in a random oracle model. It is provably secure and provides a level of security that is directly related to the strength of the RSA function. He also highlighted the fact that OAEP is plaintext-aware. When OAEP is used, it is impossible to generate valid cipher text without knowing the plaintext; thereby, effectively guarding against chosen-cipher text attacks. He briefed the RSAES-OAEP steps (his briefing slides provide further details).
PKCS #1 v2.1 (draft, September 1999; 2nd draft in preparation) defends against potential signature attacks using the Probabilistic Signature Scheme (PSS). John noted that like OAEP, PSS offers a provably secure design. He briefed the proposed PSS encoding operation (his briefing slides provides further details).
John stated that he does not know of any patents regarding the use of OAEP technique as proposed for S/MIME. The PSS encoding method is patent pending by the University of California (UC). UC agreed to waive licensing on PSS for signatures with message recovery (PSS-R variant) if adopted in an IEEE standard.
John briefed that OAEP is stable and is being included in the PKCS #1v2.0, IEEE P1363 and ANSI X9.44 specifications. He stated that standardization of PSS is being pursued in several forums and will be included in the IEEE P1363a and PKCS #1 v2.1 specifications. He stated that there is intent in ANSI X9F1 to reopen X9.31 to incorporate PSS. There is a revision in progress to include PSS-R in ISO 9796-2.
John proposed that for the short term the S/MIME v3 documents should specify PKCS #1 v1.5 as a "MUST implement" requirement and PKCS #1 v2.0 RSA with OAEP as a "SHOULD implement" requirement. He recommended that the WG should specify RSA with OAEP as a "MUST implement" requirement for interactive CMS-based applications. John proposed that PSS signatures should be adopted as a long term solution along with the AES algorithm and new hash functions.
An attendee stated that multiple "MUST implement" requirements may be tough to support on constrained platforms such as smart cards or palm devices.
Jim Schaad pointed out that the format of the RSA public key is identical for PKCS #1 v1.5 and PKCS #1 v2.0 RSA with OAEP. He asked how an application was supposed to determine, based solely on the recipient's certificate, which algorithm to use as the key transport algorithm when encrypting data. This would be a problem if both algorithms are "MUST implement" requirements. Jim asked if RSA has considered defining a new object identifier to identify public keys for subjects that use PKCS #1 v2.0 RSA. Russ Housley replied that RSA decided to use the same object identifier to support both algorithms.
John Pawling pointed out that the SMIMECapabilities attribute could be used to identify an entity's preferred key management algorithm. Jim replied that many products are not capable of processing the SMIMECapabilities attribute. He also stated that an application may support multiple key management algorithms, so there is a question regarding which algorithms will be advertised in the SMIMECapabilities attribute. Russ Housley stated that applications should offer a menu that allows the user to select a combination of algorithms. He suggested that this topic should be discussed further on the S/MIME WG mail list.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RSA As a Must Implement - Blake Ramsdell
Blake proposed that RFC 2630 be changed to specify the PKCS #1 v1.5 RSA public key algorithm as the "MUST implement" key management and signature algorithm since the RSA patent has expired.
Blake stated that the majority of the July 2000 S/MIME WG meeting attendees stated their preference that both the PKCS #1 v1.5 RSA and DSA algorithms be the "MUST implement" signature algorithms. He stated that messages sent to the S/MIME WG mail list questioned if vendors would actually implement both algorithms if both were specified as "MUST implement". Others asked if there was a valid set of requirements justifying that both algorithms be specified as "MUST implement". Blake stated that PKCS #1 v1.5 RSA algorithm should be the "MUST implement" signature algorithm and that DSA should be the "MAY implement" signature algorithm. Blake said that PKCS #1 v2.0 RSA with OAEP should be discussed.
Paul Hoffman raised the issue of the definition of "MUST implement" requirements. He described three definitions that various folks support: 1) describe current usage; 2) force a specific future solution; and 3) provide optimal security solution. He recommended that those that are interested in this issue should conduct a sidebar meeting to write a position paper that would then be sent to the S/MIME WG mail list.
Russ Housley stated that the three definitions described by Paul point to different algorithm sets. He stated that he would talk to the security area director about this issue. He was surprised by the characterization of the arguments.
Russ stated that if PKCS #1 v1.5 RSA is approved as the "MUST implement" requirement, then the S/MIME WG must document the safeguards that should be taken.
Russ conducted a straw poll of the meeting attendees to obtain their opinion regarding the following options for the "MUST implement" signature algorithm:
1) PKCS#1 v1.5 RSA
2) DSA
3) Both
The meeting attendees were evenly divided between options 1 and 3.
Only one attendee voted for the "DSA" option.
Russ conducted a straw poll of the meeting attendees to obtain their opinion regarding the following options for the "MUST implement" key management algorithm:
1) PKCS#1 v1.5 RSA
2) PKCS#1 v2.0 RSA with OAEP
3) E-S D-H
The meeting attendees were evenly divided between options 1 and 2.
Only one attendee voted for the "E-S D-H" option.
Russ conducted a straw poll of the meeting attendees to obtain their opinion regarding the definition of the "MUST implement" requirement:
1) force a specific future solution
2) describe current usage
3) provide optimal security solution.
Not many attendees voted in this straw poll. Two attendees voted for option 1, four voted for option 2 and one voted for option 3.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Electronic Signature Formats - John Ross
John briefed regarding the "Electronic Signature Formats for long term electronic signatures" I-D. The esformats I-D is based on the European Telecommunications Standardization Institute (ETSI) Electronic Signature Infrastructure Standardization and defines a process to provide proof of the validity of a signature to be used if repudiation is attempted. The esformats-02.txt was based on ETSI ES 201 733. The new version, esformats-03.txt, is based on ETSI TS 101 733. All of the versions are based on RFC 2630. John stated that the changes in the esformats-03 I-D include extensions to the previous version including: verifier conformance options (Timestamping, Secure records); Signature policy options (Explicit by object identifier, Implied by signed content/signature environment); and Content encoding indication (Content hints).
John proposed that esformats-03 I-D is ready to become an Informational RFC. The planned work is: ETSI Implementation Trials; XML signature formats; and more work on signature policies.
John then briefed regarding the "Electronic Signature Policies" I-D, <draft-ietf-smime-espolicies-00.txt> that defines signature policies for electronic signatures. He proposed that the espolicies-00 I-D is ready to become an Experimental RFC.
Russ Housley proposed that the Electronic Signature Formats document is ready for S/MIME WG Last Call. The intent is for this document to be published as an Informational RFC. Russ proposed that the S/MIME WG Last Call should close on 10 January 2001. Nobody objected.
Russ Housley proposed that the Signature Policies document is ready for S/MIME WG Last Call. The intent is for this document to be published as an Experimental RFC. Russ proposed that the S/MIME WG
Last Call will close on 10 January 2001. Nobody objected.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
E-Signature Formats using XML - Denis Pinkas
Denis briefed that ETSI is defining new XML types to contain equivalent electronic signatures information to those ASN.1 types defined in the esformats I-D. These new XML types would include additions to the Signature XML element as defined by the W3C/IETF. He pointed out that there is not a one-to-one mapping from ASN.1to XML because some of the ASN.1 structures (such as the MessageDigest signed attribute) have been incorporated into the XML digital signature core syntax. Denis listed the new XML types defined (his briefing slides provide further details). He stated that new encapsulating XML type(s) need to contain ASN.1-encoded data generated by PKI agents such as time stamp agents that implement ASN.1 protocols. He discussed several proposals for accomplishing this goal.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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-05 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 is planning to deliver a new release of the SFL in January 2001 that will include improved PKCS #11 capabilities (tested with GemPlus, DataKey and Litronic PKCS #11 libraries). It will also include AES content encryption (as per aes-alg-00) and key wrap (128, 192, 256 bit keys; based on CMS Triple-DES key wrap algorithm). It will also include an Enhanced SNACC library that increases performance and decreases memory usage.
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 complies with the majority of the RFC 2459 requirements. Getronics is enhancing the CML to support the 2000 X.509 certificate policy processing requirements.
John also provided information regarding the Getronics-developed Access Control Library 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 from <http://www.GetronicsGov.com/>. 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 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.
Agenda
S/MIME Working Group Status
CMS-X.400 Drafts
'draft-ietf-smime-rcek-00'
On OAEP, PSS, and S/MIME
Mapping Company Classification Policy to the S/MIME Security Label
Domain Security Services Using S/MIME
S/MIME Freeware Library
ETSI Work on XML Electronic Signature Formats
Long Term Electronic Signature Formats
AES in CMS
S/MIME Symmetric Key Distribution
S/MIME Interop Matrix