This message includes the minutes of the IETF S/MIME Working
Group (WG) meeting held on 13 December 2000 in San Diego,
California. Briefing slides will be available from
<ftp://ftp.ietf.org/ietf/smime/>. These minutes include comments
from the briefing presenters. Reported by John Pawling.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Introductions - Russ Housley
Russ reviewed the agenda as follows. Nobody commented on the agenda.
Introductions Russ Housley
Working Group Status Russ Housley
Interoperability Matrix Jim Schaad
CMS and ESS Examples Paul Hoffman
Security Policies and Labels Weston Nicolls
Symmetric Key Distribution Sean Turner
Domain Security (DOMSEC) Bill Ottaway
X.400 and CMS Chris Bonatti
Reuse of Content Encryption Keys Steve Farrell
Advanced Encryption Standard Jim Schaad
RSA-OAEP and RSA-PSS John Linn
RSA as a MUST implement Blake Ramsdell
E-Signature Formats using CMS John Ross
E-Signature Formats using XML Denis Pinkas
S/MIME Freeware Library John Pawling
Wrap up Russ Housley
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
S/MIME Working Group Status - Russ Housley
Russ outlined the strategy for advancing the following RFCs from
Internet Proposed Standards to Internet Draft Standards:
RFC 2630 Cryptographic Message Syntax (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
The aforementioned documents must meet the following requirements to
advance to Draft Standards:
1) Meet requirements documented in RFC 2026
2) Stable, mature, and useful specification
3) At least two independent and interoperable implementations
from different code bases
4) Draft Standards cannot reference Proposed Standard RFCs or
Experimental RFCs, so the aforementioned RFCs are blocked
until the PKIX Certificate and CRL Profile "Son-of-RFC 2459"
Internet-Draft (I-D) (draft-ietf-pkix-new-part1-03.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 and have not been successfully tested.
So far, 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. He asked that other organizations that have
developed S/MIME v3 capabilities should please participate.
Russ said he would submit that proposal to the S/MIME WG mail list.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Interoperability Matrix - Jim Schaad
Jim discussed the interoperability matrix for RFCs 2630 through 2634.
He has documented the successful completion of two-way interoperability
testing for the following number of clauses in each RFC. He has not
completely updated the results based on all interop testing performed:
RFC Clauses Tested
=========================
2630 49 of 96
2631 0 of 13
2632 16 of 21
2633 17 of 61
2634 27 of 81
More details regarding RFC 2630 testing:
Signed Data - 24 of 25
Enveloped Data - 11 of 25
Digested Data - 0 of 4
Encrypted Data - 0 of 4
Authenticated Data - 0 of 16
Other MUST Implement Requirements - 15 of 25
TOTAL - 49 of 96
More details regarding RFC 2634 testing:
Triple Wrap - 3 of 5
Signed Receipts - 19 of 41
Security Labels - 5 of 11
Equivalent Labels - 0 of 12
Mail List - 0 of 12
TOTAL - 27 of 81
Jim asked for others to submit input to him at
jimsch(_at_)exmsft(_dot_)com(_dot_)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Examples of S/MIME Messages - Paul Hoffman
Paul stated that he had distributed a new release of the "Examples of
S/MIME Messages" I-D <draft-ietf-smime-examples-05.txt>, November
2000, that includes additional sample data generated by Getronics
using the SFL. He stated that the document needs further input and
testing. He noted that Jim Schaad is testing all of the samples
included in the document. John Pawling recommended that a triple-
wrapped sample message should be added to the document. Jim
has already generated several triple-wrapped messages and will
provide them to Paul for inclusion in the document.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Mapping Company Classification Policy to the S/MIME Security Label -
Weston Nicolls
Weston stated that he had distributed a new release of the
"Implementing Company Classification Policy with the S/MIME
Security Label" I-D, <draft-ietf-smime-seclabel-02.txt>, October 2000.
He noted that his goal is for the document to become an Informational
RFC. It provides examples of how the RFC 2634 ESSSecurityLabel
feature can be used to support an organization's security policy. The
document includes classification policies and example security
labels for the Amoco, Caterpillar and Whirlpool corporations.
It includes an example security category syntax and samples.
It also includes Clearance attribute examples that include a
subject's authorizations.
Russ Housley proposed that Last Call for this document should be
completed by January 2001. Nobody objected.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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-02.txt>,
October 2000. Sean noted that Jim Schaad provided significant
comments to the symkeydist-01 I-D that Sean incorporated into the
symkeydist-02 I-D.
Sean stated that two messages were added: GLProvideCert and
GLUpdateCert. The GLDistributionMethod message was removed.
The GLInfo, GLOwner, and GLMember syntaxes were modified to
include "address" information. There were many changes made
to more closely align with RFC 2797 Certificate Management
Messages over CMS. He added text to explain how many and
when rekey messages are distributed. The rekey defaults
were fixed.
Sean stated that he still needed to add a conformance clause
and an Abstract Syntax Notation One (ASN.1) module. He also
needs to verify correctness of RFC 2797 error behavior.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
DOMSEC Draft Discussion - Bill Ottaway
Bill presented a briefing regarding the "Domain Security Services Using
S/MIME" I-D <draft-ietf-smime-domsec-07.txt>, November 2000. He made
several minor changes as a result of e-mail exchanges with Jim Schaad
on the S/MIME WG mail list.
He added a section regarding Mail List Agents (MLA) that addresses
the situation in which an MLA will remove the 'domain signature' when
the signature encapsulates a mlExpansionHistory attribute and/or a
envelopedData type. He briefed the solution to this problem which
is documented in domsec-07 in Section 5, "Applying a Domain Signature
when Mail List Agents are present". He stated that the he believes
that the outstanding issues have been resolved and that the DOMSEC
I-D should be submitted for last call.
Russ Housley proposed that the DOMSEC document is ready for S/MIME WG
Last Call. The intent is for this document to be published as an
Experimental RFC. Russ proposed that the S/MIME WG Last Call should
close on 10 January 2001. Nobody objected.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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. The x400wrap I-D specifies how
to protect X.400 content with CMS objects. It is roughly analogous
to RFC 2633 and refers to RFC 2633 when applicable. It minimizes
the use of MIME encodings to reduce overhead. He briefed the
proposed wrapping strategy. He discussed the object identifiers
used, MIME heading parameters and detached signature form. He
has already incorporated comments submitted by Bill Ottaway and
Graeme Lunt.
Chris noted that products generally do not support encapsulating
content types other than data (such as signed-data or enveloped-data).
Jim Schaad challenged that statement and noted that the Microsoft,
SFL and Peter Gutmann's cryptlib S/MIME v3 implementations do
support encapsulating content types other than data.
The x400transport I-D specifies how to package CMS objects for
transport by X.400 Message Transfer Agents (MTA). It discusses
the scenario in which the CMS encapsulated content is an RFC 822
MIME message. It states that the outer MIME wrapper is not generally
necessary in X.400. It also states that circumstances may exist when
the outer MIME wrapper is desirable such as when a gateway into an
SMTP transport is part of the architecture. Chris discussed the
object identifiers used, packaging the CMS object in the X.400
content and that messages that only contain certificates are not
supported. He has incorporated comments submitted by Bill Ottaway.
Blake Ramsdell asked about support for messages that only contain
certificates. Chris responded that messages that only contain
certificates are supported, but they can't be identified as such
in the wrapper.
Chris recommended that these I-Ds be placed on the standards track
and asked for feedback from the WG. Russ Housley and Jeff Schiller
agreed with Chris' recommendation.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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-00.txt>, September 2000.
The rcek I-D specifies how to set up a shared secret key using
asymmetric crypto (using EnvelopedData object) and then to re-use
the content encryption key (CEK) to derive the Key Encryption Key (KEK)
of the next message. It defines attributes for inclusion in
EnvelopedData objects that indicates that the CEK is to be re-used
and the maximum number of times that it can be re-used.
Steve noted that the I-D specifies a key derivation scheme for the
re-use of CEKs when the KEK and CEK algorithms must be different.
The I-D defines a new attribute for this case. It also documents a
new key derivation function with the property that it only requires
the use of the CEK encryption algorithm. The function is documented
in the rcek I-D, "Using different CEK and KEK algorithms" section.
Blake Ramsdell recommended that Steve examine the Public Key
Cryptography Standard (PKCS) #5 v2 key derivation function as an
alternative to defining a new function.
Steve stated that the outstanding issues are how much to specify
failure cases and the proposed key derivation scheme. He would like
to do one more version and then submit it to WG last call. He
recommended that this I-D be placed on the standards track.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Advanced Encryption Standard (AES) in CMS - Jim Schaad
Jim presented a briefing regarding the "Use of the Advanced
Encryption Algorithm in CMS" I-D, <draft-ietf-smime-aes-alg-00.txt>,
November 2000. The aes-alg I-D specifies how to incorporate AES
into CMS as an additional algorithm for symmetric encryption. Jim
briefed that the proposed AES parameters are as follows:
Block Size - Fixed at 16 bytes
Key Size - 128, 192 or 256 bits
Proposed MUSTs 128 and 256 bits
Jim noted that the aes-alg I-D does not include an AES key wrap
algorithm. He proposes to include 256-bit key wrap algorithm as
the only MUST-implement requirement. Paul Hoffman asked if Jim
knew the difference in performance between using 256-bit versus
128-bit keys. Jim responded that the 256-bit key wrap takes a
longer amount of time, but he didn't know the exact difference.
Regarding key management, the I-D specifies that compliant
implementations MUST support key transport using the PKCS #1 v2.0
Optimal Asymmetric Encryption Padding (RSA with OAEP) technique.
It also specifies that compliant implementations MAY support key
agreement using Ephemeral-Static (E-S) Diffie-Hellman (D-H) with
modifications. It also specifies that compliant implementations
MAY support symmetric key-encryption key management.
Paul Hoffman commented that he believes that if the S/MIME WG
specifies the use of both 128- and 256-bit keys, then customers
will always demand 256-bit keys to achieve maximum security.
He is concerned that the use of 256-bit keys will be a significant
performance hit. For example, he believes that using 256-bit keys
will drastically impact the performance of secure mail lists. He
asked if the WG should consider only specifying the use of 128-bit
keys.
Jim responded that the certificate processing required to obtain a
recipient's valid public key far exceeds the performance difference
between using 128- and 256-bit keys.
An attendee pointed out that companies couldn't sell 128-bit
implementations because they have already been advertising the use
of larger key sizes with Triple-DES.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RSA-OAEP and RSA-PSS - John Linn
John presented a briefing regarding the potential use of RSA-based
encryption and signature algorithms in conjunction with CMS and
S/MIME. He stated that many S/MIME products currently use the PKCS
#1 v1.5 (RFC 2313) RSA algorithm that defines encryption and
signature algorithms using ad hoc padding. PKCS #1 v1.5 RSA is
specified as an optional algorithm in RFC 2630 (CMS). John described
the PKCS #1 v1.5 padding formats and usage (his briefing slides
provide details). He then described the Bleichenbacher adaptive
chosen cipher text attack on PKCS #1 v1.5 encryption padding. The
attack requires information from hundreds of thousands of decryptions,
indicating whether correct padding resulted. A successful attack
yields the result of a specific decryption. It does not yield the
originator's private RSA key. Countermeasures include protocol-level
means to ensure that information on decryptions is not available to
attackers (constraints on returned information; randomize key,
continue upon detected pad error) and improved, plaintext-aware
padding (OAEP) in the cryptographic layer. More details are
available in RSA Laboratories Bulletin #7 in
<http://www.rsalabs.com/bulletins>.
PKCS #1 v2.0 (RFC 2437) defends against encryption padding attacks
using OAEP in conjunction with the RSA algorithm. It can be used
with CMS as described in the "Use of the RSAES-OAEP Key Transport
Algorithm in CMS" I-D, <draft-ietf-smime-cms-rsaes-oaep-02.txt>.
John stated that recent theoretical results on strengths and
assumptions of OAEP proofs have been discussed in the cryptographic
research community, and have reinforced the conclusion that the
OAEP properties remain strong for use with RSA. He pointed out
that OAEP offers attractive properties in a random oracle model.
It is provably secure and provides a level of security that is
directly related to the strength of the RSA function. He also
highlighted the fact that OAEP is plaintext-aware. When OAEP is
used, it is impossible to generate valid cipher text without
knowing the plaintext; thereby, effectively guarding against
chosen-cipher text attacks. He briefed the RSAES-OAEP steps
(his briefing slides provide further details).
PKCS #1 v2.1 (draft, September 1999; 2nd draft in preparation)
defends against potential signature attacks using the Probabilistic
Signature Scheme (PSS). John noted that like OAEP, PSS offers a
provably secure design. He briefed the proposed PSS encoding
operation (his briefing slides provides further details).
John stated that he does not know of any patents regarding the use
of OAEP technique as proposed for S/MIME. The PSS encoding method
is patent pending by the University of California (UC). UC agreed
to waive licensing on PSS for signatures with message recovery
(PSS-R variant) if adopted in an IEEE standard.
John briefed that OAEP is stable and is being included in the PKCS #1
v2.0, IEEE P1363 and ANSI X9.44 specifications. He stated that
standardization of PSS is being pursued in several forums and will
be included in the IEEE P1363a and PKCS #1 v2.1 specifications. He
stated that there is intent in ANSI X9F1 to reopen X9.31 to
incorporate PSS. There is a revision in progress to include PSS-R
in ISO 9796-2.
John proposed that for the short term the S/MIME v3 documents should
specify PKCS #1 v1.5 as a "MUST implement" requirement and PKCS #1
v2.0 RSA with OAEP as a "SHOULD implement" requirement. He recommended
that the WG should specify RSA with OAEP as a "MUST implement"
requirement for interactive CMS-based applications. John proposed that
PSS signatures should be adopted as a long term solution along with
the AES algorithm and new hash functions.
An attendee stated that multiple "MUST implement" requirements may be
tough to support on constrained platforms such as smart cards or palm
devices.
Jim Schaad pointed out that the format of the RSA public key is
identical for PKCS #1 v1.5 and PKCS #1 v2.0 RSA with OAEP. He asked
how an application was supposed to determine, based solely on the
recipient's certificate, which algorithm to use as the key transport
algorithm when encrypting data. This would be a problem if both
algorithms are "MUST implement" requirements. Jim asked if RSA has
considered defining a new object identifier to identify public keys
for subjects that use PKCS #1 v2.0 RSA. Russ Housley replied that
RSA decided to use the same object identifier to support both
algorithms.
John Pawling pointed out that the SMIMECapabilities attribute could
be used to identify an entity's preferred key management algorithm.
Jim replied that many products are not capable of processing the
SMIMECapabilities attribute. He also stated that an application may
support multiple key management algorithms, so there is a question
regarding which algorithms will be advertised in the SMIMECapabilities
attribute. Russ Housley stated that applications should offer a menu
that allows the user to select a combination of algorithms. He
suggested that this topic should be discussed further on the S/MIME
WG mail list.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RSA As a Must Implement - Blake Ramsdell
Blake proposed that RFC 2630 be changed to specify the PKCS #1 v1.5
RSA public key algorithm as the "MUST implement" key management and
signature algorithm since the RSA patent has expired.
Blake stated that the majority of the July 2000 S/MIME WG meeting
attendees stated their preference that both the PKCS #1 v1.5 RSA and
DSA algorithms be the "MUST implement" signature algorithms. He
stated that messages sent to the S/MIME WG mail list questioned if
vendors would actually implement both algorithms if both were
specified as "MUST implement". Others asked if there was a valid set
of requirements justifying that both algorithms be specified as "MUST
implement". Blake stated that PKCS #1 v1.5 RSA algorithm should be
the "MUST implement" signature algorithm and that DSA should be the
"MAY implement" signature algorithm. Blake said that PKCS #1 v2.0
RSA with OAEP should be discussed.
Paul Hoffman raised the issue of the definition of "MUST implement"
requirements. He described three definitions that various folks
support: 1) describe current usage; 2) force a specific future
solution; and 3) provide optimal security solution. He recommended
that those that are interested in this issue should conduct a
sidebar meeting to write a position paper that would then be sent
to the S/MIME WG mail list.
Russ Housley stated that the three definitions described by Paul
point to different algorithm sets. He stated that he would talk to
the security area director about this issue. He was surprised by
the characterization of the arguments.
Russ stated that if PKCS #1 v1.5 RSA is approved as the "MUST
implement" requirement, then the S/MIME WG must document the
safeguards that should be taken.
Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the following options for the "MUST
implement" signature algorithm:
1) PKCS#1 v1.5 RSA
2) DSA
3) Both
The meeting attendees were evenly divided between options 1 and 3.
Only one attendee voted for the "DSA" option.
Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the following options for the "MUST
implement" key management algorithm:
1) PKCS#1 v1.5 RSA
2) PKCS#1 v2.0 RSA with OAEP
3) E-S D-H
The meeting attendees were evenly divided between options 1 and 2.
Only one attendee voted for the "E-S D-H" option.
Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the definition of the "MUST
implement" requirement:
1) force a specific future solution
2) describe current usage
3) provide optimal security solution.
Not many attendees voted in this straw poll. Two attendees voted
for option 1, four voted for option 2 and one voted for option 3.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Electronic Signature Formats - John Ross
John briefed regarding the "Electronic Signature Formats for long term
electronic signatures" I-D. The esformats I-D is based on the European
Telecommunications Standardization Institute (ETSI) Electronic Signature
Infrastructure Standardization and defines a process to provide proof of
the validity of a signature to be used if repudiation is attempted. The
esformats-02.txt was based on ETSI ES 201 733. The new version,
esformats-03.txt, is based on ETSI TS 101 733. All of the versions
are based on RFC 2630. John stated that the changes in the esformats-03
I-D include extensions to the previous version including: verifier
conformance options (Timestamping, Secure records); Signature policy
options (Explicit by object identifier, Implied by signed content/
signature environment); and Content encoding indication (Content hints).
John proposed that esformats-03 I-D is ready to become an Informational
RFC. The planned work is: ETSI Implementation Trials; XML signature
formats; and more work on signature policies.
John then briefed regarding the "Electronic Signature Policies" I-D,
<draft-ietf-smime-espolicies-00.txt> that defines signature policies
for electronic signatures. He proposed that the espolicies-00 I-D
is ready to become an Experimental RFC.
Russ Housley proposed that the Electronic Signature Formats document
is ready for S/MIME WG Last Call. The intent is for this document to
be published as an Informational RFC. Russ proposed that the S/MIME
WG Last Call should close on 10 January 2001. Nobody objected.
Russ Housley proposed that the Signature Policies document is ready
for S/MIME WG Last Call. The intent is for this document to be
published as an Experimental RFC. Russ proposed that the S/MIME WG
Last Call will close on 10 January 2001. Nobody objected.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
E-Signature Formats using XML - Denis Pinkas
Denis briefed that ETSI is defining new XML types to contain
equivalent electronic signatures information to those ASN.1 types
defined in the esformats I-D. These new XML types would include
additions to the Signature XML element as defined by the W3C/IETF.
He pointed out that there is not a one-to-one mapping from ASN.1
to XML because some of the ASN.1 structures (such as the
MessageDigest signed attribute) have been incorporated into the XML
digital signature core syntax. Denis listed the new XML types
defined (his briefing slides provide further details). He stated
that new encapsulating XML type(s) need to contain ASN.1-encoded
data generated by PKI agents such as time stamp agents that
implement ASN.1 protocols. He discussed several proposals for
accomplishing this goal.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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-05 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 is planning to deliver a new release of the SFL in January
2001 that will include improved PKCS #11 capabilities (tested with
GemPlus, DataKey and Litronic PKCS #11 libraries). It will also
include AES content encryption (as per aes-alg-00) and key wrap
(128, 192, 256 bit keys; based on CMS Triple-DES key wrap algorithm).
It will also include an Enhanced SNACC library that increases
performance and decreases memory usage.
John also provided information regarding the Certificate Management
Library (CML) that is a freeware implementation of X.509 version 3
certification path verification as specified in the 1997 X.509
Recommendation (except Delta CRLs are not implemented).
The CML: validates X.509 certification paths and CRLs; provides
local certificate/CRL storage functions; and provides remote
directory retrieval via LDAP. The CML complies with the majority
of the RFC 2459 requirements. Getronics is enhancing the CML to
support the 2000 X.509 certificate policy processing requirements.
John also provided information regarding the Getronics-developed
Access Control Library 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 from <http://www.GetronicsGov.com/>.
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 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.