All,
This message includes the minutes of the IETF S/MIME Working Group (WG)
meeting held on 26 August 1998 in Chicago, IL. These minutes have been
coordinated with the briefing presenters. 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. The attendees agreed that wording was sufficient.
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 variant. 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.
======================================================
John Pawling jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc. www.jgvandyke.com
======================================================