All,
This message includes the minutes of the IETF S/MIME Working Group meeting
held on 10 December 1997 in Washington, D.C. These minutes have been
coordinated with the briefing presenters and their comments have been
incorporated. 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 <Filename>
--------- ------------------------------------------
Nov 97 Cryptographic Message Syntax (CMS)
<draft-ietf-smime-cms-01.txt>
18 Nov 97 Enhanced Security Services (ESS) for S/MIME
<draft-ietf-smime-ess-00.txt>
20 Nov 97 S/MIME Version 3 Message Specification (MSG3)
<draft-ietf-smime-msg-00.txt>
Nov 97 S/MIME Version 3 Certificate Handling (CERT3)
<draft-ietf-smime-cert-00.txt>
++++++++++++++++++++++++++++++++++++++++++++++++
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(_dot_)dean(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk(_dot_)
++++++++++++++++++++++++++++++++++++++++++++++++++
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
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================