Subject: Final 29 March 2000 S/MIME WG Minutes

From: "Pawling, John" <[email-masked]>
Date: Mon, 8 May 2000 16:51:27 -0400

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 <[email-masked]>

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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 [email-masked].  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 
<[email-masked]>.  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.