Introductions - Russ Housley Russ reviewed the agenda as follows. Nobody objected to the agenda. Introductions Russ Housley RFC 2630 - 2634 Status Russ Housley Charter Revision Russ Housley Small Subgroup Attack Mike Just CERTDIST Draft Discussion Jim Schaad DOMSEC Draft Discussion Bill Ottaway CMS/ESS Examples Paul Hoffman Security Policies and Labels Weston Nicolls KEA and SKIPJACK Algorithms John Pawling CAST-128 Algorithm Carlisle Adams Elliptic Curve Algorithms Paul Lambert ETSI Electronic Signatures Denis Pinkas S/MIME Freeware Library John Pawling Wrap up Russ Housley +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ RFC 2630-2634 Status - Russ Housley Russ outlined the strategy for advancing the following RFCs from Internet Proposed Standards to Internet Draft Standards: RFC 2630 Cryptographic Message Syntax, R. Housley, June 1999 RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999 RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999 RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999 RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999 The aforementioned documents must meet the following requirements to become Draft Standards: 1) Meet requirements documented in RFC 2026 2) Stable, mature, and useful specification 3) At least two independent and interoperable implementations from different code bases Stable, Mature, and Useful: - Strong belief that the specification is mature and will be useful - Must be well-understood and known to be quite stable - semantics and basis for developing an implementation - may still require additional or more widespread field experience - Considered to be a final specification - changes are likely to be made only to solve specific problems - reasonable for vendors to deploy implementations Russ noted that no significant errors had been reported to the aforementioned RFCs. Implementations: - At least two independent and interoperable implementations from different code bases: - interoperable means to be functionally equivalent or interchangeable - applies to all of the options and features - Working Group chair responsible for documenting specific implementations and interoperability testing: - support of each of the individual options and features - submitted to Area Director with protocol action request Way Forward: - CMS and ESS Examples I-D providing informal inputs - Jim Schaad is developing matrices for RFCs 2630-2634 - Paul Hoffman has offered to coordinate interoperability testing Paul Hoffman stated that another requirement for a Proposed Standard to become a Draft Standard is that all normative references to other RFCs must refer to Draft Standards. RFC 2632 includes a normative reference to 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. Russ agreed with Paul's statement that a Draft Standard cannot include a normative reference to a document that has not achieved at least Draft Standard status. Russ agreed that since RFC 2632 relies on RFC 2459, then RFC 2459 will have to become a Draft Standard before or at the same time as RFC 2632. Paul pointed out that each requirement must be implemented by at least two independent code bases such that they are interoperable, but a single code base does not need to implement all of the requirements. Russ agreed that the entire set of requirements could be implemented by a variety of sources. The matrices being initiated by Jim Schaad will indicate which features have and have not been implemented. John Pawling asked if there were any plans to change the Attribute Certificate (AC) syntax used in RFC 2630. Currently, RFC 2630 imports the AC syntax from the 1997 X.509 Recommendation, but the draft IETF PKIX Attribute Certificate Profile Internet Draft specifies a different AC syntax. Russ pointed out that if RFC 2630 imported the AC syntax from the PKIX AC Profile, then RFC 2630 could not achieve Draft Standard status until the PKIX AC Profile achieved that status (which Russ believes will be at least six months). Russ stated that he believed that RFC 2630 should continue to import the AC syntax from the 1997 X.509 Recommendation because the other AC syntax is still not stable. He stated that the new features of the new AC syntax don't apply to RFC 2630. The new AC syntax allows for binding attributes to arbitrary objects identified by object identifiers. John pointed out that a new CMS specification could be drafted in the future which could include the new AC syntax once it is stable. Nobody disagreed with Russ' statement that the RFC 2630 AC syntax should not be changed. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Charter Revision - Russ Housley Russ stated that the following work items have been approved since the July S/MIME working group meeting: - Small Subgroup Attack Informational RFC - Additional Algorithm Support: - KEA, SKIPJACK Informational RFC - IDEA, CAST, and ECC Standards Track RFCs - CMS and ESS Examples Informational RFC - CERTDIST Standards Track RFC - Password-based Key Management RecipientInfo Extension Standards Track RFC - Mail List Key Distribution Standards Track RFC - Security Label Usage Informational RFC - DOMSEC Experimental RFC Russ stated that there is another proposed addition: CMS Compressed Proposed Standard RFC. Compression improves security by removing known data patterns, improves throughput by reducing the amount of data which needs to be encrypted or hashed, and reduces the overall message size. Enabling S/MIME version 3 to use compression will provide all of these advantages. The proposed schedule is as follows: Oct 1999 - First Compression I-D. Jan 2000 - Compression Last Call. Apr 2000 - Compression Proposed Standard RFC. Russ stated that both IETF Security Area Directors have expressed support for this addition. Russ asked if any attendees knew of any issues, had comments or wshed to discuss any related topics, and no one raised anything. Russ asked if there were any patent concerns, and no one raised any patent concerns. Paul Hoffman stated that the previous IP Compression working group had already worked on a compression standard and that the previous MIME working group had purposely avoided the issue of compression. Russ asked if the meeting attendees approved the addition of compression. The majority approved. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Small Subgroup Attack - Mike Just Mike stated that there had not been a new draft of the "Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME" I-D since the last meeting. One minor comment was received regarding wordsmithing. Russ asked if the attendees believed that the I-D was ready for working group last call. Nobody objected, so Russ asked that the aforementioned comment be incorporated into a new I-D and then that I-D would be submitted for last call. Russ asked that people please carefully review the I-D. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CERTDIST Draft Discussion - Jim Schaad Jim discussed the Certificate Distribution Specification I-D (CERTDIST-04), October 20, 1999. He stated that "directory people" had criticized CERTDIST, but had not proposed an alternate solution. Russ noted that the directory folks were complaining because certificates are stored in the directory twice within different attributes. He said that they are concerned that the certificates stored within the two attributes will be different. He also said that they proposed that SupportedAlgorithms could be used. Jim pointed out that the SMIMECapabilities signed attribute could be used to point to a certificate rather than storing the entire certificate. Jim also stated that the method proposed in CERTDIST allows each certificate to claim different algorithm preferences. Carlisle Adams asked if the SMIMECapabilities signed attribute is supposed to be tied to a specific certificate. Jim answered that SMIMECapabilities must be tied to a specific key management certificate. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ DOMSEC Draft Discussion - Bill Ottaway Bill presented a briefing regarding the Domain Security Services Using S/MIME I-D (DOMSEC-03). Bill provided an overview of the DOMSEC concepts and the new features. The new features included: Naming conventions for signing and encryption, and the creation of a NULL signature when there is no originator signature present. Bill's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes the details regarding the issues and proposed solution for each new feature. Bill's goal is that DOMSEC should achieve RFC status in 2000. He would like DOMSEC to describe a solution that will work for a wide variety of organizations. He has received significant feedback from Baltimore, but would like to hear feedback from others. Jim Schaad recommended that the domain name should be exactly matched. Jim also pointed out that RFC 2630 states that the content type should be id-data when there are no signers of a signedData object. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CMS/ESS Examples - Paul Hoffman Paul stated that there has been much progress with the "Examples of S/MIME Messages" I-D and that almost all of the examples have been provided for incorporation into the document. He stated that there needs to be more testers of the sample data. He asked that folks please publicize their progress with verifying the sample data. Paul asked if there was any interest in a PKIX Examples Document. There was not much interest shown by the attendees. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Security Policies and Labels - Weston Nicolls Weston stated that he is developing an I-D that will document the security policies of Whirlpool, Caterpillar and Amoco. The draft will describe how the ESSSecurityLabel can be used to implement those corporate security policies. It is planned that the document will be an Informational RFC. Weston stated that he has been provided with classification policies for: - Amoco Corporation: o General, Confidential, Highly Confidential o Minimum, Medium, Maximum Integrity - Caterpillar Inc o Public, Confidential Green, Confidential Yellow, Confidential Red - Whirlpool Corporation o Public, Internal, Confidential o Privacy Labels o Security Categories? Jim Schaad pointed out that an example security policy is needed to populate sample ESSSecurityLabel attributes to be included in the "Examples of S/MIME Messages" I-D. The implication of Jim's statement is that one of the security policies described in Weston's document could be used to populate sample ESSSecurityLabel attributes to be included in the "Examples of S/MIME Messages" I-D. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ KEA and SKIPJACK Algorithms - John Pawling John presented the CMS KEA and SKIPJACK Conventions I-D (CMSKEA-02), 29 July 1999. The goal of CMSKEA is to promote interoperability between implementations using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithms with the RFC 2630 enveloped-data and encrypted-data content types. CMSKEA describes a profile for using SKIPJACK and KEA with CMS. It describes modes, key lengths, object identifiers and parameter formats associated with the use of SKIPJACK and KEA with CMS. J.G. Van Dyke and Associates (VDA) has used the S/MIME Freeware Library with the Fortezza Cryptologic Interface (CI) Library and Fortezza Card to successfully perform interoperability testing with Microsoft. This testing verifies the correctness of the CMSKEA I-D. The "FORTEZZA Card\CI Library Usage With CMS KEA SKIPJACK I-D" text file (available from http://www.jgvandyke.com/services/infosec/sfl.htm) contains hints for using the FORTEZZA Card and FORTEZZA CI Library to meet the CMSKEA requirements. Russ pointed out that CMSKEA is planned to be an Informational RFC. He stated that he would like to issue the working group last call for CMSKEA. Nobody objected. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CAST-128 Algorithm for S/MIME - Carlisle Adams Carlisle discussed the "Use of the CAST-128 Encryption Algorithm in S/MIME" I-D, September 1999 (cast-128-00). He stated that this is a short, simple specification. It documents how to use CAST-128 as a content encryption algorithm and a key encryption algorithm. The relevant algorithm object identifiers and parameters are specified. Carlisle stated that there are patents issued and pending regarding the CAST design procedure, but CAST-128 (described in RFC 2144) may be used by anyone for any purpose without paying any royalties or obtaining any licenses as stated in www.ietf.org/ipr.html. He stated that there is no encumbrance in using CAST-128. The same is true for CAST-256 (RFC 2612). Russ pointed out that the CAST-128 document is planned to be on Standards Track. He stated that he would like to issue the working group last call for the document as soon as possible. Nobody objected. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Elliptic Curve Algorithms - Paul Lambert Paul briefed the "Elliptic Curve S/MIME" I-D, October 1999 (ECC-00). He stated that the EC algorithms support digital signatures and key management. EC Diffie-Hellman (D-H) is based on ANSI X9.63 and EC Digital Signature Algorithm is based on ANSI X9.62. Paul stated that there is one issue. The I-D includes two recommendations for ECDH: one-pass D-H and cofactor D-H. Paul recommends that the S/MIME working group pick one or the other, but not both. Paul's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the EC S/MIME I-D. Paul Hoffmann stated his concerns about the patent issues regarding the EC algorithms. He stated that the IPR for the EC algorithms is insufficient for the WG to decide what to do. Paul Lambert stated that Certicom has patents and patent applications that may cover the specification and will include a pointer to the IPR statement in the EC S/MIME I-D. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ETSI Electronic Signatures - Denis Pinkas Denis briefed the "European Electronic Signature Standardisation Initiative". He stated that the European Community plans to vote on the EESSI directive. The directive will cover anything in digital form that can prove the identity of the signer. The goal is to specify technology and standards that are equivalent to a manual signature. The ETSI definition provides "Evidence in a digital form than can be processed to get confidence that some commitment has been explicitly endorsed under a signature policy, at a given time, by a signer under an identifier, e.g. a name or a pseudonym, and optionally a role." The ETSI draft Standard builds upon RFC 2630 and RFC 2634. It defines new signed and unsigned attributes. The Electronic Signature uses signed attributes defined in RFC 2630, RFC 2634 and the draft ETSI standard including: - signature policy ID (reference and hash) (new), - commitment type (new), - content Type [RFC 2630], - signer's physical location (new), - signing time [RFC 2630], - signing certificate reference [RFC 2634], - role attribute (claimed or certified) (new). Denis also briefed regarding the role of time stamping in the EESSI. His briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the EESSI. An attendee asked how the verifier can prove the signer's physical location. Denis said that the EESSI specification replicates the services provided by the paper hard copy which is no authentication of the signer's location value. Phillip Hallam-Baker stated that the requirement for the signer to state her location is bogus and is not required in the United Kingdom. An attendee stated that a 760-bit signing key could be compromised in 20 years, so the time stamp signature could be compromised too. Denis said that an authority can re-sign the time stamps with a longer length key or could apply two stamps. Chris Bonatti asked if the signature policy is selected by the signer, what guarantee is there that the verifier will recognize the signature policy. Denis said that the verifier will look for specific values. An attendee asked whether there will be a signature policy distribution point from which people could obtain defined policies. Denis said that service might be provided by the International Chamber of Commerce. An attendee asked if XML would be more useful to describe the signature policy than ASN.1. Denis said that ASN.1 will be used for now, but XML may be used in the future. Phillip Hallam-Baker stated that XML is better for future use. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ S/MIME Freeware Library (SFL) - John Pawling John provided an update briefing regarding the SFL which is a freeware implementation of RFC 2630 and RFC 2634. It uses the Crypto++ freeware library to implement RFC 2631. It provides functions to support use of RFC 2632 and RFC 2633. The goal of the SFL is to provide a reference implementation of RFC 2630 and RFC 2634 to encourage their acceptance as Internet Standards. VDA is developing the SFL. The SFL implements the optional RFC 2634 security services such as signed receipts, security labels, mail list information, signing certificate attribute and equivalent security labels. It has been used with the RSA BSAFE v4.2, Crypto++ v3.1, Fortezza CI and SPYRUS SPEX/ libraries. VDA is now developing the capability for the SFL to use any security library that provides a PKCS #11 interface. Version 1.3 of the SFL was released in October 1999. It was tested on MS Windows 95/NT and Sun Solaris 2.6. It was tested using the mandatory and RSA algorithm suites. VDA continues to enhance the SFL. Organizations can use the SFL as part of their applications without paying any royalties or licensing fees (see SFL Public License). All source code is provided. The VDA-enhanced SNACC ASN.1 software is freely available 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). John also provided information regarding the Certificate Management Library (CML) that is a freeware implementation of X.509 version 3 certification path verification as specified in the 1997 X.509 Recommendation (except Delta CRLs are not implemented). The CML: validates X.509 certification paths and CRLs; provides local certificate/CRL storage functions; and provides remote directory retrieval via LDAP. The CML uses the Certificate Path Development Library (CPDL) developed by Cygnacom Solutions to robustly build certification paths including cross certificates. The CML complies with the majority of the RFC 2459 requirements. Organizations can use the CML as part of their applications without paying any royalties or licensing fees (see CML Public License). All CML source code is provided. CML is available at: http://www.armadillo.huntsville.al.us/software. John's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the SFL and CML. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Wrap Up - Russ Housley Russ discussed the work item proposing the use of password-based key management for file encryption. This is documented in the "Password-based Encryption for S/MIME" I-D. The proposal uses PKCS #5 techniques. Russ stated that the working group needs to decide if that proposal will be accepted. He encouraged people to read the document and provide comments. Bob Jueneman stated his concern with the processing of name forms. Bob is concerned that not all applications display all address spec texts. He stated that they may omit, abbreviate or truncate the address spec text. He believes that this should be a joint work item between the PKIX and S/MIME working groups. He stated that properly supporting the address spec requirements is important. He recommends that we allow the use of a personal name form that precedes the address spec. For example, a husband and wife may share an e-mail address, but use different certificates. Paul Hoffman stated that RFC 822 includes a third option that allows comments to be included in parentheses. The third option must be included in any solution. He agreed that this issue needs to be resolved. Bob Jueneman also stated his concern regarding using the same object identifier to indicate two-key triple-DES and three-key triple-DES. He believes that separate object identifiers must be used for export control reasons. Two-key triple-DES may be exportable, but 3-key triple-DES may not be exportable. He said that 168-bit keys (112 effective) need a separate object identifier. Paul Hoffman stated that his understanding is that two-key is 80-bit and three-key is 112 bit (effective). He does not believe that the object identifier should be changed. Russ asked if it would be acceptable to examine the contents of the key to determine if the first and third keys are the same. Bob said that he has to enforce that they are the same. Russ said that it seems to be a receive-side issue, since the send-side controls the formation of the keys. Russ asked if the receive side could examine the keys and stop processing if the first and third keys are different. Paul Hoffman noted the creation of the S/MIME developers mail list for discussing implementation of S/MIME. The new list is a good place to send sample S/MIME messages for interoperability testing. The list is called imc-smime-dev@imc.org. To subscribe, send a message to imc-smime-dev-request@imc.org with the single word "subscribe" in the body of the message. Russ noted that members of the S/MIME mail list don't necessarily need to use S/MIME-enabled e-mail products. Meeting adjourned.