Minutes of the IETF S/MIME Working Group meeting held on 26 August 1998 in Chicago, IL, USA. These minutes were coordinated with the S/MIME WG mail list members. All briefing slides are stored at: ftp://ftp.ietf.org/ietf/smime/. Introductions - Russ Housley Russ reviewed the agenda. Nobody objected to the agenda. MSG Draft Discussion - Blake Ramsdell Blake stated that the 6 Aug 98 S/MIME v3 Message Specification (MSG) Internet Draft (I-D) includes the comments submitted to the S/MIME WG mail list. He stated that the application/MIME text was deleted from MSG and the X.509 references were changed to PKIX references. When asked if there were any other comments to the MSG I-D, the room was silent. When asked how many people had read the MSG I-D, not many in the room raised their hands. Blake stated that the MSG I-D has been submitted for last call within the S/MIME WG and that there are no other changes planned for the MSG I-D. CERT Draft Discussion - Blake Ramsdell Blake stated that the 6 Aug 98 S/MIME v3 Certificate Handling (CERT) I-D includes the comments submitted to the S/MIME WG mail list. He stated that the CERT I-D has been submitted for last call within the S/MIME WG. When asked how many people had read the CERT I-D, not many in the room raised their hands. Blake stated that the X.509 references were changed to PKIX references. There was a comment from an attendee that Section 3.2 "Required Name Attributes" should be deleted because it is redundant to the PKIX X.509 Certificate and CRL Profile (PKIX Part I). Nobody objected to this change. There was a comment from an attendee who was concerned that certificates included in S/MIME messages may divulge sensitive information. The consensus of the attendees was that this is a matter to be solved by the policy of the local organization of the user who is releasing the S/MIME message. The group decided that no change is required in the S/MIME I-Ds regarding this issue. ESS Draft Discussion - Paul Hoffman Paul stated that the 5 Aug 98 Enhanced Security Services for SMIME (ESS) I-D has been submitted for last call within the S/MIME WG. When asked how many people had read the ESS I-D, not many in the room raised their hands. Paul stated that the EntityIdentifier syntax needs to be added to the ESS I-D ASN.1 module as noted on the S/MIME WG mail list. He stated that the S/MIME ASN.1 modules need to be compiled by various ASN.1 toolkits to determine if there are any other discrepancies. Van Dyke and Associates (VDA) volunteered to compile the ESS and CMS I-D ASN.1 modules using the SNACC ASN.1 compiler, but others were urged to check the ASN.1 with their own compilers as well. CMS Draft Discussion - Russ Housley Russ presented briefing slides (see ftp://ftp.ietf.org/ietf/smime/) regarding the open issues related to the June 98 Cryptographic Message Syntax (CMS) I-D. Russ stated that the ESS, CERT and MSG I-Ds are dependent on the CMS I-D; therefore, those I-Ds will not complete WG Last Call until the CMS I-D completes WG Last Call. When CMS enters WG Last Call, then all of the I-Ds will be final after the two-week last call period is complete. In summary, the WG last call period will simultaneously close for the CMS, ESS, CERT and MSG I-Ds. Slide #1: CMS Document Status: All CMS sections are complete except for Section 12 that will document the mandatory algorithms and some optional algorithms. The comments received on the mail list have been incorporated into a CMS draft that has not yet been released to the WG. A draft of Section 12 was discussed on the mail list. The most recent draft is included in the 22 July message, subject: "CMS Section 12, take 3". The completion of Section 12 depends on the Diffie-Hellman (D-H) Key Agreement Method I-D . Slide #2: Message Digest Algorithms: SHA-1 is mandatory to implement. The AlgorithmIdentifier syntax includes an optional parameters field. There was some debate regarding whether the parameters field should be absent or set to an ASN.1 NULL (05 00 hex) when the SHA-1 OID is populated in the AlgorithmIdentifier syntax. Eric Rescorla and Blake pointed out that current implementations encode the field as an ASN.1 NULL. The attendees decided that the CMS I-D will state that the parameters must be encoded as an ASN.1 NULL, but that CMS implementations should be able to accept either an ASN.1 NULL or absent parameters. This is required for compatibility with S/MIME v2. MD5 is optional to implement. The attendees decided that the CMS I-D will state that the parameters must be encoded as an ASN.1 NULL when the MD5 OID is populated in the AlgorithmIdentifier syntax. This is required for compatibility with S/MIME v2. Slide #3: Signature Algorithms: DSA-with-SHA1 is mandatory to implement. The attendees decided that the CMS I-D will state that the parameters must be absent (not ASN.1 NULL). This is required for consistency with PKIX Part I. RSA-with-SHA1 and RSA-with-MD5 are optional to implement. With both of these combinations, the rsaEncryption OID must be used in the signedData signerInfo signatureAlgorithm. The digesting algorithm is indicated in the signedData signerInfo digestAlgorithm. The attendees decided that the CMS I-D will state that the parameters must be encoded as an ASN.1 NULL when the rsaEncryption OID is populated in the AlgorithmIdentifier syntax. This is required for compatibility with S/MIME v2. Slide #4: Key Management (KM) Algorithms: The group discussed which KM algorithms and key encryption algorithms should be documented in CMS. The attendees decided that the most important algorithms to cover are the mandatory-to-implement algorithms. The attendees agreed that optional algorithms not already covered in CMS can be documented in separate I-Ds. The proposed Section 12 text states that static D-H (as specified in the D-H I-D) will be mandatory to implement. CMS will document how static D-H can be used to generate a key-encryption key (KEK) for use with Triple DES. It will also document how static D-H can be used to generate a KEK for use with RC2. When obtaining the bits of the KEK, the minimal number of bits needed to form the KEK must be used (a.k.a. key reduction). There is an open issue regarding how the minimal number of bits is obtained for RC2. The group decided that this issue will be debated on the list. The group decided that CMS should not discuss the use of D-H to generate keys for DES. The group decided that CMS should specify that at least 512 modulus should be used. An attendee asked about key recovery. Russ stated that this issue has been thoroughly discussed on the mail list and that discussion identified at least three ways to implement key recovery without specifying a specific strategy in CMS. Slide #5: Key Management (KM) Algorithms 2: Mail List Key (MLK) encryption is optional to implement. CMS will discuss the use of Triple-DES and RC2 to be used for MLK purposes. Slide #6: Key Wrapping Algorithm: CMS will document a single mandatory-to-implement key wrapping strategy to be used with key agreement and MLK (but not key transport). Jim Schaad asked if an OID should be defined to identify the wrapping algorithm. Russ answered that the X9.42 D-H OID used in conjunction with CMS implies the wrapping algorithm. John Pawling pointed out that Sec 12.4, 3rd paragraph states: "Triple-DES may be an exception here; the same identifier is used for both 2-key and 3-key Triple DES. This is probably easily handled by always wrapping three keys, even if the first and third keys match." John stated that these issues need to be resolved to avoid interoperability problems. Slide #7: Content Encryption Algorithms: Triple-DES in CBC mode is the mandatory-to-implement algorithm. The DES-EDE3- CBC OID will be used. The group decided that DES will not be documented in CMS. Slide #8: Content Encryption Algorithms 2: The group decided that CMS will document RC2 in CBC mode as a "should" to implement (rather than "may"). The RC2-CBC OID will be used. Slide #9: Message Authentication Code (MAC) Algorithms: The group decided by a clear majority that HMAC-with-SHA1 will be the mandatory-to-implement algorithm. The wording in CMS will be: "If authenticatedData is implemented, then HMAC-with-SHA1 must be implemented." The group also decided that DES MAC will not be included in CMS as an optional algorithm. Slide #10: Way Forward: When Section 12 is completed, then CMS will be ready for last call. Russ asked if there were any other issues. 1) Denis Pinkas asked if there was a way to verify the "correctness" of a CMS message. Dennis considers signature generation time to be a critical factor in determining whether or not that signature is valid. If the signing key is revoked, then the signing time would indicate if the message signed before or after the revocation date. John Pawling pointed out that the MSG I-D already states that the signingTime attribute should always be included in signed messages. Denis said that he would send a message to the S/MIME WG mail list regarding this topic as a stimulus for further debate. 2) Denis also was concerned that the serial number in the signer's cert is not covered by the signedData signerInfo signature, so a different cert could be substituted for the signer's cert. Russ stated that the SIGATTR I-D addresses this issue. 3) Doug Maughn asked about the processing requirements for generating a countersignature. It was proposed on the list that the generator of a countersignature must validate the original signature before generating the countersignature. Russ has included that proposal in the CMS draft that he has not yet published. He stated that "validate" means verify the signature value of the CMS signedData, not necessarily validate the signer's cert path. 4) John Linn proposed that text should be added to the Security Considerations section regarding the use of PKCS #1 v2. The group agreed that this was a good idea. John Linn agreed to provide the text for the Security Considerations section of CMS. X9.42 Draft Discussion - Russ Housley The D-H Key Agreement Method I-D (a.k.a. D-H I-D) is required before CMS can progress to WG Last Call. After the D-H I-D was published to the list, Russ asked if there were any patents that applied to the D-H variant documented in the I-D. Certicom announced on the list that they have applied for a patent that covers the variant of the D-H algorithm specified in the D-H I-D. He proposed two alternatives: 1) CMS and D-H I-Ds could continue to mandate the current D-H variant; or 2) WG could pursue a different D-H variant as the mandatory-to-implement KM algorithm to avoid the delay associated with working out the licensing agreement with Certicom. Russ presented a slide describing another variant. The variant currently documented in D-H I-D is called Static-Static (S-S) D-H. With S-S D-H, the originator has a static key and the recipient has a static key both of which are contained in certificates. The alternative is called Ephemeral-Static (E-S) D-H. With E-S D-H, the recipient has a static key contained in a certificate, but the originator generates an ephemeral key not contained within a certificate. Russ stated that the E-S D-H would need to be documented and then distributed to determine if there are any patents or pending patents that apply to the E-S D-H ariant. He stated that the E-S D-H has some of the same properties as the Open PGP D-H strategy, but not identical. Paul Hoffman noted that there have been no patent statements made regarding the Open PGP D-H strategy. Russ presented the following info: S-S D-H | E-S D-H | Pending patent | No patents (?) 1 exponentiation per recipient | 2 exponentiations per recipient Data origin authentication | No authentication Shorter certificate | Longer certificate (p,q,g) | (about 200 bytes longer) Originator cert in message | Originator cert not in message Common p,q,g parameters | Use recipient's p,q,g values The question was asked if q is really required to be transmitted in the CMS heading. Russ stated that q should be included so that the existing X9.42 ASN.1 syntax for the p,q,g parameters can be used. Also, the q value can be used to validate the p and g values. Darren Harter pointed out that there is another option in which the originator would produce a self-signed E-S D-H cert and include it in the message. Tim Dierks from Consensus Development Corporation/Certicom spoke regarding Certicom's pending patent that they believe covers the X9.42 D-H variant. Tim stated that Certicom is willing to issue a royalty-free license to S/MIME and PKIX vendors to use the technology covered by their pending patent. Tim stated that any applicant must divulge their own patents and pending patents that would block the implementation of the mandatory requirements of PKIX or CMS. Tim stated that Certicom will require that the applicant issue a royalty-free license to Certicom covering the applicant's patented technology. Tim stated that Certicom intends to gain revenue for use of the technology in "non-S/MIME" cases. Eric Rescorla pointed out that the S/MIME WG's acceptance of this option would limit future vendor's options. He also pointed out that CMS is used in applications other than S/MIME, so the Certicom's offer does not benefit all users of CMS. Paul pointed out that there is not an official definition of "S/MIME", so the limitation to issue licenses to "S/MIME" vendors is problematic. Paul also pointed out that there will probably be future versions of the S/MIME specifications. Paul reiterated Eric's statement that CMS is used in applications other than S/MIME. Jeff Schiller, the IETF Security Are Co-Director, expressed his desire to avoid a situation in which licenses must be obtained to implement mandatory-to-implement features. He was concerned with the restrictions placed by Certicom's proposal regarding how CMS is to be used. Jeff stated that he had difficulty with the "S/MIME" limitation included in Certicom's offer because not all CMS implementers would be able to obtain the royalty-free license. Jeff stated that he liked the E-S D-H option better than the S-S D-H option due to technical reasons in addition to the patent issues. Jeff stated that he has found that the two exponentiations required to be calculated for each recipient in the E-S D-H option is acceptable as far as performance is concerned. John Pawling pointed out that some vendors are implementing CMS/ESS security libraries that could be used by "S/MIME" or "non-S/MIME" applications, so this further complicates the issue. He pointed out that the E-S option eliminates the need to validate the originator's KM cert, so a significant time saving is achieved. He recommended that the WG should pursue both the E-S D-H and S-S D-H options in parallel. Several attendees agreed with this plan. Dave Solo pointed out that some environments consist of an "S/MIME" application on one end of a transaction and a "non-S/MIME" application on the other end. Dave also asked if there was an issue with using the E-S D-H option with forming a pairwise key with yourself. Russ stated that that there will not be a problem with that operation. Tim stated that he would obtain more info from Certicom. Later in the meeting after talking with Certicom via telephone, Tim stated that Certicom agreed to provide royalty-free licenses for all uses of CMS, not just for use in "S/MIME" applications. Tim stated that the license would also cover the use of S-S D-H in future versions of the CMS and PKIX specifications (not just S/MIME v3). SIGATTR Draft Discussion - Jim Schaad Jim used slides for his two presentations. Jim stated that the 2 July 98 Signing Certificate Attribute Specification (SIGATTR) I-D has been submitted to the S/MIME WG mail list. Jim stated that he would incorporate the comment regarding replacing the IssuerAndSerialNumber field with IssuerSerial so that Attribute Certificates can be identified. There was some debate regarding whether the CertID certHash value should be changed so that it is optional. Jim asked if the attendees believe that the SIGATTR text should be incorporated into CMS as a "MAY implement" option. Paul agreed that the Signing Certificate Attribute should be included as a "MAY implement" option in CMS. Dave Solo stated that he would like an enhancement to be made to the Signing Certificate Attribute syntax to allow the identification of the complete cert path of the signer (not just signer's cert). This enhancement is required so that the recipient can determine the context of the signer's signature by examining the cert path of the signer's cert. This issue requires further debate on the list. It was agreed that the SIGATTR text would not be incorporated into CMS until all issues are resolved. CERTDIST Draft Discussion - Jim Schaad Jim stated that the 6 July 98 Certificate Distribution (CERTDIST) I-D has been submitted to the S/MIME WG mail list. Jim stated that the open issues identified include: 1) Lack of content within the published message. He considers this one closed and that there will not be a content. 2) Ability of CA and RA to publishing information on behalf of the user. Through discussion with others, he has determined that the best solution requires an extension in the RA's cert. Issue: Is this overly broad for CAs to issue? Jim's current position is that only users can create these messages. Issue: Is the fact that any parent CA could issue this and the fact that a new Extension is required a problem. Jim's current position is that the risks out-weigh the benefits and that only users can create these messages. DOMSEC Draft Discussion - Bill Ottaway Bill stated that the 15 July 98 Domain Security Services using S/MIME (DOMSEC) I-D has been submitted to the S/MIME WG mail list. When asked how many people had read the DOMSEC I-D, many in the room raised their hands. Bill presented the briefing slides stored on ftp://ftp.ietf.org/ietf/smime/. These slides presented the basic points made in the DOMSEC I-D. There were no significant issues raised. The question was asked from the floor (by Paul Hoffman) as to the future plans for the document. Bill said he was happy to allow the working group to make that decision. Paul said that the DOMSEC I-D contained protocol, so it could not be progressed as an informational document. Chris Bonatti suggested that the protocol could be moved into CMS, allowing the document to become informational. Revocation Info in CMS - Paul Hoffman Paul proposed that the message originator should be able to include non-CRL revocation status information in the CMS heading "in case the recipient of the message cannot (or does not want to) get the status information when validating the signature, such as if the recipient is not online and no usable CRLs were included in the SignedData." For example, an OCSP response could be included in the CMS heading. This could be done via a new attribute or by enhancing the CMS CRL list syntax. This proposal requires further debate on the list. Wrap Up - Russ Housley Russ asked for a straw poll of the attendees regarding which options the WG should continue to pursue regarding the "mandatory-to-implement" KM issue. The results are as follows: 1) Pursue S-S D-H option: about 20 hands raised 2) Pursue E-S D-H option: about 50 hands raised 3) Pursue self-signed E-S- D-H option: 0 hands raised Based on this straw poll, options 1 and 2 will be pursued in parallel. Russ will investigate whether there are any patent issues with the E-S D-H option. Russ asked Tim Dierks to post further info regarding the Certicom license offer.