Final 11 November 1999 S/MIME WG Minutes

["Pawling, John" <[e-mail]>]

This message includes the minutes of the IETF S/MIME Working Group
meeting held on 11 November 1999 in Washington, D.C.  All briefing slides
are 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
RFC 2630 - 2634 Status                  Russ Housley
Charter Revision                        Russ Housley
Small Subgroup Attack                   Mike Just
CERTDIST Draft Discussion               Jim Schaad
DOMSEC Draft Discussion                 Bill Ottaway
CMS/ESS Examples                        Paul Hoffman
Security Policies and Labels            Weston Nicolls
KEA and SKIPJACK Algorithms             John Pawling
CAST-128 Algorithm                      Carlisle Adams
Elliptic Curve Algorithms               Paul Lambert
ETSI Electronic Signatures              Denis Pinkas
S/MIME Freeware Library                 John Pawling
Wrap up                                 Russ Housley


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

RFC 2630-2634 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

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

Stable, Mature, and Useful:
- Strong belief that the specification is mature and will be useful
- Must be well-understood and known to be quite stable
  - semantics and basis for developing an implementation
  - may still require additional or more widespread field experience
- Considered to be a final specification
  - changes are likely to be made only to solve specific problems
  - reasonable for vendors to deploy implementations

Russ noted that no significant errors had been reported to the 
aforementioned RFCs.

Implementations:
- At least two independent and interoperable implementations from
  different code bases:
  - interoperable means to be functionally equivalent or interchangeable
  - applies to all of the options and features 
- Working Group chair responsible for documenting specific 
  implementations and interoperability testing:
  - support of each of the individual options and features
  - submitted to Area Director with protocol action request

Way Forward:
- CMS and ESS Examples I-D providing informal inputs
- Jim Schaad is developing matrices for RFCs 2630-2634
- Paul Hoffman has offered to coordinate interoperability testing

Paul Hoffman stated that another requirement for a Proposed Standard 
to become a Draft Standard is that all normative references to other 
RFCs must refer to Draft Standards.  RFC 2632 includes a normative
reference to RFC 2459 (Internet X.509 Public Key Infrastructure
Certificate and CRL Profile), so RFC 2632 can not become a Draft
Standard until RFC 2459 becomes one.  Russ agreed with Paul's 
statement that a Draft Standard cannot include a normative reference
to a document that has not achieved at least Draft Standard status.
Russ agreed that since RFC 2632 relies on RFC 2459, then RFC 2459
will have to become a Draft Standard before or at the same time as
RFC 2632.    

Paul pointed out that each requirement must be implemented by at
least two independent code bases such that they are
interoperable, but a single code base does not need to implement 
all of the requirements.  Russ agreed that the entire set of
requirements could be implemented by a variety of sources.  The 
matrices being initiated by Jim Schaad will indicate which 
features have and have not been implemented.  

John Pawling asked if there were any plans to change the Attribute
Certificate (AC) syntax used in RFC 2630.  Currently, RFC 2630
imports the AC syntax from the 1997 X.509 Recommendation, but the 
draft IETF PKIX Attribute Certificate Profile Internet Draft
specifies a different AC syntax.  Russ pointed out that if RFC 2630
imported the AC syntax from the PKIX AC Profile, then RFC 2630
could not achieve Draft Standard status until the PKIX AC Profile 
achieved that status (which Russ believes will be at least six
months).  Russ stated that he believed that RFC 2630 should
continue to import the AC syntax from the 1997 X.509 Recommendation
because the other AC syntax is still not stable.  He stated that 
the new features of the new AC syntax don't apply to RFC 2630.  
The new AC syntax allows for binding attributes to arbitrary objects 
identified by object identifiers.  John pointed out that a new CMS
specification could be drafted in the future which could include
the new AC syntax once it is stable.  Nobody disagreed with Russ' 
statement that the RFC 2630 AC syntax should not be changed.

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

Charter Revision - Russ Housley

Russ stated that the following work items have been approved since
the July S/MIME working group meeting:
- Small Subgroup Attack Informational RFC
- Additional Algorithm Support:
  - KEA, SKIPJACK Informational RFC
  - IDEA, CAST, and ECC Standards Track RFCs
- CMS and ESS Examples Informational RFC
- CERTDIST Standards Track RFC
- Password-based Key Management RecipientInfo Extension Standards Track RFC
- Mail List Key Distribution Standards Track RFC
- Security Label Usage Informational RFC
- DOMSEC Experimental RFC

Russ stated that there is another proposed addition: CMS Compressed 
Proposed Standard RFC.  Compression improves security by removing
known data patterns, improves throughput by reducing the amount of
data which needs to be encrypted or hashed, and reduces the overall
message size.  Enabling S/MIME version 3 to use compression will 
provide all of these advantages.  The proposed schedule is as follows:
Oct 1999 - First Compression I-D.
Jan 2000 - Compression Last Call.
Apr 2000 - Compression Proposed Standard RFC.

Russ stated that both IETF Security Area Directors have expressed 
support for this addition.

Russ asked if any attendees knew of any issues, had comments or wished to 
discuss any related topics, and no one raised anything.  Russ asked if there

were any patent concerns, and no one raised any patent concerns.

Paul Hoffman stated that the previous IP Compression working group had
already worked on a compression standard and that the previous MIME working 
group had purposely avoided the issue of compression.  Russ asked if the
meeting attendees approved the addition of compression.  The majority 
approved.

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

Small Subgroup Attack - Mike Just 

Mike stated that there had not been a new draft of the "Methods for 
Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key 
Agreement Method for S/MIME" I-D since the last meeting.  One minor
comment was received regarding wordsmithing.  

Russ asked if the attendees believed that the I-D was ready for
working group last call.  Nobody objected, so Russ asked that 
the aforementioned comment be incorporated into a new I-D and then
that I-D would be submitted for last call.  Russ asked that people
please carefully review the I-D.   

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

CERTDIST Draft Discussion - Jim Schaad

Jim discussed the Certificate Distribution Specification I-D 
(CERTDIST-04), October 20, 1999.  He stated that "directory people"
had criticized CERTDIST, but had not proposed an alternate solution.
Russ noted that the directory folks were complaining because certificates
are stored in the directory twice within different attributes.  He said
that they are concerned that the certificates stored within the two
attributes will be different.  He also said that they proposed that 
SupportedAlgorithms could be used. Jim pointed out that the 
SMIMECapabilities signed attribute could be used to point to a certificate 
rather than storing the entire certificate.  Jim also stated that the 
method proposed in CERTDIST allows each certificate to claim different 
algorithm preferences.

Carlisle Adams asked if the SMIMECapabilities signed attribute is 
supposed to be tied to a specific certificate.  Jim answered that 
SMIMECapabilities must be tied to a specific key management certificate.

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

DOMSEC Draft Discussion - Bill Ottaway

Bill presented a briefing regarding the Domain Security Services Using
S/MIME I-D (DOMSEC-03).  Bill provided an overview of the DOMSEC
concepts and the new features. The new features included: Naming
conventions for signing and encryption, and the creation of a NULL 
signature when there is no originator signature present. Bill's briefing
is stored at ftp://ftp.ietf.org/ietf/smime/ and includes the details 
regarding the issues and proposed solution for each new feature.  Bill's 
goal is that DOMSEC should achieve RFC status in 2000.  He would like 
DOMSEC to describe a solution that will work for a wide variety of 
organizations.  He has received significant feedback from Baltimore,
but would like to hear feedback from others.

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. 

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

CMS/ESS Examples - Paul Hoffman

Paul stated that there has been much progress with the "Examples of 
S/MIME Messages" I-D and that almost all of the examples have been
provided for incorporation into the document.  He stated that there
needs to be more testers of the sample data.  He asked that folks
please publicize their progress with verifying the sample data.

Paul asked if there was any interest in a PKIX Examples Document. 
There was not much interest shown by the attendees.

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

Security Policies and Labels - Weston Nicolls

Weston stated that he is developing an I-D that will document the
security policies of Whirlpool, Caterpillar and Amoco.  The draft will
describe how the ESSSecurityLabel can be used to implement those
corporate security policies.  It is planned that the document will be
an Informational RFC.

Weston stated that he has been provided with classification policies for:
- Amoco Corporation: 
  - General, Confidential, Highly Confidential
  - Minimum, Medium, Maximum Integrity
- Caterpillar Inc
  - Public, Confidential Green, Confidential Yellow, Confidential Red
- Whirlpool Corporation
  - Public, Internal, Confidential
  - Privacy Labels
  - Security Categories?

Jim Schaad pointed out that an example security policy is needed to
populate sample ESSSecurityLabel attributes to be included in the
"Examples of S/MIME Messages" I-D. The implication of Jim's statement 
is that one of the security policies described in Weston's document could 
be used to populate sample ESSSecurityLabel attributes to be included in
the "Examples of S/MIME Messages" I-D.

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

KEA and SKIPJACK Algorithms - John Pawling

John presented the CMS KEA and SKIPJACK Conventions I-D (CMSKEA-02),
29 July 1999.  The goal of CMSKEA is to promote interoperability between
implementations using the Key Exchange Algorithm (KEA) and SKIPJACK 
encryption algorithms with the RFC 2630 enveloped-data and encrypted-data
content types. CMSKEA describes a profile for using SKIPJACK and KEA with
CMS.  It describes modes, key lengths, object identifiers and parameter
formats associated with the use of SKIPJACK and KEA with CMS.  J.G. 
Van Dyke and Associates (VDA), a Wang Government Services Company,
has used the S/MIME Freeware Library with the Fortezza Cryptologic 
Interface (CI) Library and Fortezza Card to successfully perform
interoperability testing with Microsoft.  This testing verifies the
correctness of the CMSKEA I-D.  

The "FORTEZZA Card\CI Library Usage With CMS KEA SKIPJACK I-D" text
file (available from http://www.jgvandyke.com/services/infosec/sfl.htm) 
contains hints for using the FORTEZZA Card and FORTEZZA CI Library
to meet the CMSKEA requirements.  

Russ pointed out that CMSKEA is planned to be an Informational RFC.  He
stated that he would like to issue the working group last call for
CMSKEA.  Nobody objected.

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

CAST-128 Algorithm for S/MIME - Carlisle Adams

Carlisle discussed the "Use of the CAST-128 Encryption Algorithm in
S/MIME" I-D, September 1999 (cast-128-00).  He stated that this is a 
short, simple specification.  It documents how to use CAST-128 as a 
content encryption algorithm and a key encryption algorithm.  The 
relevant algorithm object identifiers and parameters are specified.

Carlisle stated that there are patents issued and pending regarding
the CAST design procedure, but CAST-128 (described in RFC 2144) may
be used by anyone for any purpose without paying any royalties or 
obtaining any licenses as stated in www.ietf.org/ipr.html.  He stated
that there is no encumbrance in using CAST-128.  The same is true for
CAST-256 (RFC 2612).

Russ pointed out that the CAST-128 document is planned to be on
Standards Track.  He stated that he would like to issue the working
group last call for the document as soon as possible.  Nobody
objected.

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

Elliptic Curve Algorithms - Paul Lambert

Paul briefed the "Elliptic Curve S/MIME" I-D, October 1999 (ECC-00). 
He stated that the EC algorithms support digital signatures and key 
management.  EC Diffie-Hellman (D-H) is based on ANSI X9.63 and EC Digital 
Signature Algorithm is based on ANSI X9.62.  Paul stated that there is one 
issue. The I-D includes two recommendations for ECDH: one-pass D-H and
cofactor D-H.  Paul recommends that the S/MIME working group pick one
or the other, but not both.  Paul's briefing is stored at 
ftp://ftp.ietf.org/ietf/smime/ and includes additional details 
regarding the EC S/MIME I-D.

Paul Hoffmann stated his concerns about the patent issues regarding the
EC algorithms.  He stated that the IPR for the EC algorithms is
insufficient for the WG to decide what to do.

Paul Lambert stated that Certicom has patents and patent
applications that may cover the specification and will include a pointer
to the IPR statement in the EC S/MIME I-D.

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

ETSI Electronic Signatures - Denis Pinkas

Denis briefed the "European Electronic Signature Standardisation
Initiative".  He stated that the European Community plans to vote on
the EESSI directive.  The directive will cover anything in digital
form that can prove the identity of the signer.  The goal is to 
specify technology and standards that are equivalent to a manual
signature.  The ETSI definition provides "Evidence in a digital form 
than can be processed to get confidence that some commitment has been 
explicitly endorsed under a signature policy, at a given time, by a
signer under an identifier, e.g. a name or a pseudonym, and
optionally a role."  The ETSI draft Standard builds upon RFC 2630 and
RFC 2634.  It defines new signed and unsigned attributes.  The Electronic
Signature uses signed attributes defined in RFC 2630, RFC 2634 and the 
draft ETSI standard including:
- signature policy ID (reference and hash) (new),
- commitment type (new),
- content Type [RFC 2630],
- signer's physical location (new),
- signing time [RFC 2630],
- signing certificate reference [RFC 2634],
- role attribute (claimed or certified) (new).

Denis also briefed regarding the role of time stamping in the EESSI.
His briefing is stored at ftp://ftp.ietf.org/ietf/smime/ 
and includes additional details regarding the EESSI.

An attendee asked how the verifier can prove the signer's 
physical location.  Denis said that the EESSI specification replicates
the services provided by the paper hard copy which is no authentication
of the signer's location value.

Phillip Hallam-Baker stated that the requirement for the signer to state 
her location is bogus and is not required in the United Kingdom.

An attendee stated that a 760-bit signing key could be
compromised in 20 years, so the time stamp signature could be
compromised too.  Denis said that an authority can re-sign the
time stamps with a longer length key or could apply two stamps.

Chris Bonatti asked if the signature policy is selected by the
signer, what guarantee is there that the verifier will recognize
the signature policy.  Denis said that the verifier will look
for specific values.

An attendee asked whether there will be a signature policy
distribution point from which people could obtain defined policies.
Denis said that service might be provided by the International
Chamber of Commerce.

An attendee asked if XML would be more useful to describe 
the signature policy than ASN.1.  Denis said that ASN.1 will be
used for now, but XML may be used in the future.  Phillip
Hallam-Baker stated that XML is better for future use.

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

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.  It uses the Crypto++ freeware
library to implement RFC 2631.  It 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.

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 now developing the capability for the SFL to use any security library
that provides a PKCS #11 interface.

Version 1.3 of the SFL was released in October 1999.  It was tested on 
MS Windows 95/NT and Sun Solaris 2.6.  It was tested using the 
mandatory and RSA algorithm suites.  VDA continues to enhance the SFL.  

Organizations can use the SFL as part of their applications without paying
any royalties or licensing fees (see SFL Public License).  All source
code is provided.  The VDA-enhanced SNACC ASN.1 software is freely 
available at http://www.jgvandyke.com/services/infosec/sfl.htm.  All 
other portions of the SFL are available at:
http://www.armadillo.huntsville.al.us/software/smime and are export
controlled as per U.S. Government Export Administration Regulations (see:
http://www.bxa.doc.gov/Encryption/Default.htm).

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's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ 
and includes additional details regarding the SFL and CML.


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

Wrap Up - Russ Housley

Russ discussed the work item proposing the use of password-based key 
management for file encryption.  This is documented in the "Password-based
Encryption for S/MIME" I-D.  The proposal uses PKCS #5 techniques. 
Russ stated that the working group needs to decide if that proposal
will be accepted.  He encouraged people to read the document and
provide comments.

Bob Jueneman stated his concern with the processing of
name forms.  Bob is concerned that not all applications display 
all address spec texts.  He stated that they may omit, abbreviate
or truncate the address spec text.  He believes that this should be a 
joint work item between the PKIX and S/MIME working groups.  He stated 
that properly supporting the address spec requirements is important.
He recommends that we allow the use of a personal name form that
precedes the address spec.  For example, a husband and wife may 
share an e-mail address, but use different certificates.

Paul Hoffman stated that RFC 822 includes a third option 
that allows comments to be included in parentheses.  The
third option must be included in any solution.  He agreed that
this issue needs to be resolved.

Bob Jueneman also stated his concern regarding using the same object
identifier to indicate two-key triple-DES and three-key triple-DES.
He believes that separate object identifiers must be used for
export control reasons.  Two-key triple-DES may be exportable, 
but 3-key triple-DES may not be exportable.  He said that 
168-bit keys (112 effective) need a separate object identifier.

Paul Hoffman stated that his understanding is that two-key is 80-bit and
three-key is 112 bit (effective).  He does not believe that the object 
identifier should be changed.

Russ asked if it would be acceptable to examine the contents of the key 
to determine if the first and third keys are the same.  Bob said that 
he has to enforce that they are the same.  Russ said that it seems
to be a receive-side issue, since the send-side controls the formation
of the keys.  Russ asked if the receive side could examine the keys and
stop processing if the first and third keys are different. 

Paul Hoffman noted the creation of the S/MIME developers mail list for
discussing implementation of S/MIME.  The new list is a good place to
send sample S/MIME messages for interoperability testing. 
The list is called [e-mail]. To subscribe, send a message 
to [e-mail] with the single word "subscribe" in 
the body of the message.

Russ noted that members of the S/MIME mail list don't necessarily need 
to use S/MIME-enabled e-mail products.

Meeting adjourned.