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 jimsch(_at_)exmsft(_dot_)com(_dot_)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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.