Minutes for the IETF S/MIME Working Group meeting held on 10 December 1997 in Washington, D.C. Over one hundred people attended the meeting. ++++++++++++++++++++++++++++++++++++++++++++++++ Introductions - Russ Housley Russ reviewed the agenda. Nobody objected to the agenda. He then reviewed the list of the S/MIME WG Internet Drafts (I-D): Latest Revision I-D Title --------- ------------------------------------------ Nov 97 Cryptographic Message Syntax (CMS) 18 Nov 97 Enhanced Security Services (ESS) for S/MIME 20 Nov 97 S/MIME Version 3 Message Specification (MSG3) Nov 97 S/MIME Version 3 Certificate Handling (CERT3) ++++++++++++++++++++++++++++++++++++++++++++++++ CMS Draft Discussion - Russ Housley Russ presented several briefing slides regarding the history of and future plans for the CMS I-D. The slides and related discussion are included in the following text. Slides: History CMS 00 included: Algorithm Independence: No longer depends on RSA algorithms. Backwards compatible with PKCS #7 v1.5 when RSA algorithms used. Includes SignedData and EnvelopedData CMS 01 included: Fixed errors in CMS 00. Included placeholder for ASN.1 module. Future Plans CMS 02 proposed changes: 1) Fixes errors in CMS 01. 2) Forces originator to provide an encrypted content encryption key for himself. 3) Includes ASN.1 module. 4) Includes digestedData and encryptedData 5) Includes PKCS #9 attributes 6) Includes placeholder for algorithm specifications Beyond CMS 02 AuthenticatedData object (facilitates Message Authentication Codes) Discussion: CMS 02 Proposal 2: Russ explained that the inclusion of a copy of the content encryption key encrypted for the originator in an envelopedData object will ensure that the originator can decrypt the envelopedData object if it is returned for non-delivery. Several WG members objected to the "mandatory" nature of the proposal. A comment was made that there will be one more copy of the content encryption key that can be attacked. Another comment was that it takes additional processing resources to encrypt the key for the originator. Another comment was that there are customers who require that encrypted data must not be able to be decrypted by the originator. Another point was made that other protocols that use CMS might not have the property that the originator could get a "bounced" message. S-HTTP is one example where the originator does not need to have a copy of the content encryption key encrypted for the originator. Jeff Schiller stated that the "MUST implement" requirement means that the implementer must implement the feature, not that the feature must be present in every message. Jeff said that a vendor must implement the "MUST" requirements to claim conformance to the specification, but that the customer can choose not to populate the field. Steve Kent made similar statements. The consensus of the WG was that the requirement must not be included in the CMS I-D, but that it must be included in the MSG3 I-D as a SHOULD requirement. Blake Ramsdell took the action to add the requirement to MSG3. CMS 02 Proposal 3: Russ proposed that the CMS ASN.1 module should use the 1988 ASN.1 syntax definitions with a few added enhancements (such as BMPString, etc). He stated that he would prefer not to include two modules (one using 1988 rules and another using 1994 rules) in CMS. He stated that he had drafted a CMS module and that it had been successfully parsed using three different ASN.1 compilers. Russ asked if the WG preferred 1988 or 1994 ASN.1 syntax definitions. The silence was deafening. Because the 1994 proponents seemed to be absent, Paul Hoffman stood up for them and stated that their concern (based on message traffic on the S/MIME WG mail list) was that using the 1988 syntax rules with enhancements did not constitute valid ASN.1 definitions. Another WG member stated that the 1994 syntax rules include the "table" format which tightly binds OIDs with ASN.1 definitions (in contrast to 1988 OID/ANY pairs) that an ASN.1 compiler can process in one pass and can check for correctness. Eric Rescorla said that the "table" format is not always a positive feature because there are cases in which the ASN.1 decoding software can decode the object to the point of the OID/ANY pair, but that other modules of the software can decode the ANY based on the value of the OID. The consensus was that the CMS ASN.1 module will use the 1988 ASN.1 syntax definitions with a few enhancements. CMS 02 Proposal 4: Russ stated that CMS 02 will include definitions for the digestedData and encryptedData objects, but that those objects are not intended for use with S/MIME applications. The MSG3 I-D will not include support for digestedData and encryptedData. They are being added to CMS to support requirements stated by the S-HTTP proponents. The S-HTTP specification needs to point to the CMS I-D because it includes IETF-acceptable "MUST implement" algorithms. Nobody objected to the proposal. CMS 02 Proposal 5: Russ stated that CMS 02 will include definitions of the PKCS #9 attributes, so that CMS does not have to refer to the RSA PKCS #9 specification. Nobody objected to the proposal. CMS 02 Proposal 6: The WG agreed that the "MUST implement" algorithms are SHA-1, DSA, Diffie-Hellman (D-H) and 3DES as specified in MSG3. The D-H will be one of the x9.42 variants. The 3DES will use three independent keys and CBC mode. Russ stated that CMS 02 will include placeholders for the algorithm specifications that will include details regarding the use of the "MUST implement" cryptographic algorithms with CMS. After a brief debate regarding which I-D should include the "MUST implement" cryptographic algorithms, it was agreed that the CMS I-D will specify the "MUST implement" algorithms and that the MSG3 I-D will refer to the CMS I-D for the specification of the "MUST implement" algorithms. ++++++++++++++++++++++++++++++++++++++++++++++++ MSG3 Draft Discussion - Blake Ramsdell Blake stated that MSG3 is based on the S/MIME Version 2 Message Specification. It has been updated to support "MUST implement" algorithms of SHA-1, DSA, D-H and 3DES. It also includes the RSA algorithms as "SHOULD implement" algorithms. [Note that MSG3 will be modified to refer to the CMS I-D for the specification of the "MUST implement" algorithms.] Blake stated that the text regarding the Certificate Request message format and certificate generation issues will be moved to CERT3. Dave Solo asked which I-D will include text regarding the use of separate digital signature (DS) and key management (KM) keys. Blake answered that CERT3 will include that text. Paul Hoffman stated that the security section should include text encouraging the use of separate DS and KM keys. Jim Schaad stated that the attribute identifying which of a user's certificates should be used for DS and KM should be included. The attribute will be defined as a CHOICE between IssuerandSerialNumber and subjectKeyIdentifier. Blake agreed that the attribute will be included in MSG3. Jim Schaad stated that MSG3, Section 3.1 should be changed to remove the requirement that the RFC822 "from-field" must be identical to the signer's RFC822 address included in the signer's X.509 certificate. Blake agreed. Eric Rescorla stated that the recipient should be informed if there is a difference. A WG member asked what requirement, if any, is there for an RFC822 name in a KM X.509 certificate. Steve Kent made the point that users may wish to send messages from multiple mailboxes using the same X.509 certificate. Steve went on to say that the receiving agent could display the "from-field" in the normal in-box, but that the signer could be identified in a security-related window. Another WG member stated that the WG should not dictate what the application displays. The WG agreed with this concept. Paul Hoffman terminated the debate by asking that interested parties send a message to the S/MIME WG mail list proposing specific changes to MSG3, Section 3.1. ++++++++++++++++++++++++++++++++++++++++++++++++ CERT3 Draft Discussion - Blake Ramsdell Blake stated that CERT3 refers to the PKIX X.509 Certificate and CRL Profile (PKIX I). CERT3 states that certificate extensions should be used as stated in PKIX I. CERT3 states that certificates should be allowed to include RFC822 addresses. Unless anybody complains, CERT3 will use the certificate chaining strategy described in PKIX I. PKIX I allows NULL issuer and subject DNs, so the issuerAltName and subjectAltName extensions can be used for chaining. Nobody objected to the concepts presented by Blake. ++++++++++++++++++++++++++++++++++++++++++++++++ ESS Draft Discussion - Paul Hoffman Paul stated that ESS describes features not included in the S/MIME v2 documents. He stated that some of the additional security features described in ESS can be used in conjunction with S/MIME v2 messages in addition to S/MIME v3 messages. He stated that the addition of ESS features to CMS enables an implementation to meet U.S. Department of Defense (DOD) requirements. He described the additional features as follows: Signed Receipts: Paul stated that when an originator of a SignedData object verifies the signature of an ESS Signed Receipt returned by the recipient of the SignedData object, then the Signed Receipt verification provides proof to the originator that the recipient received and was able to verify the signature of the SignedData object (content and authenticated attributes). Paul stated that ESS Signed Receipts are not intended to provide any other services. There have been suggestions discussed on the IETF S/MIME mail list that additional services should be provided by ESS Signed Receipts. Paul stated that there are IETF WGs dedicated to calendaring/scheduling (calsch) and electronic commerce interchange (ediint) that are working on similar services, so he does not recommend that those services should be provided by the ESS Signed Receipt. Nobody objected to this concept. Security Label: Identifies the sensitivity of the encapsulated content. In addition to meeting US DOD requirements, commercial industry needs this capability also. For example, the health care industry needs to label personal medical data. Nobody objected to this concept. Mail List Expansion History: Provides information in the CMS header to warn ML agents of looping conditions. A WG member asked if the ML information increased the risk of traffic analysis. Paul said yes, but that the benefit gained far outweighed the risk incurred. Nobody objected to the ML concepts included in ESS. A WG member stated that timestamping should be included in ESS. Another WG member stated that the IETF must design a standard for digital timestamps. It was also stated that there would probably be more than one timestamping service proposed and the S/MIME WG will need to choose the one best suited for S/MIME. Once the IETF proposals are stable, then the S/MIME WG can make that decision. Everybody agreed with this plan. ++++++++++++++++++++++++++++++++++++++++++++++++ CRS Draft Discussion - Mike Myers Background: One of the biggest issues facing the PKIX and S/MIME WGs was the debate of whether the PKCS 10-based CRS or the PKIX Certificate Management Protocol (CMP) would be endorsed by IETF as the standard Internet protocol. The two proposed specifications contained redundant ASN.1 syntaxes for Certificate Request and other formats. Prior to the IETF meetings, there was a proposal to move the CRS work into the S/MIME WG. At the 8 December 97 IETF PKIX WG, it was decided that the CRS work belonged in the PKIX WG rather than the S/MIME WG because the Certificate Request format is not an S/MIME-specific issue, it is a general PKI issue. The ideal situation would be to have a common Certificate Request format (and other related certificate management formats) that can be communicated via various mechanisms (including S/MIME and others). Mike presented a series of briefing slides regarding the history of CRS. The slides and related discussion are included in the following text. Slides: TIMELINE: - Dec 96: Initial comment on Part 3 - Floor call showed strong support for 7, 10 reuse - Action predicated on PKCS movement into IETF - April 97: Further group discussion in Memphis - still no constructive movement re: PKCS. - August 97: Draft put forward in Munich - In anticipation of PKCS 7, 10 movement. - A "supplement" to CMP - Dec 97: S/MIME now into IETF. - 7 &10 Information drafts, CMS proposed standard CURRENT STATUS OF DRAFT - Algorithm Independence - Optional transaction ID, nonces - Protocol version - Separate Signature and Encryption keys - Optional encryption, two enveloping methods: - Outer signed, inner encrypted - Outer encrypted, inner signed - Added revocation request, response - Other minor edits PLAN: - Standardize that which can be standardized - Integrate current comments - Active review and comment in Jan 98 - Final Draft in Feb 98 - Last Call by next IETF Discussion: Mike stated that the CRS and CMP authors and other interested parties had developed a compromise solution referred to as the "harmonized" Certificate Request format (which has not yet been publicized). The end result of the IETF meetings is that the PKIX WG will publish a separate RFC that includes the "harmonized" Certificate Request and other related protocols. The CMP and CRS I-Ds will be changed to replace their redundant protocols with pointers to the "harmonized" protocols. The CRS I-D will define the use of CMS for protecting the "harmonized" Certificate Request (and other related certificate management protocols). The CERT3 I-D will define how the CRS objects are communicated using MIME. The WG concluded that CERT3 should point to the CRS I-D which will point to the "harmonized" protocol RFC. Other WGs will define how the "harmonized" protocols will be communicated via other mechanisms. ++++++++++++++++++++++++++++++++++++++++++++++++++ Add CRS to Charter? - Russ Housley Russ proposed that the S/MIME WG should concur with the PKIX WG decision that the CRS work should stay in the PKIX WG. In other words, the S/MIME WG should not define a Certificate Request format. The S/MIME WG agreed with Russ' proposal. ++++++++++++++++++++++++++++++++++++++++++++++++++ Interoperability Discussion - Tim Dean Secure Interoperability Discussion - Tim Dean Tim presented a series of briefing slides that are available from http://sostdp.mod.uk/demo1a.html#pct. Tim asked for the S/MIME WG's opinion regarding a proposal to define a strategy for making Message Security Protocol-protected X.400 applications interoperable with S/MIME applications including preserving the originator's signature of the content. Several WG members stated that heterogeneous e-mail is a message format problem, not a security problem. Paul Hoffman stated that there is another IETF WG, MIXER, that is working on X.400-MIME interoperability that may want to deal with the issues raised by Tim, but that these issues should not be debated by the S/MIME WG. However, Jim Craigie pointed out that allowing CMS to carry any kind of data object rather than just MIME entities would be a significant enhancement to the protocol. This would not only make secure interoperability much easier, but also allow direct signing of various objects such as word processor files etc. Russ Housley agreed that it was the intent to allow CMS to be pointed at by other documents for such purposes. Jeff Schiller agreed. Tim asked that any comments be sent to him at t.dean@eris.dera.gov.uk. ++++++++++++++++++++++++++++++++++++++++++++++++++ Signed Receipt Hashing - John Pawling John presented a proposal for enhancing ESS, Section 2.4, Signed Receipt Creation, so that the chain of digests leading to the signedData/Receipt signature value includes digesting the authenticatedAttributes of the original signedData signerInfo requesting the signedData/Receipt and includes digesting the authenticatedAttributes of the signedData/Receipt signerInfo. This will allow the originator of the original signedData object requesting the signedData/Receipt to verify that the recipient received and was able to verify the signature of the original signedData object including the content and authenticatedAttributes. This will also allow the originator of the original signedData object to verify the integrity and authenticity of the authenticatedAttributes of the signerInfo containing the signedData/Receipt signature value. The meeting attendees agreed with this proposal with one minor enhancement recommended by Jim Schaad. A separate message will be sent to the S/MIME WG mail list proposing the exact text for inclusion in ESS, Section 2.4. ++++++++++++++++++++++++++++++++++++++++++++++++++ These minutes were written and edited by John Pawling from J.G. Van Dyke & Associates, Inc. (jsp@jgvandyke.com). The chairman and other working group members greatly appreciate John's efforts.