Subject: 31 July 2000 S/MIME WG Minutes

From: "Pawling, John" <[email-masked]>
Date: Thu, 24 Aug 2000 17:20:20 -0400

This message includes the minutes of the IETF S/MIME Working Group
meeting held on 31 July 2000 in Pittsburgh, Pennsylvania, U.S.A. 
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 commented on the agenda.

Introductions				Russ Housley
Working Group Status			Russ Housley
Interoperability Matrix 		Jim Schaad
CERTDIST Draft Discussion 		Jim Schaad
Symmetric Key Distribution		Sean Turner
Security Policies and Labels		Weston Nicolls
Message Compression		      Ned Freed
DOMSEC Draft Discussion 		Bill Ottaway
CMS/ESS Examples				Paul Hoffman
Crypto Algorithm Documents		Russ Housley
RSA as a MUST Implement	            Blake Ramsdell
Electronic Signature Formats		John Ross
Signature Policy Format	            Denis Pinkas
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]
RFC 2876 Use of the KEA and SKIPJACK Algorithms in CMS, J. Pawling,
          July 2000. [Informational]            

The aforementioned documents must meet the following requirements to
advance to 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-02.txt) 
   progresses to Draft Standard (last call was estimated to begin by
   7 August 2000). 

Russ stated that Jim Schaad has developed an interoperability matrix
for RFCs 2630 through 2634. The interoperability matrix is posted at
<http://www.imc.org/ietf-smime/interop-matrix.html>.  The matrix 
indicates which features have and have not been implemented.  So far,
Microsoft and Wang Government Services (WGS), A Getronics Company,
have provided input to the interoperability matrix.  WGS has provided
input regarding the capabilities of the S/MIME Freeware Library (SFL)
including interoperability testing conducted with Microsoft.  

Russ noted that Paul Hoffman (IMC) has offered to coordinate 
interoperability testing and to enhance the "Examples of S/MIME 
Messages" I-D.  He also noted that no other organizations have 
participated in the interoperability testing.  He asked that other
organizations that have developed S/MIME v3 capabilities should 
please participate.

There are some S/MIME v3 features for which interoperability testing 
has not been performed between at least two independent 
implementations.  For example, Russ pointed out that the 
EncryptedData, AuthenticatedData and DigestedData content types 
have not been tested between two parties.

Russ proposed that RFC 2630 should be changed to state that:
 - EnvelopedData and SignedData MUST be implemented; and
 - EncryptedData, DigestedData, and AuthenticatedData MAY be 
     implemented.

Russ said that he would submit that proposal to the IETF S/MIME
working group (WG) mail list.

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

Interoperability Matrix - Jim Schaad

Jim discussed the interoperability matrix for RFCs 2630 through 2634.
He has documented the successful completion of two-way interoperability
testing for the following number of clauses in each RFC.  He noted that 
he has not completely updated the results based on all interoperability
testing performed:

   RFC      Clauses Tested
   2630        45 of 96
   2631         0 of 13
   2632        16 of 21
   2633        17 of 61
   2634         0 of 81

Jim asked for others to submit input to him at [email-masked].

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

CERTDIST Draft Discussion - Jim Schaad

Jim discussed the Certificate Distribution Specification I-D 
<draft-ietf-smime-certdist-05.txt>, May 2000.  Based on discussions 
on the S/MIME WG mail list, Jim stated that there are three camps 
of thought regarding publishing certificates with secondary support
information such as the SMIMECapabilities attribute:
1) Use attribute certificates (AC)
2) Put user's certificates in the signed object (see certdist-05)
3) Omit user's certificates from the signed object

Jim stated that the advantage of the AC strategy is that it matches 
the X.500 schema.  The disadvantage is that ACs are "new" and are
not necessarily a good use of ACs.

Jim stated that the advantage of the strategy to include user 
certificates in the signed object is that there is a single location
from which to retrieve all of the required information.  The 
disadvantages of this strategy are that duplicate information is 
stored in the directory and there are potential consistency problems.

Jim stated that the advantages of the strategy to omit user 
certificates in the signed object are less data stored in the
directory and a single set of user certificates are used for all 
purposes.  The disadvantages of this strategy are that there are 
potential consistency problems and multiple elements to be retrieved
from the directory.

Jim conducted a straw poll of the meeting attendees to obtain their
opinion regarding the following options: 
1) Continue to try and get consensus
2) Adopt on standards track w/o consensus
3) Adopt on experimental track w/o consensus
The majority of the meeting attendees who voted chose option 1.

Blake Ramsdell asked if these issues should be discussed on the IETF 
PKIX WG mail list in addition to the S/MIME WG mail list.  Russ 
stated his belief that the interested parties are subscribed to the
S/MIME mail list so it is not necessary to discuss the issues on the
PKIX mail list.

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

Symmetric Key Distribution - Jim Schaad for Sean Turner

Jim discussed the S/MIME Symmetric Key Distribution I-D, 
<draft-ietf-smime-symkeydist-01.txt>, July 2000.  Jim provided 
significant comments to the symkeydist-00 I-D that Sean incorporated
into the symkeydist-01 I-D.

Jim stated that major architecture changes were made to the symmetric
key distribution strategy.  The Key Management Agent (KMA) and Group 
Management Agent (GMA) were combined into one component called the 
Group Lists Agent (GLA).  This change removes duplicative KMA checks.
The change was made based on the assumption that the KMA and GMA 
will likely be implemented in the same box.  

Jim briefed that major protocol changes were made to the symmetric
key distribution strategy.  Instead of defining a new content type,
symkeydist-01 specifies that the exchange of data will use a protocol
based on RFC 2797, Certificate Management Messages over CMS (CMC).

There were many other changes made to the document as a result of 
changing the architecture and protocols.

Jim briefed the following implementation requirements for the 
control attributes:

Implementation	
 Requirement    Control Attribute
==================================
	MAY		glUseKEK
	MAY		glDelete
	MAY		glAddMembers
	MAY		glDeleteMembers
	MAY		glRekey 
	MAY		glAddOwners
	MAY		glRemoveOwners
	MAY		glkCompromise
	SHOULD	glkRefresh
	MAY		glSuccessInfo
	MAY		glFailInfo
	MAY		glAQueryRequest
	MAY		glAQueryResponse
	MUST		glKey

Jim noted that the protocol exchanges between the user and GLA will
be changed to "MUST implement" requirements.  He also noted that 
the protocol exchanges between the KMA and GLA will remain as
"MUST implement" requirements.  

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

Mapping Company Classification Policy to the S/MIME Security Label - 
Weston Nicolls

The "Implementing Company Classification Policy with the S/MIME 
Security Label" I-D, <draft-ietf-smime-seclabel-01.txt>, July 2000,
was authored by Weston Nicolls.  Weston planned to provide a briefing
at the meeting, but could not be present due to airline delays. 
There was no information presented regarding this topic.

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

Message Compression - Ned Freed

Ned Freed is proposing a MIME encoding to handle compression.  His
proposal is to compress the message using this MIME encoding before 
it is signed or encrypted.  Ned Freed could not be present at this
meeting, so there was no information presented regarding this topic.

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

DOMSEC Draft Discussion - Bill Ottaway

Bill presented a briefing regarding the "Domain Security Services Using
S/MIME" I-D <draft-ietf-smime-domsec-06.txt>, July 2000.  Bill stated 
that there have been two releases of the DOMSEC I-D since the last 
S/MIME WG meeting.  DOMSEC-05 included clarifications based on input
from Luis Barriga and included the object identifier for the 
signatureType attribute.  DOMSEC-06 included corrections and 
clarifications based on input from Jim Schaad, and included an ASN.1
module added.  

Bill then discussed some issues with some technical proposals from
Jim Schaad.  In an e-mail message, Jim Schaad stated: "Section 3.0
bullet 1: This concept bothers me. I think that there may be some 
programs out there that assume at least one signature in a signed 
data object except for cases such as degenerate certs only messages."
Blake Ramsdell reiterated that some applications interpret
a signedData with no signerInfos as being a certs-only message.
Bill's position is that CMS (section 5.1) states that there may be
zero signerInfos, so compliant implementations should be able to 
process a signedData with zero signerInfos.  He asked if any of the
other meeting attendees believed that DOMSEC should be changed to
omit the use of signedData objects without any signerInfos.  None
of the meeting attendees responded.

In an e-mail message, Jim Schaad also stated: "Section 4 Paragraph
Last-2 - How can I possibly enforce this?  For Key Transport the 
sender is anonymous, for Key Agreement the senders certificate is
often not examined.  Additionally the domain component could change
so that does match -- or it might be my domain component that did 
the re-enecryption and would therefore match my domain name and not
the senders domain name."  Bill's position is: "The only extra 
specification to those specified in CMS is that the naming 
convention and name mapping convention defined in DOMSEC is used.
This is specified to locate public keys. For example, if a domain
needs to locate the public key for the domain of the recipient 
[email-masked] then the public key belonging to
[email-masked] needs to be 
located, or if not present the public key of an ascendant of the 
domain name needs to be located."  Bill also stated that the 
DOMSEC messages are encrypted between the originator's domain 
and the recipient's domain, not the actual recipient user.  
He stated that the text is intended to explain how an 
originator domain agent can look up a recipient's name. 
He will clarify the text.
Bill stated that the he believes that the outstanding issues
should be resolved and then the DOMSEC I-D should be submitted 
for last call.

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

RSA As a Must Implement - Blake Ramsdell

Blake Ramsdell proposed that RFC 2630 be changed to require the
RSA public key algorithm as the "MUST implement" key management
algorithm since the RSA patent will expire on 20 September 2000.
He also raised the question of changing RFC 2630 to require the
RSA public key algorithm as the "MUST implement" signature algorithm.

John Pawling asked if anybody had applied for any patents related
to the RSA public key algorithm.  Russ Housley stated that was a
possibility, since patent filings are confidential until they are
published.  He noted as an example that an organization applied
for a patent regarding the methods for avoiding the "small-
subgroup" attacks on the Diffie-Hellman (D-H) key agreement method.
He stated that nobody had made any statements to him regarding any
patents related to the RSA public key algorithm.  John Linn stated
that RSA is not applying for any patents (that he knows of) related
to the RSA public key algorithm.

Pat Cain stated that he was concerned that this significant change 
would slow down the process of advancing the S/MIME v3 RFCs from
Internet Proposed Standards to Internet Draft Standards.  Jim Schaad
replied that this change would not slow down the process of 
implementing the S/MIME v3 standards.  Russ Housley stated that the
changes probably would reset the clock for advancing the S/MIME v3 
RFCs from Internet Proposed Standards to Internet Draft Standards.  

An attendee pointed out that PKCS #1 is not fully tested.  Another
attendee stated that the group needs to consider the quality of the
cryptographic algorithms in addition to patent concerns.

Jim Schaad stated that he believes that DSA should remain a "MUST
implement" signature algorithm because the signature value requires
less bytes, and because it is widely implemented and required.

Russ Housley stated that the RFC 2630 Security Considerations 
section recommends that the PKCS #1 v2.0 Optimal Asymmetric 
Encryption Padding (RSA with OAEP) technique should be employed
instead of the PKCS#1 v1.5 RSA key management algorithm.  Therefore,
if Ephemeral-Static Diffie-Hellman is no longer going to be the 
mandatory-to-implement algorithm, then he recommends the use of
RSA with OAEP as its replacement.

Jim Schaad asked if separating the algorithms-related text from RFC
2630 would mandate a new six-month waiting period.  Russ replied that
he did not believe that change alone mandated a new six-month 
waiting period because it does not impact the RFC 2630 core 
requirements.

Phillip Hallam-Baker stated his belief that the "S/MIME v3" mark 
on a product means that it is interoperable with all S/MIME
implementations, so he supports RSA with OAEP rather than D-H.

An attendee asked if RSA with OAEP breaks backward compatibility
with S/MIME products that implement PKCS#1 v1.5 RSA.  Russ
replied that it does break backward compatibility.

Blake Ramsdell pointed out that using RSA with OAEP was a better
option than using Ephemeral-Static (E-S) D-H because the same RSA
certificates can be used with both PKCS#1 v1.5 RSA and RSA with
OAEP.

Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the following options for the "mandatory-
to-implement" key management algorithm: 
1) PKCS#1 v1.5 RSA
2) RSA with OAEP 
3) E-S D-H
The majority of the meeting attendees who voted chose option 1,

An attendee asked if anybody had submitted any patents regarding
RSA with OAEP.  Russ replied that the OAEP authors told him that
they have not submitted any patents relating to OAEP.

Dave Solo asked if the group could discuss separate sign and 
verify "mandatory-to-implement" signature algorithm requirements.
Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding Dave's request.  The majority of the
meeting attendees who voted indicated that there should not be
separate sign and verify "mandatory-to-implement" signature 
algorithm requirements.

Russ conducted a straw poll of the meeting attendees to obtain 
their opinion regarding the following options for the "mandatory-
to-implement" signature algorithm: 
1) PKCS#1 v1.5 RSA 
2) DSA
3) Both
The majority of the meeting attendees who voted chose "Both".

Russ stated that he would submit these proposals to the S/MIME WG 
mail list.  He noted that the earliest that the changes could be 
made would be September 2000.

An attendee asked how many organizations have implemented OAEP.
Russ replied that he did not know of any S/MIME implementations
that include OAEP.

An attendee stated that vendors are required to use NIST-approved
algorithms for federal procurement efforts.  Russ stated that 
both X9.42 D-H and X9.44 RSA are NIST-approved.

Russ noted that the NIST AES winner is supposed to be announced
in September 2000.  He suggested that the group should discuss 
whether AES should be the mandatory-to-implement symmetric 
encryption algorithm instead of Triple-DES.  Dave Solo noted 
that AES is still theoretical.  

Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the following options for the "mandatory-
to-implement" symmetric encryption algorithm: 
1) Triple-DES 
2) AES
The vote was evenly split between the two options.

Pat Cain recommended that the S/MIME v3 standards should continue
to mandate Triple-DES for the immediate future, but that the group
could consider AES later.

Phillip Hallam-Baker suggested that the S/MIME v3 standards could
mandate both Triple-DES and AES.

Carlisle Adams stated his belief that AES must be the "mandatory-
to-implement" symmetric encryption algorithm.  Pat Cain replied 
that AES may not be implemented until the end of next year.  Jim
Schaad noted that RSA with OAEP also delays implementation. 

A meeting attendee stated that the AES has not been published yet,
but Carlisle Adams replied that the five AES candidates are 
well-known.  The implication being that people could begin 
implementing the five AES candidates now. 

Russ re-iterated that he would submit these proposals to the
S/MIME WG mail list.  

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

Examples of S/MIME Messages - Paul Hoffman

Paul Hoffman planned to participate in the meeting, but could not
be present because he was required to attend another meeting at
the same time as the S/MIME WG meeting. 

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

Electronic Signature Formats - John Ross

John briefed regarding the "Electronic Signature Formats for long term
electronic signatures" I-D, <draft-ietf-smime-esformats-01.txt>, July
2000.  The esformats-01 I-D is based on the ETSI Electronic Signature 
Infrastructure Standardisation.

John briefed that the esformats-00 I-D was split into two documents.
One covers Electronic Signature Formats and is proposed to be an 
informational RFC.  The other covers Signature Policy and is proposed
to be an experimental RFC.

John briefed that esformats-01 uses the following RFCs: 
-RFC 2630 Cryptographic Message Syntax (CMS)
-RFC 2459 PKIX Certificate and CRL Profile
-RFC (to be published) PKIX Timestamping protocol
-RFC on "Attribute Certificates".

He summarized that the esformats-01 I-D defines a process to
provide proof of validity of a signature to be used if 
repudiation is attempted.

John stated that the contents of the esformats-01 I-D is technically
equivalent to the ETSI ES 201 733 V.1.1 document.  ETSI owns the
Copyright (C) on this document.  John stated that individual copies
of the document can be downloaded from <http://www.etsi.org>.  He
noted that these are two new ETSI work items: long term Electronic 
Signature Formats that do not mandate timestamping and long term 
Electronic Signature Formats based on XML signatures syntax.

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

Signature Policy Format - Denis Pinkas

Denis briefed regarding the "Electronic Signature Policies" I-D,
<draft-ietf-smime-espolicies-00.txt>.  Denis briefed that the 

contents of the I-D is based on the signature policy defined in the
ETSI ES 201 733 V.1.1.3(2000-05) document.  ETSI owns the
Copyright (C) on this document.  Denis stated that the
I-D defines signature policies for electronic signatures. He defined
signature policy as a set of rules for the creation and validation 
of an electronic signature, under which the validity of signature can
be determined. He noted that a given legal/contractual context may
recognize a particular signature policy as meeting its requirements.
He stated that a signature policy has a globally unique reference, 
which is bound to an electronic signature by the signer as part of 
the signature calculation.  He said that the signature policy needs
to be available in human readable form so that it can be assessed 
to meet the requirements of the legal and contractual context in 
which it is being applied.  He briefed that to allow for the 
automatic processing of an electronic signature another part of the
signature policy specifies the electronic rules for the creation 
and validation of the electronic signature in a computer processable
form.  He noted that the current document defines the format of the
signature policy using ASN.1 and briefed the proposed syntax.  

Denis concluded with the statement that work on section 5 of the ID
continues 

to define the Conformance Requirements including:
5.1  Signature Policy definition -  Any signature policy issued by 
     a Signature Policy Issuer SHALL include ...
5.2  For signer systems - Signer systems MUST be able to process an
     electronic signature defined in accordance with [ES-FORMATS] 
     against the signer rules of a signature policy defined in 
     accordance with ...
5.3  For verifier systems - Verifier systems MUST be able to process 
     an electronic signature defined in accordance with [ES-FORMATS] 
     against the verifier rules of a signature policy defined in 
     accordance with ...

An attendee asked if there was an issue regarding the occurrence of
one or more time stamps associated with the signature.  Denis 
responded that the signature policy may mandate a single or 
multiple TSAs.  For example, separate TSAs may be specified for the
sender and recipient.

Carlisle Adams asked about the timeframe for ETSI.  Denis replied 
that the ASN.1 for the signature format is stable, but the signature
policy ASN.1 syntax is still being actively discussed.  He believes
that there will be a stable signature policy document by the end of
the year.  

John Ross invited comments to both documents.  

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

Wrap Up - Russ Housley

Russ asked if there were any other issues to discuss.  The meeting
attendees were silent.

Meeting adjourned.