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 <draft-ietf-smime-x942-00.txt>.

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:

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.