8 August 2001 S/MIME WG Minutes

[Paul Hoffman / IMC <[e-mail]>]

[[Forwarded for Rich Nicholas, the proficient minutes-taker.]]

This message includes the official minutes of the IETF S/MIME Working
Group (WG) meeting held on 8 August 2001 in London, England.  Briefing
slides will be available from <ftp://ftp.ietf.org/ietf/smime/>.  The
briefing presenters have reviewed these minutes.  Reported by Rich
Nicholas.

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

Introductions - Russ Housley

Russ welcomed the attendees and presented the working group's agenda as
follows.

Introductions                       Russ Housley
Working Group Status                Russ Housley
Interoperability Matrix             Jim Schaad
CMS and ESS Examples                Paul Hoffman
Updates to CMS                      Russ Housley
Updates to CERT & MSG               Blake Ramsdell
Symmetric Key Distribution          Sean Turner
X.400 and CMS                       Chris Bonatti
Reuse of Content Encryption Keys    Steve Farrell
AES and RSA-OAEP                    Jim Schaad
Elliptic Curve Crypto               Simon Blake-Wilson
S/MIME Gateway Protocol             Blake Ramsdell
NIST S/MIME Activities              Mike Chernick
XML Electronic Signature Syntax     Denis Pinkas
CSP and Time Stamps                 Denis Pinkas
S/MIME Freeware Library             Rich Nicholas
Wrap up                             Russ Housley

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

S/MIME Working Group Status - Russ Housley

Russ listed the RFCs generated by the S/MIME WG:
RFC 2630 Cryptographic Message Syntax (CMS), 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]
RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS, C. Adams,
	      October 2000.
RFC 3058 Use of the IDEA Encryption Algorithm in CMS, S. Teiwes,
             P. Hartmann, and D. Kuenzi, February 2001.  [Informational]

In addition to the RFCs, the following three documents are in the RFC
Editor's queue:
esformats   Electronic Signature Formats for long term electronic
  		signatures.  D. Pinkas, J. Ross, and N. Pope.
espolicies  Electronic Signature Policies.  J. Ross and N. Pope.
seclabel    Implementing Company Classification Policy
  		with the S/MIME Security Label.  W. Nicolls.

The seclabel document is on hold in the editor's queue pending the PKIX
Attribute Certificate Profile, so the seclabel document can cite it as
a reference.  The PKIX Attribute Certificate Profile was recently sent
to the RFC editor.

Russ outlined the requirements for advancing the standards track RFCs
from Proposed Standards 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
<draft-ietf-pkix-new-part1-08.txt> progresses to Draft Standard.
Son-of-RFC 2459 is presently with the Security Area Director, awaiting
IETF Last Call.

Regarding requirement #3, Jim Schaad has developed an interoperability
matrix for CMS, Diffie-Hellman, MSG, CERT, and ESS documents.  The
interoperability matrix is posted on the IMC web site at the following
URL:  <http://www.imc.org/ietf-smime/interop-matrix.html>.  Paul Hoffman
offered to coordinate interoperability testing and compile CMS and ESS
Examples document.

Blake Ramsdell noted that the Examples of S/MIME Messages Internet-Draft
is a very large document and asked if there is a precedent for such a
large document.  Paul Hoffman answered that there are larger RFCs, but
there is no document that he has ever found like the examples document.
Blake restated his question as are we approaching it the right way, is
there a protocol that has been profiled as extensively as this?  Paul
answered that no, not that he's aware of.

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

Interoperability Matrix - Jim Schaad

Jim briefed on the status of the interoperability matrix.  The matrix
was updated to reflect the new CMS and CMS Algorithms Internet-Drafts.
CMS now has 96 MUST statements and 79 optional requirements or
"features."  Of those requirements, implementations have demonstrated
interoperability of 56% of the MUST statements and 48% of the features.
In the CMS Algorithms draft, there are now 46 MUST statements and 15
optional features.  Of those, interoperability has been successfully
demonstrated with 93% of the MUST statements and 93% of the optional
features.
For the other unchanged specifications:
RFC 2631, Diffie-Hellman, only 1 of the 13 requirements has passed
interoperability testing.
RFC 2632, CERT, 16 of the 21 requirements have passed.
RFC 2633, MSG, 17 of the 61 requirements have passed.
RFC 2634, ESS, 27 of the 81 requirements have passed.

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

CMS and ESS Examples - Paul Hoffman

Paul briefly discussed status of the "Examples of S/MIME Messages"
Internet-Draft <draft-ietf-smime-examples-06.txt>, 25 February 2001.
Paul stated that an updated draft was not posted prior to the Internet
Draft cut-off due to time constraints.  An updated version of the
document is forthcoming that includes changes that have been discussed
on the ietf-smime-examples mail list.  Only John Pawling and Jim Schaad
have provided active input on the examples.  Paul knows there are many
more S/MIME implementations out there and requests the other S/MIME
implementers provide feedback as to whether their software can
process the examples, both positive or negative.  The feedback can
either be public on the ietf-smime-examples mail list or privately to
Paul.

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

Updates to CMS - Russ Housley

Russ presented the status of CMS.  CMS is being split into two
documents, with the algorithms being moved into a separate document.
The proposed revision to CMS, <draft-ietf-smime-rfc2630bis-01.txt>, has
been discussed on the mail list.  A new draft will be forthcoming once
the two remaining issues have been resolved.  The CMS Algorithms draft,
<draft-ietf-smime-cmsalg-01.txt>, has been discussed on the mail list as
well.  A new draft will be released when the RFC2630bis open issues are
addressed.  Russ hopes that these issues will be resolved during this
meeting.

The two remaining open issues are:
1.  Should CMS specify any mandatory to implement algorithms?
2.  Are version numbers handled correctly?

Regarding issue #1, a protocol cannot say:
"Implementations of the CMS MUST support the mandatory to implement
algorithms specified in [CMSALG], or its successor."  There are two
possible alternative remedies:  either preserve the MUST and SHOULD
statements for algorithms in CMS, or remove the algorithm-specific
requirements from CMS.  Russ presented the pros and cons of both
alternatives.  Requiring mandatory to implement algorithms ensures that
protocols that employ CMS can inherit the algorithms from CMS without
further specification.  Removal of mandatory to implement algorithms
makes the CMS protocol stable, but places the burden of algorithm
specification on protocols that employ CMS.  Russ noted that this second
alternative is similar to the PKIX Certificate and CRL Profile and that
RFC 2633 already includes necessary statements for S/MIME.  Russ noted
that this issue has been discussed on the mail list, but only a few
people have expressed an opinion.

Paul Hoffman stated this is mostly a political issue, not a technical
one, so he hasn't expressed an opinion.  Another working group member
noted that protocol implementers and users typically have different
agendas and users of CMS implementations might feel more strongly about
the need to require specific algorithms to promote interoperability.

Russ polled the working group members as to which alternative they
preferred.  The majority preferred the second alternative to require no
mandatory algorithms in CMS.

Russ then presented the following example to illustrate issue #2:
Current EnvelopedData version processing:
      IF ((originatorInfo is present) AND
           (any version 2 attribute certificates are present)) OR
           (any RecipientInfo structures include pwri) OR
           (any RecipientInfo structures include ori)
      THEN version is 3
      ELSE
           IF (originatorInfo is present) OR
                (unprotectedAttrs is present) OR
                (any RecipientInfo structures are a version other than 0)
           THEN version is 2
           ELSE version is 0

Currently, the version number in a complex structure like EnvelopedData
is set to ensure that all subordinate components can be decoded in a
single pass.  The outer version number indicates to the application if
it can decode all of the inner subcomponents.  The alternative is to let
the version number in each subordinate component handle changes within
that component.  Based on discussions on the list, many implementations
are not prepared for decode errors after the higher-level version check.

Jim Schaad noted that based on discussions on the list, Peter Gutmann's
implementation is the only one to check the EnvelopedData version prior
to decoding.  Most other implementations attempt to decode the entire
structure and only check the version number if a decode error occurs.
Other working group members noted that whether an implementation
encounters an error decoding the EnvelopedData or checks the version
number prior to decoding, the result is the same.  The version number at
least gives information as to the cause of the decode error which is
useful for debugging.

Russ polled the working group members as to which alternative they
preferred.  Only a few members expressed a preference, so Russ left the
issue open.

Blake Ramsdell noted that there are quite a lot of optional features in
CMS.  He asked whether those optional features could be moved from the
base CMS document into a third CMS protocol document.  The consensus was
that it was not worth doing that at this time, but could be done at the
next level (when the documents go from proposed standards to draft
standards).

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

Updates to CERT & MSG - Blake Ramsdell

Blake briefed the status of the updates to RFCs 2633 and 2632.  Blake
noted that new versions of both RFCs are forthcoming and outlined the
changes.
Changes to RFC 2633 (MSG):
      RFC 2633                    2633bis
      MUST DSA                    Receiver MUST DSA and RSA
      SHOULD RSA                  Sender MUST DSA or RSA

      MUST DH                     SHOULD DH
      SHOULD RSA                  MUST RSA

      Individual alg specs        CMS Alg

Changes to RFC 2632 (CERT):
      RFC 2632                    2632bis
      MUST DSA                    MUST DSA
      SHOULD SHA1 w/RSA           MUST SHA1 w/RSA
      SHOULD MD2/MD5 w/RSA        MAY MD2/MD5 w/RSA

Jim Schaad asked if the requirement for MD2 could be eliminated.  Paul
Hoffman suggested that the MD5 requirement should be changed to SHOULD
rather than MAY, but that MD2 could be left as a MAY, or dumped.

A question was asked whether the MUST DSA statement in 2632bis required
applications to implement DSA or rather, only if the application
implements DSA, that it be implemented in accordance with CMS Alg.  The
member was particularly concerned about constrained mobile devices not
being able to implement DSA.  The answer from Blake, and seconded by
Russ, was that at a previous working group meeting it was decided that
compliant applications must be capable of verifying signatures signed
using both algorithms.

Jim asked if 2632bis should reference the PKIX algorithms Internet-Draft
or CMS Alg?  Blake answered that it will be changed to refer to the PKIX
algorithms document.

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

Symmetric Key Distribution - Sean Turner

Sean briefed the status of the S/MIME Symmetric Key Distribution
Internet-Draft, <draft-ietf-smime-symkeydist-05.txt>.  Working group
Last Call was issued on 1 May 2001.  No comments were received on the
list, some comments were sent directly to Sean.  Almost all of the
comments received were editorial.  Based on the comments, the following
changes were made:
- Moved section "Using the Group Key" (section 8) to section 1.3
- Clarified language for the conformance table in section 3.1
- Restricted Attribute Certificates to be version 2
- Made SKDAlgRequest syntax NULL
- Added information pointing out that there are multiple ways to wrap
   SignedData or EnvelopedData (to MIME wrap or not)
- Modified wording in section 4
- Copied wording from CMS Algs about symmetric key generation
- Expanded wording in Security Considerations

One of the suggestions was to change the name.  Sean suggested "CMS
Symmetric Key Management and Distribution."  No one objected to the
name change.

Sean asked whether the document needed to recycle through working group
Last Call.  Russ answered no; it is ready to go forward to the Area
Directors.

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

X.400 and CMS - Chris Bonatti

Chris presented the status of the CMS X.400 Internet-Drafts.  New
versions of both "Securing X.400 Content with S/MIME",
<draft-ietf-smime-x400wrap-03.txt>, and "Transporting S/MIME Objects in
X.400," <draft-ietf-smime-x400transport-03.txt> were distributed on
19 July 2001.

The x400wrap document specifies how to protect X.400 content with CMS
objects.  It is roughly analogous to RFC 2633 (MSG).  The changes
incorporated into the -03 version include:
- Altered the requirements for CMS options (2.2 and 2.3) to align with
   the mandatory algorithms agreed for the Draft Standard work.
- Deleted from section 2.3 the statement that:  The size of the private
   key is determined during key generation.  This statement is algorithm
   specific and not pertinent to the topic at hand.  The same comment may
   be raised against 2633bis.
- Clause 2.4.2 was updated to clarify the requirement in terms of
   MAY/SHOULD/MUST.  The same comment may be raised against 2633bis.
- Text of 3.2 through 3.4 to remove intervening layers ContentInfo
   wrappers.
- Revised text of 3.2.1, 3.3.1, and 3.4.1 to reflect correct values of
   smime-type parameters as per the discussion on the mailing list.

A single editorial bug is known to exist in the -03 version:  The second
paragraph 3.2.1 needs to be updated to specify the smime-type parameter
be set to "signed-x400" instead of "signed-data."  This typo is minor
has been discussed on the list.

The x400transport document specifies how to package CMS objects for
transport by X.400 Message Transfer Agents (MTAs).  It is separate from
the X.400 wrapping draft to encourage use of RFC 822/MIME content in
X.400 communities.  The changes incorporated into the -03 version
include:
- Clarified and corrected text of 2.3 describing how to forward CMS
   objects in X.420 IPMS messages.
- Assigned OID values for EITs in section 2.5.
- New text was added in section 2.6 to address use of X.400 EoS that may
   have impact on use of CMS security.
   -- MTS Conversion Services:  Does not apply to CMS content, but could
      result in destruction of the message or breaking the signature
      function.  Conversion Prohibition EoS SHOULD be selected.
   -- Message Redirection Services:  The enveloped-data type requires an
      instance of RecipientInfo for each intended recipient or alternate
      recipient.  Some types of redirection are not subject to originator
      control.  If ORAR is used, an appropriate RecipientInfo element
      SHOULD be generated.
   -- DL Expansion:  The enveloped-data type requires processing by a
      secure mail list expander as described in ESS.  When transporting
      CMS objects within an X.400 environment, the DL Expansion
      Prohibited service SHOULD be selected.

Chris believes both documents are ready for working group Last Call.
Russ agreed to initiate working group Last Call once the typo is fixed
in the X400wrap document.

Jim Schaad commented that a couple of small issues remain in both
documents.  Paul Hoffman believes these new issues need to be resolved,
incorporated into new versions of the documents, and then sent to the
mail list.

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

AES and RSA-OAEP in CMS - Jim Schaad

Jim presented a briefing on the updates to the "Use of the AES
Encryption Algorithm and RSA-OAEP Key Transport in CMS" Internet-Draft,
<draft-ietf-smime-aes-alg-02.txt>.  The new draft includes the
following changes:
- Removed the AuthenticatedData section.  Since RSA is a key transport
   mechanism, there was no way to authenticate who sent the key.
- Added an AES overview.
- Added place holder examples for the key wrap algorithm -- awaiting
   Object Identifiers from NIST.
- Added AES EncryptedData section.

Jim listed the following work items as things left to be done:
- Get key wrap algorithm OID assigned by NIST
- Once done, complete AES key wrap examples
- Add ASN.1 appendix to define a couple of ASN.1 items that RFC 2437
   omits.
- Resolve password recipient info key wrap issues

Other algorithms that may be added to the document at a later date
include the RSA Probabilistic Signature Scheme (PSS) algorithm and the
SHA-2 hash algorithm.  The specification of the PSS algorithm has not
progressed, and its OID and definitions are still unspecified.  The
SHA-2 algorithm details for use with DSA have not been released by NIST
at this time.  Use of SHA-2 with RSA is awaiting specification of the
PSS algorithm.

Blake asked when would the working group know anything about SHA-2?
Jim answered that the issue was brought up with RSA at the last working
group and nothing has been done since.  Russ commented that PSS is still
being coordinated with the various communities that will use it.  Russ
was asked if PSS will be specified in a PKCS document and he answered
that yes it would.

A comment was made that the SHA-2 draft has been out for a long time.
Jim clarified that the question was when will the DSA key sizes and OIDs
for DSA with SHA-2 be known.  Mike Chernick noted that NIST completed
the specification of SHA-256, but he didn't know when the DSA
specification would be updated.

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

Elliptic Curve Cryptography - Simon Blake-Wilson

Simon presented a brief synopsis of the state of the "Use of ECC
Algorithms in CMS" Internet-Draft, <draft-ietf-smime-ecc-06.txt>,
7 May 2001.  The document has completed both working group Last Call
and IETF Last Call.

Russ took an action to follow up with the Area Directors on this
document and the others (rcek and domsec) that are awaiting the ADs
attention.

Simon noted that three independent implementers have conducted
interoperability testing.  Simon is currently working on an examples
draft.

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

S/MIME Gateway Protocol - Blake Ramsdell

Blake briefed the working group on the "S/MIME Gateway Protocol",
Internet-Draft, <draft-ramsdell-enc-smime-gateway-00.txt>,
12 July 2001.  The protocol specifies how to use S/MIME to perform
server-to-server (gateway) encryption between cooperating domains.  The
Massachusetts Health Data Consortium led the development of the
protocol and its prototyping in order to comply with the United States
Health Information Protection Act (HIPA).  Six S/MIME server vendors,
Tumbleweed, Baltimore Technologies, DICA, Vanguard, Tenfour, and VIASEC
participated in the effort.  Deloitte & Touche conducted an independent
interoperability test and evaluation of the vendor products.

Blake asked the working group what should be done with the
specification.  Currently it is an independent Internet-Draft under his
name.  Should it be a working group work item?  Should it be considered
a profile of DOMSEC?

Russ asked the working group members, who read the document?  Only a
couple of members had read it.  Paul Hoffman commented that this
document is an important document since it increases the use of S/MIME,
but without having to burden users with the details and complexity.
Paul recommends that all working group members read the document and
encourage similar use of S/MIME wherever possible.

A comment was made that if this document is to be made a working group
work item that it should be aligned with DOMSEC.  Also, if encryption is
the only service provided by this solution, isn't this solution
vulnerable to a man-in-the-middle attack?  Blake responded by noting
that the key management for this solution is handled outside the
document.

The same individual asked Paul why SMTP over TLS was not considered.
Paul answered that SMTP/TLS is ok, but it's point-to-point, so if
multiple SMTP hops are involved, each hop would require a separate TLS
session.  In general, Paul felt that S/MIME implementations are more
widely available then implementations of SMTP over TLS.

A comment was made that the man-in-the-middle attack mentioned earlier
isn't an issue since the To addressee's domain is used to find the
correct certificate for the intended recipient.

Russ asked if Bill Ottaway had looked at DOMSEC in comparison with
Blake's document.  Bill had not.  Russ requested Bill post a comparison
to the list and the working group can go from there.

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

NIST S/MIME Activities - Mike Chernick

Mike briefed the working group on the current S/MIME activities at the
U.S. National Institute of Standards and Technology (NIST).  Mike
described the mission of his group as "to accelerate deployment of
secure interoperable S/MIME products."  They are currently working on
three major projects:  an in-house laboratory, the S/MIME v3 client
profile, and an internet-based S/MIME test facility.

The first purpose of the S/MIME v3 profile is to identify the subset of
S/MIME v3 specifications that helps to assure interoperability,
promotes secure communications at reasonable cost, and serves as a
basis for test development.  The second purpose of the profile is to
serve as guidance for COTS product procurement and development.  The
profile is relatively short (17 pages) and is currently out for public
comment until mid-September 2001.  The profile is available at the
following URL:
http://csrc.ncsl.nist.gov/pki/smime/draft_SMIMEProfile.pdf

The profile specifies the mandatory parts of RFCs 2630, 2632, and 2633,
except Diffie-Hellman key agreement not required.  The mandatory CMS
algorithms are required, plus the profile requires support for both RSA
(V1.5, RFC 2313) and DSA (FIPS 186-2) digital signatures.  Key sizes of
at least 1024 bits for RSA and DSA are required.  Use of Diffie-Hellman
keys and derivation of KEKs as defined in RFC 2631 is encouraged but
NOT required.

The profile requires selected features from RFC 2634, Enhanced Security
Services, including Signed Receipts processing:  request (non-third
party) signed receipt, generate signed receipt upon request, and match
signed receipt to original message.  The profile also requires that the
mlExpansionHistory attribute MUST be processed.

The profile has the following message generation requirements:
- Send "clear" signed messages that include generation of SignerInfo,
   SMIMECapabilities Attribute, and sending of user certs and CRLs
- Send encrypted message
- Send signed and encrypted messages
- Send to multiple recipients
The profile requires clients to support receiving and processing both
"clear" and "opaque" signed messages and receiving and decrypting
messages sent to multiple recipients.

The profile requires implementations to construct certification paths
between accepted trust points and the sender's or intended recipient's
certificates.  Tests will include paths with multiple CA certificates.
Testing will require use of LDAP and the processing of the standard
directory attributes (RFC 2587).  The profile requires that client
perform path validation in accordance with RFC 2459, Section 6.

Mike was asked if the profile will be changed to require son-of-RFC2459,
rather than RFC 2459.  Mike answered yes.  In general, the profile will
be updated to require the latest version of the various specifications,
as practical.

The automated S/MIME test facility is currently being developed by NIST
using the Getronics S/MIME Freeware Library (SFL) as reference
implementation.  The test facility will test scenarios to cover S/MIME
v3 profile requirements and options, but NOT out-of-scope S/MIME
features.  The test facility will ensure conformance of vendor
implementations to S/MIME v3 client profile.  Information and
instructions will be available over the web; SMTP will be used for
testing.  The automated test facility will support both originator and
recipient roles, but will require "human scoring" and self-scoring for
some tests.  The automated test facility will help identify ambiguities
and errors in IETF specifications, the NIST profile, and the SFL
reference code.

Some notes about the automated S/MIME test facility are:
- Objective testing wherever possible
- Anonymous testing possible
- Results only to remote tester
- All required communications through e-mail
- Not publishing remote tester's certificates and CRLs
- Using test policy OIDs

Mike also presented the test facility architecture and walked through
several sample scenarios.

More information about the NIST S/MIME group can be found on their web
site: http://csrc.nist.gov/pki/smime

Mike was asked if people outside the United States will be able to use
the automated test facility, and answered yes.
Blake Ramsdell asked if successful tests would be published.  Mike
answered that test results may possibly be published.
Blake asked if the purpose of this testing is to test and certify S/MIME
products for the U.S. government, in addition to FIPS 140?  Mike
answered that the purpose of this testing is to encourage interoperable
implementations, and is much more informal than FIPS 140.
Blake asked for clarification if there will be a requirement for U.S.
government agencies to only use products that pass the NIST S/MIME
testing.  Mike answered certainly not at this point -- that is not their
intention.

Simon asked how the algorithm recommendations in the S/MIME v3 profile
relate to FIPS 186?  Mike answered that the algorithms are aligned with
FIPS 186.  Tim Polk seconded that answer and noted that the profile
allows optional algorithms such as AES, to position the profile for the
future.

Russ asked if a U.S. federal agency could require, in a procurement
document, S/MIME implementations that pass this testing.  Tim clarified
that an agency could require S/MIME implementations that match the
profile.  Tim suggested that one way a vendor could demonstrate profile
compliance would be to pass the conformance tests.  Tim stated that NIST
will not perform any product testing nor certify any results.

As a follow-up, Simon asked if there will be a FIPS 186-3, that permits
PKCS v1.5?  Tim answered yes.  Simon also asked if we can make
assumptions about what the FIPS on key management is going to say?  Tim
answered no, key management is much earlier in its evolution, and is
subject to change.

A comment was made that this testing seems to be geared to vendors
performing vendor testing.  Publishing results would be useful to users.

Paul commented that publishing results while useful, can be dangerous
due to misleading information being provided.  He recommends general
comments be published rather than specific product results.  Mike agreed
that NIST won't publish specific results, only statistical summaries.

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

Reuse of Content Encryption Keys - Steve Farrell

Steve briefed the status of the "Reuse of CMS Content Encryption Keys"
Internet-Draft, <draft-ietf-smime-rcek-04.txt>, 28 May 2001.  Steve
noted that there is no status to report -- the working group has
finished with it.  IETF Last Call was completed on 23 June 2001 and the
document is with the Area Directors.

Russ took an action to check with the ADs to determine the status of the
document.

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

ETSI ESI Working Group - Denis Pinkas

Denis briefed the working group on several draft European
Telecommunications Standards Institute (ETSI) Electronic Signature &
Infrastructure (ESI) working group documents that are out for public
review and comment.  Comments are requested by September 2001.  The
documents are freely available from: http://www.etsi.org/sec/el-sign.htm

The three draft documents are:
- XML Advanced Electronic Signatures (XAdES)
- Policy Requirements for CAs
- Policy Requirements for Time-Stamping Authorities

The first document, XML Advanced Electronic Signatures, provides, for
XML data, the same functionality as the Electronic Signature format
specification, which uses CMS (i.e. ASN.1), but instead of using CMS
uses the XMLDigSig specification with additions.  In the same way CMS
uses signed attributes and unsigned attributes, XAdES uses
SignedSignatureProperties and UnsignedSignatureProperties.  In addition,
it also uses SignedDataObjectProperties since multiple portions of an
XML document can be globally signed by one signer.  It can be seen as an
"xmlElSign", i.e. an equivalent to CMS in the XML world for signatures
(encryption features are not supported).  The work has been done with
close coordination with W3C.

The second document, Policy Requirements for CAs, is based on TS 101 456
and defines policy requirements for CAs issuing Qualified Certificates
and specifies policy requirements for CAs supporting public key
certificates used to support:
- electronic signatures,
- digital signatures,
- encryption,
- key exchange and
- key agreement mechanisms.
Comments to this document are particularly sought on the following
points:
- A number of requirements have been selected for defining different
   quality levels, where each level should represent a consistent set of
   requirements related to threats and risks involved with the
   environment of the service.  This has critical effects of the
   sensitivity of the service with regard to cost or/and security.
- Are these levels appropriate from a market point of view or would
   other level(s) be more useful?
- Comments based on different business scenarios would help in order to
   address wide segments of practical applications.

The last document, Policy Requirements for Time-Stamping Authorities, is
primarily targeted to support a Time-Stamping Service adequate for
Qualified Signatures, but can also be used in other contexts.  Comments
to this document are particularly sought on the following points:
- One baseline policy has been introduced, however the TSA has the
   possibility to define its own policy by adding enhancements to the
   baseline policy.  How can this be done?
- Naming convention for identifying the TSA.
- Verification of a time-stamp beyond the end of the validity period of
   the certificate of the TSA.

On the last issue, typically two things must be done:
- New TST MUST be applied before the end of the validity period of the
   certificate, so that it can remain valid.
- The CRL (or an OCSP response) from the CA that has issued the TSA
   certificate MUST also be captured, to prove that the time-stamp was
   still valid when the additional TST was applied.

Question:  What if the key is compromised?
Denis:  Certificate will be revoked on CRL, so time stamp applied by
revoked cert will be invalid.

To avoid re-applying a time stamp every time a TSA certificate is due to
expire (for example, five years), this could be avoided if:
- Key generation and public key certification is done correctly,
- The private key is zeroized at the end of the validity period of the
   certificate, and
- No backup of the private key is ever done.
Then:
   The private key is very unlikely to be compromised, even beyond the
   end of the validity period of the certificate of the TSA.

A TST would remain verifiable beyond the end of the validity period of
the certificate of the TSA, if it can be known/proven that:
- the TSA private key has not been compromised at any time during the
   validity period of the certificate, and beyond,
- the hash algorithms used in the TST exhibits no collisions,
- the key size of the signature algorithm under which TST has been
   signed is still beyond the reach of cryptographic attacks (as well as
   the signature algorithm itself).

However, there is no guidance on how these conditions can be met in
practice.  PKIX-1 says:  The certificate validity period is the time
interval during which the CA warrants that it will maintain information
about the status of the certificate.  An extension to the PKIX / X.509
model, might be appropriate, e.g., by mandating the CA to handle the
revocation status of TSA certificates beyond the end of their validity
period.

More specifics on these issues can be found by reading the documents,
which are available at: http://www.etsi.org/sec/el-sign.htm

Question:  Regarding the time stamping authority.  What if cryptography
advances and the algorithms are no longer secure?
Denis:  A second time stamp should have been applied before the
vulnerabilities with the first time stamp algorithms are found or
exploited.

Stefan Santesson:  Why would revocation information need to be
maintained after certificate expiration?
Denis:  Once compromised, time stamps with any dates can be generated
and can no longer be trusted.  Therefore, revocation information must be
published even after expiration.

Comment:  The date when TSA's key was compromised is important.  If a
client verifies a time stamp before the key is compromised, time stamp
could still be considered valid since it was known to be valid prior to
revocation of the TSA's certificate.
Denis:  The client's verification process cannot be trusted by a third
party.  It's better to just apply more than one time stamp, as that is
more secure than relying on a single time stamp.

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

CMS Version Issue Revisited - Russ Housley

Russ decided to revisit the CMS version issue again.  Russ asked the
question differently:

1. Who objects to the current approach?
2. Who objects to changing the approach to where the subordinate
components handle the version number and the implementations are
required to gracefully handle decode errors?

A comment was made that a third question, "Who doesn't care?" should
also be asked.

Russ asked the three questions with almost no response to the first two
questions.  The working group members that responded answered only to
the third question, that they don't care.

Russ noted that the working group did not give him much guidance on
this issue.

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

S/MIME Freeware Library (SFL) - Rich Nicholas

Rich presented a brief overview of the SFL, a freeware implementation of
RFCs 2630 and 2634 developed by Getronics Government Solutions.  Rich
described the various Getronics freeware security libraries and a high
level architecture depicting their relationship.  The libraries are:
- S/MIME Freeware Library
   -- Implements S/MIME v3 CMS/ESS security protocol.
   -- Provides ESS features: security labels, signed receipts, secure mail
      list info, signing certificate.
- Certificate Management Library
   -- Validates PKIX X.509 v3 certification paths & CRLs.
   -- Provides local cert/CRL storage functions.
   -- Provides remote directory retrieval via LDAP.
- Access Control Library
   -- Provides Rule Based Access Control using security labels and
      authorizations conveyed in either X.509 Attribute or public key
      certificates.
- Enhanced SNACC ASN.1 library provides DER.

For all of the Getronics freeware libraries, unencumbered source code is
freely available to all.  Getronics freeware can be used as part of
applications without paying any royalties or licensing fees.  There is a
public license associated with each Getronics freeware library.

The Getronics freeware libraries are available at:
SFL: <http://www.getronicsgov.com/hot/sfl_home.htm>
CML: <http://www.getronicsgov.com/hot/cml_home.htm>
ACL: <http://www.getronicsgov.com/hot/acl_home.htm>
SNACC: <http://www.getronicsgov.com/hot/snacc_home.htm>

The SFL is freeware implementation of RFC 2630 (CMS) and RFC 2634 (ESS).
When used with the Crypto++ library, the SFL implements RFC 2631
Ephemeral-Static (E-S) Diffie-Hellman (D-H) Key Agreement Method.  The
SFL supports RFC 2632 (Certificate Handling) and RFC 2633 (Message
Specification).  The goal of the SFL is to provide a reference
implementation of RFCs 2630 & 2634 to encourage acceptance as Internet
Standards.
The SFL:
- Can be used to protect any type of data (not just MIME)
- Maximizes crypto algorithm independence
- Successfully used by many commercial vendors

Getronics has used the SFL to perform a significant amount of S/MIME v3
interoperability testing.  Getronics tested the majority of features in
RFCs 2630, 2631 and 2634 as well as some of the features in RFCs 2632
and 2633.  Getronics used the SFL to successfully process and produce
the majority of features documented in "Examples of S/MIME
Messages".  SFL-generated data was included in the Examples document
such as: signed receipts, countersignatures, security labels, equivalent
security labels, mail list information, and signing certificate
attributes.  S/MIME v3 interoperability testing between the SFL and
Microsoft successfully tested most CMS/ESS features.

Rich presented the current status of the various Getronics freeware
libraries:
- SFL v1.10 (relesaed April 2001):
   -- Tested on RedHat Linux, Windows NT/98/00, Solaris 2.7.
   -- Fixed bugs in v1.9 SFL and accompanying CTILs.
   -- Added support for SHA-256 use with RSA (use with DSA TBD).
- CML v1.9.2 (released July 2001)
   -- Fixed bugs in v1.9 CML.
- Enhanced SNACC v1.3 R6 (released April 2001) fixed bugs.
- Access Control Library v1.6 (released May 2001)
   -- Supports multiple Clearance attributes in an X.509 attribute
      certificate or public key certificate.

Major new releases planned for September 2001.

The Internet Mail Consortium (IMC) has established SFL, CML and Enhanced
SNACC mail lists.  Rich pointed out that SFL/CML/Enhanced SNACC messages
should be sent to the IMC lists and should not be sent to the IETF mail
lists.

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

Wrap Up - Russ Housley

Russ asked if there were any other issues to discuss.  No additional
issues were raised.

Meeting adjourned.