21 March 2001 S/MIME WG Minutes

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

This message includes the official minutes of the IETF S/MIME
Working Group (WG) meeting held on 21 March 2001 in Minneapolis, 
Minnesota, USA.  Briefing slides will be available from
<ftp://ftp.ietf.org/ietf/smime/>.  These minutes were reviewed
by 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
IPR Statements                      Russ Housley
Interoperability Matrix             Jim Schaad
CMS and ESS Examples                Paul Hoffman
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
Mandatory to Implement Algorithms   Russ Housley
S/MIME Freeware Library             John Pawling
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]

Russ outlined the requirements for advancing the standards track RFCs
from Internet Proposed Standards to Internet 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-05.txt) 
   progresses to Draft Standard. 

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 been successfully tested.  So far,
only Jim Schaad and Getronics Government Solutions have provided
input to the interoperability matrix.  Jim has provided input
regarding the capabilities of the Microsoft S/MIME v3 implementation.
Getronics 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.  

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

IPR Statements - Russ Housley

Russ presented a briefing regarding Intellectual Property Rights (IPR)
notices that have been provided to the IETF that may be related to 
implementing features described in the S/MIME specifications.  The
main goal of this briefing was to inform working group members of the 
existence and location of these IPR statements.

Russ began with a disclaimer that he is not a patent attorney and  
warned that implementers should not make development decisions based
on his presentation.  He stated that each implementer MUST have 
their own patent attorney review the relevant documents.  He further
stated that the opinions expressed in his briefing are his own and 
do not necessarily reflect the opinion of his employer, RSA Security.

Russ briefed that some techniques for efficiently implementing 
cryptographic algorithms have been patented and that many of these
patent holders have not chosen to submit IPR statements to the IETF.
He stated that he is only addressing the patents identified in IPR
statements posted on the IETF Page of IPR Notices
<http://www.ietf.org/ipr.html>.  He re-iterated that implementers
MUST do their homework before selecting a particular technique.

RSA Security IPR <http://www.ietf.org/ietf/IPR/RSA> states that
the RSA public-key cryptosystem Patent expired on 20 September 2000.

RSA Security IPR <http://www.ietf.org/ietf/IPR/RSA-MD-all> states
that implementations of the MD2, MD4, and MD5 message-digest
algorithms, including implementations derived from the reference
C code in RFC 1319, RFC 1320, and RFC 1321, may be made, used, 
and sold without license from RSA Security for any purpose. 

U.S. National Institute of Standards and Technology (NIST) IPR
<http://www.ietf.org/ietf/IPR/DSA-NIST> states that they have made
the Digital Signature Algorithm (DSA) patent available 
royalty-free to users worldwide. 

Certicom IPR <http://www.ietf.org/ietf/IPR/CERTICOM-ECDSA> states 
that they believe that they have patents issued or pending that 
relate to Elliptic Curve DSA (ECDSA) as follows: point 
compression, public key validation (including domain parameter
validation), and computational techniques.  They are willing to
offer a non-exclusive license under reasonable and 
non-discriminatory terms and conditions, providing the applicant 
provides a similar grant for the applicant's relevant patents
(if any) and respects Certicom's other intellectual property.

Certicom IPR <http://www.ietf.org/ietf/IPR/CERTICOM-SMIME-1>
states that they have U.S. Patent No. 5,933,504 issued regarding 
Diffie-Hellman (D-H) Small Subgroup Attacks.  They are offering 
a royalty-free license for the restricted field of use of 
Ephemeral-Static (E-S) D-H as specified in the S/MIME 
specifications (i.e. RFC 2631).  The Certicom license does
not address fields of use other than E-S D-H.  Other algorithms
require a separate license.  The Certicom license requires 
reciprocal grant to licensee's patents (if any) in same field 
of use.

IBM IPR <http://www.ietf.org/ietf/IPR/IBM-diffie-hellman.html>
states that they have U.S. Patent No. 5,953,420 issued regarding
D-H.  Where there is a necessary dependence upon this patent to
implement the algorithms, IBM will provide a non-exclusive 
license under reasonable and non-discriminatory terms and 
conditions, in accordance with IBM's usual licensing practices.
Russ' personal opinion is that this patent does not apply to the
Ephemeral-Static (E-S) D-H algorithm as described in RFC 2631.

Don Hall IPR <http://www.ietf.org/ietf/IPR/HALL-SMIME> states that
he has U.S. Patent No. 5,126,728 issued regarding Security Labels.
Nonexclusive licenses, on relevant patent claims, will be made 
openly available for a reasonable fee, without discrimination.
Russ' personal opinion is that this patent does not apply to the
security labeling as described in RFC 2634.

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

Interoperability Matrix - Jim Schaad

Jim briefed that he is still working with the S/MIME Freeware Library
and Microsoft S/MIME v3 implementations to build and process examples
of the features documented in the interoperability matrix for RFCs 
2630 through 2634.  Other organizations that have developed S/MIME v3
capabilities are requested to participate.  If an organization
has already performed tests that fulfill a particular requirement,
then the results should be included in the matrix.  Please submit
input to Jim at [e-mail].

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

CMS and ESS Examples - Paul Hoffman

Paul stated that he had distributed a new release of the "Examples of
S/MIME Messages" I-D <draft-ietf-smime-examples-06.txt>, 25 February 
2001, that includes corrected sample data generated by Getronics
using the SFL.  He stated that the document needs further input and 
testing.  He asked that other organizations that have developed 
S/MIME v3 capabilities should please participate.  He invited people 
to provide comments regarding errors in the document.  He acknowledged
that there are still errors in some of the test data that must be 
fixed.  He stated that since nobody had provided a sample of an 
EnvelopedData using RC2/40 for content encryption using a 
previously-distributed key-encryption key, that he would eliminate
that section from the document.  When Paul stated that nobody had
provided any sample AuthenticatedData objects, Jim Schaad volunteered
to provide those examples.  Chris Bonatti questioned the value of
including AuthenticatedData objects in the document that only Jim
Schaad could build and process.  The consensus was that was better
than nothing.

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

Symmetric Key Distribution - Sean Turner

Sean stated that he had distributed a new release of the S/MIME
Symmetric Key Distribution I-D, <draft-ietf-smime-symkeydist-03.txt>, 
2 March 2001.  Sean noted that Jim Schaad provided significant 
comments to the symkeydist-02 I-D that Sean incorporated into the 
symkeydist-03 I-D.  

Sean briefed the following changes included in symkeydist-03:
- Reorganized requirements (Each component has mandatory and
    optional support requirements).
- Removed restriction that only Group List (GL) Owner (GLO) is
    allowed on unmanaged lists.
- Added new field to GLRekey to support rekey of all outstanding 
    keys.
- Added ASN.1 module.
- Added text for "Using the Group Key".
- Added date to GLKRefresh to support getting a range of previously
    distributed keys. 
- Modified GLProvideCert and GLUpdateCert so they are the same 
    syntax.
- Removed strict requirement for encrypting outbound messages if 
    inbound messages were encrypted.
- ktri instead of kari RecipientInfo choice.
- Added checks for the GLO and GL member to make sure the GL's 
    certificate was used to sign the response.

Sean stated that he is incorporating comments to symkeydist-03
regarding using the new Certificate Management Messages over 
CMS (CMC) structures.  Also, some object identifiers (OID) need
to be defined.

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

X.400 and CMS - Chris Bonatti

Chris presented a briefing regarding the "Transporting S/MIME Objects
in X.400" I-D, <draft-ietf-smime-x400transport-01.txt> and "Securing
X.400 Content with S/MIME" I-D, <draft-ietf-smime-x400wrap-01.txt> 
both distributed in November 2000.  Both drafts are proposed
for the IETF Standards Track.  Paul Hoffman is the primary editor
for both drafts and will be delivering an "02" version of both 
drafts once he has incorporated comments.  

The x400wrap I-D specifies how to protect X.400 content with CMS 
objects.  It is roughly analogous to RFC 2633 and refers to RFC2633
when applicable.  Chris believes that the "02" version will be 
ready for S/MIME working group last call.

The x400transport I-D specifies how to package CMS objects for 
transport by X.400 Message Transfer Agents (MTA).  It is separate
from the X.400 wrapping draft to encourage use of RFC 822/MIME 
content in X.400 communities.  

One outstanding issue is the X.400 Transport of the "certs-only"
format.  RFC 2633 specifies a convention for identifying a message
that contains a "degenerate" SignedData structure that contains no
encapsulated content, but is sent merely for the purpose of 
conveying certificates or CRLs.  The "certs-only" convention was
omitted from the -01 X.400 Transport draft because the RFC 2633
convention was not applicable and it was unclear whether Public Key
Cryptography Standard (PKCS) 10 requests would be used in the X.400
environment.  Discussion with some in the X.400 community yielded
a proposal to identify certs-only messages via the encoded-
information-types (EITs) field in the X.400 envelope.  Chris' 
proposed solution was to add clarifying text to the X.400 
Transport document. This approach was discussed on the mailing 
list and appeared to be acceptable.  

A comment was sent to the mailing list that the "certs-only" 
message was misnamed because it could include certificates and/or
Certificate Revocation Lists (CRL).  Chris made the point that
if the x400transport I-D is changed, then RFC 2633 should also
be changed to be consistent.  He further stated that this is 
a real issue because CRLs are being conveyed in operational 
S/MIME messages today.   

Paul Hoffman expressed his opinion that the name of the message 
should be changed to clarify the contents.  He stated that a 
similar misnomer had created problems in the IPSEC environment
because implementations were not expecting CRLs to be included
in an ASN.1 encoded object and crashed when they were included.

Jim Schaad expressed his concern that we may be setting a 
precedent for defining new S/MIME types for every new type of
S/MIME message that is defined (such as CMC).  Jim asked if the
plan was to define other S/MIME types.

Chris replied that he did not think that it was necessary to 
create a new S/MIME type for every variation of S/MIME message.

Jim asked why it is necessary for certs-only messages.

Chris stated that RFC 2633 defined a different S/MIME type so
that applications would know to process it differently.

Jim stated that S/MIME applications include special processing
rules for some types of S/MIME messages such as signed receipts and
certs-only.  His opinion is that we only need to identify those
messages with special S/MIME types that require special processing.

Chris agreed with Jim's statement and further stated that the 
x400transport I-D should be consistent with RFC 2633 regarding
identification of messages that require special processing.

Russ stated that in X.400, content types are expressed as an OID;
however, MIME uses a structure that permits subtypes.  The X.400
use of an OID does not permit subtypes.

Jim asked if we planned to define OID values for other MIME
subtypes.

Russ pointed out that signed receipts require special 
processing, so they should also have a special X.400 type.

Chris stated that he will draft proposed text regarding the 
certs-only issue for inclusion in the x400transport I-D.

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

Reuse of Content Encryption Keys - Steve Farrell

Steve presented a briefing regarding the "Reuse of CMS Content
Encryption Keys" I-D, <draft-ietf-smime-rcek-01.txt>, February 2001.
The rcek I-D specifies how to set up a shared secret key using 
asymmetric crypto (using EnvelopedData) and then to re-use 
the content encryption key (CEK) to derive the Key Encryption
Key (KEK) of the next message.  

Steve briefed the changes included in the rcek-01 I-D:
- Key Derivation Function (KDF) changed to use PKCS #5 v2 KDF.
- Removed error attribute.
- Added ASN.1 module.
- Regarding comment that bit-reversal breaks DES parity bits,
    so use byte reversal instead.
- Received comments to use other KDFs such as X9.63/p1363a or
     TLS PRF.  Steve decided to stick with PKCS #5.
- Received comments regarding attribute syntax: Separate vs.
    single attribute.  Steve decided to stick with separate
    attributes.

Russ pointed out that the PKCS #5 ASN.1 syntax uses 1993 ASN.1
features, so Steve must convert the module to use 1988 ASN.1
syntax and include it in the rcek I-D. 

Paul Hoffman asked why others recommended other KDFs. 

Steve stated that he believed that the PKCS #5 KDF is the 
way to go.

Simon Blake-Wilson stated that he believes that the X9.63 KDF
is more appropriate and efficient.  They are planning to use
S/MIME on a wireless device using scripts so efficiency is
important to them.

Steve disputed the statement that the X9.63 KDF is 
significantly more efficient than the PKCS #5 KDF.

Steve briefed that he still needs to add the following:
- Security consideration documenting the scenario in 
    which msg2 is sent to subset of msg1.
- Text describing combinations of attributes (sent 
    new "conformance" text to list).
- More motivation and "when-to-use" text.
- Security considerations describing flip-flop issue
    (will add text from list).
- Needs OIDs for attributes.
- "Same" algorithms (Text on list)
- CEKMaxDecrypts default & max (default: 1, max: 2^32)
- Comment ASN.1 module

Russ conducted a straw poll of the meeting attendees to obtain 
their opinion regarding the following options for the rcek KDF: 
1) X9.63/P1363a  
2) TLS
3) PKCS #5
There were 3 votes for option 1, no votes for option 2 and
4 votes for option 3.

Russ recommended that rcek should continue to use PKCS #5 KDF 
unless somebody could present a good reason for using another KDF.

Russ asked that people examine the aforementioned byte-reversal
issue.
   
Russ stated that the last call period would be re-started
because of the magnitude of the changes.   

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

AES and RSA-OAEP in CMS - Jim Schaad

Jim presented a briefing regarding the "Use of the Advanced 
Encryption Algorithm in CMS" (aes-alg) I-D.  The I-D specifies how 
to incorporate the Advanced Encryption Standard (AES) into CMS as 
an additional algorithm for symmetric encryption.  Jim stated that
the next version of the aes-alg document will also specify how to 
incorporate the RFC 2437 PKCS #1 v2.0 Optimal Asymmetric Encryption
Padding (RSAES-OAEP) key transport method of key management into CMS
as an additional algorithm.  The "Use of the RSAES-OAEP Key Transport 
Algorithm in CMS" I-D will be eliminated because the information will
be included in the aes-alg I-D.  The aes-alg I-D will describe the
conventions for using the RSAES-OAEP key transport algorithm and AES 
content encryption algorithm with the CMS enveloped-data, 
encrypted-data and authenticated-data content types.  

Jim stated that the S/MIME v3 specifications will be written to state
that compliant implementations will use RSAES-OAEP (rather than 
PKCS #1 v1.5) as the key transport algorithm when AES is used as the
content encryption algorithm.

Jim noted that the aes-alg I-D does not include an AES key wrap 
algorithm, but that he expects that will be provided by July 2001.
He is still waiting for input from NIST which should be provided 
during June or July 2001.
 
Jim noted that he would like to add signature algorithms for
use with SHA-256 to the document.  This is dependent on the 
following events:
- PKCS #1 v2.1 Probabilistic Signature Scheme (PSS) being 
    standardized and OIDs issued
- SHA-256 being standardized
- DSA-SHA-256 Key sizes and OIDs being issued

Tim Polk stated that NIST is working on a DSA specification for
use with SHA-256.  They are discussing the use of PSS/RSA with 
SHA-256.  He believes that they will have a SHA-256/PSS 
specification ready before August 2001.

Simon Blake-Wilson stated that he was concerned that the formats
of the certificates containing RSA public keys for use with 
RSA PKCS #1 v1.5 and RSAES-OAEP are identical.  He was trying 
to make the point that it is good cryptographic practice to
employ a given key pair in only one scheme.  This avoids the risk
that vulnerability in one scheme may compromise the security 
of the other, and may be essential to maintain provable security.
For example, RSAES-OAEP by itself would resist attack, but an 
opponent could exploit a weakness in the implementation of 
RSAES-PKCS #1 v1.5 to recover messages encrypted with either
scheme.  There was much discussion regarding this point.  

Russ Housley pointed out RSA is working to ensure that the RSA
algorithms are consistently specified in the various documents.

Russ recommended that the strengthened key management be 
specified in one I-D and DSA in another. 
 
Tim Polk stated that the PKIX working group will be specifying
how to sign certificates using the new algorithms.

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

Elliptic Curve Cryptography (ECC) - Simon Blake-Wilson

Simon presented a briefing regarding the "Use of ECC Algorithms in
CMS" I-D, <draft-ietf-smime-ecc-03.txt>, 2 March 2001.  He briefed
that ECC may offer savings in terms of bandwidth, computation, and
storage.  He stated that ECC savings may increase as key sizes 
increase.  

Simon briefed that EC-based algorithms are documented in the 
following specifications:
- Elliptic Curve Diffie-Hellman (ECDH) (from draft ANSI X9.63)
- ECDSA (from ANSI X9.62)
- ECMQV (from draft ANSI X9.63)
- Equivalent specifications in FIPS 186-2, IEEE P1363, SEC 1

Simon briefed that EC-based algorithms can be used with CMS
as follows:
- SignedData using ECDSA
- EnvelopedData using Ephemeral-Static ECDH
- EnvelopedData and AuthenticatedData using 1-pass ECMQV

Notes regarding ECC I-D:
- SignedData provides message digest, ECDSA starts with
   the message.
- Key derivation function uses X9.63.
- AuthenticatedData and multiple recipients.
- Efficiency for AuthenticatedData.
- Key wrap for AuthenticatedData.

To promote interoperability, the ECC I-D documents the
following:
- Recommended algorithms
- Recommended curves
- Use of SMIMECapabilities signed attribute
- Examples

Simon proposed the following plan for the ECC I-D:
- address any comments from meeting
- update ECDH/ECMQV reference?
- issue updated draft
- submit for WG last call

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

Mandatory to Implement Algorithms - Russ Housley

Russ briefed that the PKIX WG is not going to select a mandatory to
implement algorithm for certificates, so the S/MIME WG is free to
pick a single signature algorithm for certificates and messages.

Russ reviewed the straw poll conducted at the December 2000 S/MIME
WG meeting which asked attendees of their opinion regarding 
supporting two mandatory-to-implement signature algorithm: DSA 
and RSA (PKCS #1 v1.5).  Russ was concerned about the proposal to
mandate that all implementations must sign using both of these
signature algorithms because their key generation processes
are very different.  He proposed that implementations must be 
able to verify signatures on certificates and messages 
using both the DSA and RSA (PKCS #1 v1.5) signature 
algorithms; however, implementations are only required to 
generate signatures on messages using at least one of the 
signature algorithms. 

Tim Polk stated his support for Russ' proposal because it may be 
practical for implementations that use smart cards to only implement
a single signing algorithm due to the limitations of the smart card
token.

Russ conducted a straw poll of the meeting attendees to obtain 
their opinion regarding the following options for the "MUST
implement" signature algorithm: 
1) sign and verify using both PKCS#1 v1.5 RSA and DSA
2) sign using one algorithm, verify using both (i.e. Russ' proposal)
An overwhelming majority of the meeting attendees voted for option 2. 

Al Arsenault asked if RSA OAEP should be used instead of 
RSA PKCS #1 v1.5.

Russ stated that RSA OAEP had been proposed at previous meetings 
and on the mail list, but was rejected by many implementers.  He noted 
that Eric Rescorla had posted the "Preventing the Million Message 
Attack on CMS" on the mail list on 18 March 2001.  Concerns have been
expressed regarding the use of RSA PKCS#1 v1.5 by automated messaging
applications such as a Mail List Agent.  Eric's document describes the
concerns regarding RSA PKCS#1 v1.5 and some possible countermeasures. 

John Pawling asked if the change to use RSA PKCS#1 v1.5 as the 
mandatory to implement key management algorithm was dependent on the
acceptance of the "Preventing the Million Message Attack on CMS" I-D.
Russ answered that as long as the work was progressing that the change
could be made (similar to RFC 2631 and the Small Subgroup Attack).

Paul Hoffman asked if the change in the algorithms would case the
S/MIME version number to change (ex: v3.1).  John Pawling made the
point that the CMS ASN.1 syntax is not changing, just the algorithms
used with that syntax.  He further stated that the algorithms in an
instance of a CMS object are clearly indicated by OIDs populated in 
that object, so a version number change is not required.  Russ agreed
and made the point that the RFCs would change, but the S/MIME version
number would still be 3.  Nobody disagreed with Russ.  

Russ also stated that he believes that the algorithm information 
should be separated from the CMS specification into a separate RFC
as has been done with the new PKIX specifications.  Nobody disagreed
with Russ.  

In summary, the meeting attendees overwhelmingly agreed
on the following set of mandatory to implement algorithms:  
Signature: DSA and RSA (PKCS #1 v1.5) as per Russ' proposal
Message digest: SHA-1
Key Management: RSA (PKCS #1 v1.5)
Encryption: Triple-DES

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

S/MIME Freeware Library (SFL) - John Pawling

John briefed regarding the SFL which is a freeware implementation
of RFCs 2630 and 2634 developed by Getronics Government Solutions.
The SFL can be used with the Crypto++ freeware library to implement
RFC 2631.  The SFL provides functions to support use of RFCs 2632 
and 2633.  It has been tested on the RedHat Linux, Windows NT/98/00 
and Solaris 2.7 operating systems.  The SFL maximizes crypto 
algorithm independence.  It has been used with the RSA BSAFE v4.2,
Crypto++ v3.2, Fortezza CI and SPYRUS SPEX/ libraries.  Getronics
has developed the capability for the SFL to use any security
library that provides a PKCS #11 interface.

Getronics has used the SFL to perform a significant amount of S/MIME
v3 interop 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 I-D
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 almost all CMS/ESS features using mandatory,
RSA and Fortezza algorithm suites.  For example, successful signed
receipt interoperability testing was performed between the SFL 
and Microsoft.  Getronics verified that the SFL can produce and 
process the majority of features documented in Jim Schaad's 
S/MIME v3 interoperability matrix.  Complete test drivers and test
data are available with the SFL.

Getronics delivered the v1.9 SFL in February 2001 that included 
improved PKCS #11 capabilities (tested with GemPlus, DataKey
and Litronic PKCS #11 libraries).  It also included AES content
encryption (as per aes-alg-00) and key wrap based on CMS 
Triple-DES key wrap algorithm (this may need to be changed when
the AES key wrap algorithm is included in the aes-alg I-D).  It
also included an Enhanced SNACC library that increases 
performance and decreases memory usage.  

John provided information regarding the Certificate Management 
Library (CML) that is a freeware implementation of X.509 v3
certification path verification as specified in the 2000 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 complies with the majority 
of the RFC 2459 requirements.  In February 2001, Getronics delivered
the v1.9 CML enhanced to support the 2000 X.509 certificate policy
processing requirements.

John provided information regarding the Getronics-developed 
Access Control Library (ACL) that provides Rule Based Access 
Control using security labels and authorizations conveyed in either 
X.509 Attribute or public key certificates.  He also discussed the
Getronics Enhanced SNACC ASN.1 library that implements the 
Distinguished Encoding Rules (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 Internet Mail Consortium (IMC) has established SFL, CML and
Enhanced SNACC mail lists.  John 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.  The meeting
attendees were silent.

Meeting adjourned.