John,
I was looking for Greg's briefing which was supposed to be stored at
ftp://ftp.ietf.org/ietf/smime/ but could not find it. Can you point it out
to me?
Thanks,
Raviv Karnieli - CTO
Vanguard Security Technologies Ltd.
Tel. +972-4-989-1311 Fax +972-4-989-1322
www.vguard.com raviv(_at_)vguard(_dot_)com
This message left my computer secured since I'm using
MAILguardian Enterprise the first true end to end enterprise e-mail security
solution that is policy based, centrally managed and totally transparent to
the end users.
You can get your own free evaluation copy of MAILguardian
at http://www.vguard.com/prod.asp
-----Original Message-----
From: Pawling, John [mailto:John(_dot_)Pawling(_at_)wang(_dot_)com]
Sent: Monday, May 08, 2000 10:51 PM
To: SMIME WG (E-mail)
Subject: Final 29 March 2000 S/MIME WG Minutes
This message includes the minutes of the IETF S/MIME Working Group
meeting held on 29 March 2000 in Adelaide, Australia. All briefing
slides will be stored at: ftp://ftp.ietf.org/ietf/smime/. These
minutes include comments from the briefing presenters.
Reported by John Pawling.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Introductions - Russ Housley
Russ reviewed the agenda as follows. Nobody objected to the agenda.
Introductions Russ Housley
Working Group Status Russ Housley
Security Policies and Labels Russ Housley
CERTDIST Draft Discussion Jim Schaad
Symmetric Key Distribution Sean Turner
DOMSEC Draft Discussion Bill Ottaway
Interoperability Matrix Jim Schaad
CMS/ESS Examples Paul Hoffman
Crypto Algorithm Documents Russ Housley
E-mail Addresses & Certificates Greg Colla
S/MIME Freeware Library John Pawling
Electronic Signature Formats John Ross
Wrap up Russ Housley
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
S/MIME Working Group Status - Russ Housley
Russ outlined the strategy for advancing the following RFCs from
Internet Proposed Standards to Internet Draft Standards:
RFC 2630 Cryptographic Message Syntax, R. Housley, June 1999
RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999
RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the
Diffie-Hellman Key Agreement Method for S/MIME.
R. Zuccherato. March 2000. [Informational]
The aforementioned documents must meet the following requirements to
become Draft Standards:
1) Meet requirements documented in RFC 2026
2) Stable, mature, and useful specification
3) At least two independent and interoperable implementations
from different code bases
4) Draft Standards cannot reference Proposed Standard RFCs or
Experimental RFCs, so the aforementioned RFCs are blocked
until the PKIX Certificate and CRL Profile "Son-of-RFC 2459"
Internet-Draft (I-D) (draft-ietf-pkix-new-part1-01.txt)
progresses to Draft Standard.
Russ stated that Jim Schaad has developed an interoperability matrix
for RFCs 2630 through 2634. Once completed, the matrix will
indicate which features have and have not been implemented. So far,
Microsoft and J.G. Van Dyke and Associates (VDA) have provided input
to the interoperability matrix. Russ asked that other organizations
that have developed S/MIME v3 capabilities should contribute to the
matrix.
Russ stated that testing of the example data included in the
"Examples of S/MIME Messages" I-D is providing informal inputs for
the matrix. Paul Hoffman stated that that other code bases also
need to be tested. He welcomed feedback from novice developers.
He has offered to coordinate interoperability testing. In the past,
Paul has coordinated face-to-face SecureConnect interoperability
events. He believes that future interoperability testing will not
be face-to-face, but will be supported via a bulletin board or e-mail.
He will announce any S/MIME inter events on the S/MIME WG mail list.
Those events will be discussed in detail on the S/MIME developers
mail list <imc-smime-dev(_at_)imc(_dot_)org>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Mapping Company Classification Policy to the S/MIME Security Label
- Russ Housley
The "Implementing Company Classification Policy with the S/MIME
Security Label" I-D, <draft-ietf-smime-seclabel-00.txt>, December
1999, was authored by Weston Nicolls. It is planned that the document
will become an Informational RFC. It describes how the ESS Security
Label can be used to implement an organizational security policy.
It includes three organizational examples: Whirlpool, Caterpillar
and Amoco. One use of this document is to provide sample policies
for interoperability testing.
The document includes the security policy for Amoco Corporation
as follows:
- Confidentiality: General, Confidential, Highly Confidential
- Integrity: Minimum, Medium, Maximum
It includes the security policy for Caterpillar Inc as follows:
- Confidentiality: Public, Confidential Green,
Confidential Yellow, Confidential Red
It includes the security policy for Whirlpool Corporation
as follows:
- Confidentiality: Public, Internal, Confidential
- Additional marks at discretion of owner:
- Privacy Marks?
- Security Categories?
- Do they require access control?
Way Forward:
- Support interoperability testing
- Need to assign Object Identifiers: IETF values for this document
and testing
- Organizations assign their own
After discussion with Weston Nicolls, who could not be present at
this meeting, three object identifiers were assigned to permit the
Whirlpool, Caterpillar and Amoco security policies to be used in
interoperability testing. These object identifiers are not the
ones that will be used by the companies, rather they are
intended for testing. The object identifiers are:
-- S/MIME Working Group Object Identifier Registry
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
-- Test Security Policies Arc
id-tsp OBJECT IDENTIFIER ::= { id-smime 7 }
-- Test Security Policies
id-tsp-TEST-Amoco OBJECT IDENTIFIER ::= { id-tsp 1 }
id-tsp-TEST-Caterpillar OBJECT IDENTIFIER ::= { id-tsp 2 }
id-tsp-TEST-Whirlpool OBJECT IDENTIFIER ::= { id-tsp 3 }
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CERTDIST Draft Discussion - Jim Schaad
Jim discussed the Certificate Distribution Specification I-D
<draft-ietf-smime-certdist-04.txt>, October 20, 1999. The CERTDIST
I-D was submitted for S/MIME WG "last call" for comments on 22 October
1999. Jim stated that he received comments regarding the following
topics:
- LDAP Directory Attribute layout
- Additional arguments against CERTDIST Section 2 (current methods
of publishing certificates)
- miscellaneous minor comments
Jims stated that he plans to publish an updated version of the
CERTDIST I-D soon.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Symmetric Key Distribution - Sean Turner
Sean discussed the S/MIME Symmetric Key Distribution I-D,
<draft-ietf-smime-symkeydist-00.txt>, December 20, 1999. He stated
that the design goals are to provide a transport independent
mechanism for distribution of symmetric keys to a group of users.
The mechanism must use RFC 2630. It must maximize the reuse of
existing group/list management techniques (listserv, majordomo, etc).
Seam explained the diagrams included in the I-D.
Sean stated that he did not know of any patents regarding the secure
distribution of symmetric keys. He asked if anybody else knew of
any patents. Nobody replied.
Paul Hoffman pointed out that the majordomo mail list server
software does not support all mail list features. He stated that
the SYMPA mail list server includes a database and rich set of
features.
Paul also pointed out that customers ask him on a monthly
basis for secure mail list capabilities, so he knows that there
are real requirements for these capabilities.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
DOMSEC Draft Discussion - Bill Ottaway
Bill presented a briefing regarding the "Domain Security Services Using
S/MIME" I-D <draft-ietf-smime-domsec-04.txt>. He stated that there
are minor differences between the -03 and -04 drafts as follows:
- DOMSEC signatures are now added by encapsulation only. (Used to
allow parallel signatures).
- Allows order of third party signature application to be known.
- More secure.
- Section four re-written to aid understanding
Bill discussed the proposed solution to an issue raised during the
December 1999 S/MIME WG meeting. From those minutes: "Jim Schaad
recommended that the domain name should be exactly matched.
Jim also pointed out that RFC 2630 states that the content type
should be id-data when there are no signers of a signedData object."
Bill proposes that the original domain naming conventions should be
preserved. Bill briefed that the users "must always rely on the CA
to police naming conventions."
Bill addressed Jim's other comment by adding text to the case when
no originator signature is present to state that the eContentType
will be id-data as specified in CMS. However, the eContent will
contain the unsigned message instead of being left empty as
suggested in CMS (section 2). This allows the DOMSEC signature
to cover the message which does not have an originator signature.
Bill stated that an object identifier must be obtained for the
id-signatureType attribute. He believes that the document is
ready for working group last call.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Interoperability Matrix - Jim Schaad
Jim developed an interoperability matrix for RFCs 2630 through 2634.
Jim has documented the features supported by Microsoft. VDA provided
input to Jim regarding the capabilities of the S/MIME Freeware
Library (SFL). VDA also provided input regarding interoperability
testing conducted between the SFL and Microsoft. Jim asked for others
to submit input to him at jimsch(_at_)nwlink(_dot_)com(_dot_) Jim also pointed
out that
there are some minor comments/questions to the RFCs that accompany
the matrix.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Examples of S/MIME Messages - Paul Hoffman
Paul stated that the "Examples of S/MIME Messages" I-D needs more
input. He stated that VDA had tested the samples in the document
and was planning to provide further sample data for inclusion in
the document. He stated that the document is valuable because it
includes the ASN.1 encoded examples. He stated that there is sample
data that can be extracted using a Perl script that is also
included in the document.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
S/MIME WG Cryptographic Algorithm Specification - Russ Housley
Russ briefed that the current S/MIME WG charter states: "The
Cryptographic Message Syntax (CMS) is cryptographic algorithm
independent, yet there is always more than one way to use any algorithm.
To ensure interoperability, each algorithm should have a specification
that describes its use with CMS. Specifications for the use of
additional cryptographic algorithms will be developed. An
additional suite of "mandatory to implement" algorithms may be
selected."
Russ briefed that the following I-Ds document the use of crypto
algorithms with RFC 2630:
1) Use of the CAST-128 Encryption Algorithm in CMS,
<draft-ietf-smime-cast-128-01.txt>
2) CMS KEA and SKIPJACK Conventions,
<draft-ietf-smime-cmskea-04.txt>
3) CMS RSAES-OAEP Conventions,
<draft-ietf-smime-cms-rsaes-oaep-00.txt>
4) Elliptic Curve S/MIME,
<draft-ietf-smime-ecc-00.txt>
5) Incorporation of IDEA Encryption Algorithm in S/MIME
<draft-ietf-smime-idea-02.txt>
Russ said that the following question was raised on the S/MIME WG
mail list: "Should the specifications be published as Standards
Track RFCs or Informational RFCs?" Russ stated that "mandatory-to-
implement" algorithms will be published as Standards Track RFCs.
He pointed out that the current S/MIME WG charter also states that
complete algorithm specifications will be published as Standards
Track RFCs.
Jeff Schiller stated that he believes that all drafts describing
the details of a crypto algorithm must be Informational because
the IETF cannot control the definition of the crypto algorithms.
Jeff further stated that he believes that all documents describing
how crypto algorithms can be used with an IETF protocol can be
Standards Track because the IETF can control the use of the
crypto algorithms. He further stated that all documents describing
how secret or proprietary crypto algorithms can be used can not be
Standards Track.
Russ applied Jeff's recommendations to the aforementioned list
of I-Ds:
1) The "Use of the CAST-128 Encryption Algorithm in CMS" I-D can
be a Standards Track document because the CAST 128 algorithm
description is freely available.
2) The "CMS KEA and SKIPJACK Conventions" I-D can not be a Standards
Track document because the U.S. Government has not freely
published the description of the FORTEZZA 80-bit wrap function
used to wrap the 80-bit SKIPJACK content encryption key.
3) The "CMS RSAES-OAEP Conventions" I-D can be a Standards Track
document because the PKCS #1 v2.0 algorithm description is
freely available.
4) The "Elliptic Curve S/MIME" I-D can be a Standards Track
document because the algorithms are documented in ANSI X9.62
and ANSI X9.63. Paul Hoffman said that someone told him that
Certicom has patents or pending patents on all of the "interesting
and useful" curves. Russ agreed that Standards Track could only
be achieved if the appropriate patent statements were made by
Certicom or any other patent holder.
5) The "Incorporation of IDEA Encryption Algorithm in S/MIME" I-D
can not be a Standards Track document because the IDEA
crypto algorithm description is not freely available.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Application of Attribute Certificates (AC) in S/MIME - Greg Colla
Greg's briefing addressed the topic of checking the e-mail address
of the signedData signer against the e-mail address in the signer's
certificate.
Greg briefed that there are problems with binding the subject's e-mail
address with the subject's public key in an X.509 public key certificate
such as:
- Multiple e-mail addresses
- Maintenance of e-mail addresses
- Security Proxy (a proxy signs and decrypts on behalf of many users)
- Privacy/Spam
Greg briefed the following requirements:
Address Aliasing: Associate a single entity with multiple e-mail
addresses, with a single PKC.
Secure Proxying: Associate multiple entities, each with their own
e-mail address, with a common PKC.
Address Sharing: Associate multiple entities, each with their own PKC,
with a single e-mail address.
Greg proposed the following:
- Maintenance of e-mail addresses limits S/MIME usability
- ACs can be used to cryptographically bind e-mail addresses with PK
certificates
- E-mail ACs provide a flexible solution for maintaining e-mail
addresses
- Supplements current infrastructure
- Localized modifications required to S/MIME components to use
E-mail ACs
- E-mail ACs can be used to solve other S/MIME limitations
Greg summarized by stating that his proposal provides a strategy
for removing email addresses from PK certificates. Greg's briefing
is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional
details regarding his proposal.
Paul Hoffman stated that there are not many deployed ACs and that
most companies have not implemented ACs. Paul stated his concern
that the AC proposal will add confusion to and delay the deployment
of S/MIME v3. He stated that ACs can be used in the future to solve
problems. Greg Colla rebutted that they face these problems today
(i.e. associated with binding e-mail addresses with public keys).
Jim Schaad stated the following comments/questions regarding Greg's
proposal:
1) Two directory lookups will be required for each recipient of
an encrypted message. This added time delay will decrease
overall performance.
2) How does this help keep email addresses private? People will
mail ACs in messages. A "spam harvester" could obtain the
e-mail addresses out of messages in transit or out of the
directory.
3) Solves internal/external problem.
4) Favors this approach for gateway address identification.
5) Agrees with Paul Hoffman's comments regarding adding confusion.
An attendee stated that CAs issue certificates and ISPs issue addresses.
He asked whether Greg's proposal assumes that these two entities work
closely together. Greg answered that an ISP could use an RA to create
certificates. A system administrator could generate the AC. He made
the point that the public key certificate generation is much more
important.
Another attendee stated that he doesn't agree that including e-mail
addresses in certs is a problem.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
S/MIME Freeware Library (SFL) - John Pawling
John provided an update briefing regarding the SFL which is a freeware
implementation of RFC 2630 and RFC 2634. The SFL can be used with the
Crypto++ freeware library to implement RFC 2631. The SFL provides
functions to support use of RFC 2632 and RFC 2633. The goal of the SFL
is to provide a reference implementation of RFC 2630 and RFC 2634 to
encourage their acceptance as Internet Standards. VDA is developing
the SFL.
John briefed that on 14 January 2000, the U.S. Department of Commerce
published revisions to the Export Administration Regulations that
changed the U.S. Government's encryption export policy. In accordance
with these revised regulations, the unencumbered SFL source code is
now freely available to everyone at:
http://www.armadillo.huntsville.al.us/software/smime.
Organizations can use the SFL as part of their applications
without paying any royalties or licensing fees. There is a public
license associated the SFL.
The SFL implements the optional RFC 2634 security services such as signed
receipts, security labels, mail list information, signing certificate
attribute and equivalent security labels. It has been used with the RSA
BSAFE v4.2, Crypto++ v3.1, Fortezza CI and SPYRUS SPEX/ libraries. VDA
is developing the capability for the SFL to use any security library
that provides a PKCS #11 interface.
John stated that VDA had used the SFL to perform a significant amount
of S/MIME v3 interop testing. VDA tested the majority of features
in RFCs 2630, 2631 and 2634 as well as some of the features in RFCs
2632 and 2633.
VDA used the SFL to successfully process and produce the majority
of features documented in "Examples of S/MIME Messages". A summary
of the test results was sent to the S/MIME WG examples mail list
<ietf-smime-examples(_at_)imc(_dot_)org>. Complete test drivers and test data
is available with the SFL.
S/MIME v3 interoperability testing between the SFL and Microsoft
successfully tested almost all signedData and envelopedData features
using mandatory, RSA and Fortezza algorithm suites. For example,
the SFL (using Crypto++) exchanged E-S D-H-protected envelopedData
with Microsoft. Almost all of the ESS features were tested. For
example, successful signed receipt interoperability testing was
performed between the SFL and Microsoft.
VDA verified that the SFL can produce and process the majority of
the features documented in Jim Schaad's S/MIME v3 interoperability
matrix. John sent the matrix to which VDA added the SFL test results
to Jim Schaad for incorporation into the master S/MIME WG matrix.
VDA developed sample objects that illustrate each feature in the
matrix that the SFL supports. Complete test drivers and test data
are available with the SFL.
SFL interoperability testing is automated through use of test drivers
and configuration files so it can be easily repeated and modified by
VDA or independently by a third party. A third party could enhance
the test drivers or incorporate them in an application such as an
S/MIME interoperability testing auto-responder which organizations
could use to test their S/MIME implementations.
John also provided information regarding the Certificate Management
Library (CML) that is a freeware implementation of X.509 version 3
certification path verification as specified in the 1997 X.509
Recommendation (except Delta CRLs are not implemented).
The CML: validates X.509 certification paths and CRLs; provides
local certificate/CRL storage functions; and provides remote
directory retrieval via LDAP. The CML uses the Certificate Path
Development Library (CPDL) developed by Cygnacom Solutions to
robustly build certification paths including cross certificates.
The CML complies with the majority of the RFC 2459 requirements.
Organizations can use the CML as part of their applications without
paying any royalties or licensing fees (see CML Public License).
All CML source code is provided. CML is available at:
http://www.armadillo.huntsville.al.us/software.
John also discussed the VDA-enhanced SNACC Abstract Syntax Notation
One (ASN.1) library that implements the Distinguished Encoding
Rules (DER).
John's briefing is stored at ftp://ftp.ietf.org/ietf/smime/
and includes additional details regarding the SFL and CML.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ETSI Electronic Signature Formats - John Ross
John briefed regarding electronic signature formats for long term
electronic signatures as part of the ETSI Electronic Signature
Infrastructure Standardisation.
John briefed that Special Task Force (STF) 155 includes:
Task 1: Policies for Certificate Service Providers (CSP).
Policy Requirements on CSP issuing Qualified Certificates
Task 2: Electronic Signature Formats
ETSI ES 201 733 & this Informational RFC
Task 3: Profile for Qualified Certificates
Task 4: Profile for TimeStamping Services
John discussed the "Electronic Signature Formats for long term
electronic signature" I-D, <draft-ietf-smime-esformats-00.txt>.
John briefed that this document is proposed as an Informational RFC.
It defines the format of an electronic signature that can remain
valid over long periods. It includes features which can provide
evidence as to its validity even if the signer later attempts
to deny (repudiate) the validity of the signature.
John stated that the contents of this Informational RFC will be
technically equivalent to ETSI ES 201 733 V.1.1.1 Copyright (C).
He noted that the authors do not provide the IETF with any rights
other than to publish as an Internet-Draft.
John briefed that this document builds on other IETF standards
such as RFC 2630 and RFC 2459. It will also build on coming
standards such as the PKIX Timestamping protocol and PKIX AC
profile.
John discussed the proposal to split the draft document into
two RFCs: one RFC dealing only with ES formats, the other one
dealing only with a Signature Policy format. In such a case,
the basis of this split will be, sections 6 and annex C will
be removed from this document and placed in another RFC
dealing with Signature policies. Also, the signature policy
ASN.1 will be removed the current ASN.1 modules in annex A
and placed in a new ASN.1 module in the other RFC dealing
with Signature Policies. A separate OID for the Signature
Policy arc would ease separation.
Denis Pinkas made the point that the SigningCertificate signed
attribute provides information about the signer and indicates the
signer's AC that indicates which role the signer used to sign the
data.
The point was made that the Signature policy Identifier attribute
is used by the signer to indicate the signature policy under which
he is signing. The Signature policy Identifier attribute will
contain a hash of the signature policy. The esformats-00 I-D
provides further details regarding the definition and use of
signature policies.
John made the point that the esformats-00 I-D must be equivalent
ETSI ES 201 733 V.1.1.1, so major changes can't be made to the
esformats-00 I-D.
Sean Turner asked how the ETSI Electronic Signature format relates
to the timestamping work being done in the PKIX WG. Denis Pinkas
answered that the ETSI Electronic Signature work uses CMS and will
build on the PKIX Timestamping protocol.
Mike Myers asked if the PKIX Data Validation and Certification Server
(DVCS) Protocols would satisfy the ETSI Electronic Signature
requirements. Peter Sylvester said that the DVCS protocol could
include the ETSI Electronic Signature information. Denis stated the
protocols could be used together, but don't have to be.
Sean Turner asked if the S/MIME WG cared about the contents of the
esformats-00 I-D, since they can't change it anyway. John Ross
replied that the signature policy portion of the I-D can be changed,
but that the Electronic Signature format can not be changed. John
welcomed input to the signature policy portion of the I-D.
Russ Housley asked if the signature policy portion of the I-D was
covered under the ETSI copyright. John Ross said that it was. He
further stated that they are working on getting the copyright rules
relaxed regarding this topic. ETSI may split the ES 201 733 V.1.1.1
document into two parts to be consistent with a split in the
esformats-00 I-D. A straw poll of the attendees favored splitting
the esformats-00 I-D.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Wrap Up - Russ Housley
Russ stated that the "Use of the CAST-128 Encryption Algorithm in
CMS" I-D was in working group last call. Jim Schaad stated that
he had provided comments to the document. Russ stated that
a new draft of the I-D will be submitted for IETF-wide last call.
Russ stated that he would like to issue last call for the
"Password-based Encryption for S/MIME" I-D. Jim Schaad stated that
he had provided significant comments to the document. John Pawling
pointed out that several people had questioned why the I-D defined
yet another key wrapping algorithm. Russ said that Peter Gutmann
needs to address these comments on the mail list. Russ pointed
out that the process of transforming a password to a key would
be documented in a separate RFC.
Russ discussed the "Compressed Data Content Type for S/MIME" I-D.
Peter Gutmann sent a message to the S/MIME WG mail list asking:
"Does anyone have any further thoughts on compression as a CMS
content type vs a MIME type?" Russ said that the S/MIME WG
needed to make a decision regarding Peter's question. Paul
Hoffman stated that compression has been discussed on the
MIME mail list, but it has not been standardized. He said that
the issue needs to get resolved. Russ stated that Jeff Schiller
recommended that the S/MIME WG "just do it" because the issue
needs to be resolved for efficiency purposes. Russ took a straw
poll and only three people expressed an opinion.
Meeting adjourned.