Horvath, Tom | 6 Apr 20:35 2005

v2.5 S/MIME Freeware Library (SFL) Now Available


BAE Systems has delivered the Version 2.5 S/MIME Freeware Library (SFL)
source code.  The SFL source code files and documents are freely
available at 

The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message
Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS)
specifications.  It implements portions of the RFC 2633 Message
Specification, RFC 2632 Certificate Handling, and RFC 3370 CMS
Algorithms specifications.  When used in conjunction with the Crypto++
freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H)
Key Agreement Method specification.  It has been successfully tested
using the Microsoft (MS) Windows 2000/XP, Linux and Sun Solaris 2.8
operating systems.  Further enhancements, ports and testing of the SFL
are still in process.  Further releases of the SFL will be provided as
significant capabilities are added. 

The SFL has been successfully used to sign, verify, encrypt and decrypt
CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the
Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0
Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms
provided by the Fortezza Crypto Card.  The v2.5 SFL uses the v2.5
Certificate Management Library (CML) and v1.7 Enhanced SNACC (eSNACC)
ASN.1 C++ Library to encode/decode objects and certificate path
validation.  The v2.5 SFL release includes: SFL High-level library; Free
(a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL;
Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; test
utilities; test drivers; and test data.  All CTILs were tested as
Dynamically Linked Libraries (DLL) using MS Windows.  The Fortezza,
BSAFE and Crypto++ CTILs were tested with the respective security
libraries as shared objects using Linux and Solaris 2.8.  

The SFL has been successfully used to exchange signedData and
envelopedData messages with the MS Internet Explorer Outlook Express
v4.01, Netscape Communicator 4.X, Entrust and Baltimore S/MIME products.
Signed messages have been exchanged with the RSA S/MAIL and WorldTalk
S/MIME v2 products. 

The SFL has also been used to perform S/MIME v3 interoperability testing
with Microsoft that exercised the majority of the features specified by
RFCs 3369, 3370, 2631 and 2634.  This testing included the RSA, DSA, E-S
D-H, 3DES, SHA and Fortezza algorithms.  We used the SFL to successfully
process the SFL-supported sample data included in the S/MIME WG
"Examples of S/MIME Messages" document.  We also used the SFL to
generate S/MIME v3 sample messages that were included in the "Examples"

The use of the v2.5 SFL is described in the v2.5 SFL Application
Programming Interface (API) and v2.5 SFL Software Design Description
documents.  The use of the v2.5 CTIL API is described in the v2.5 CTIL
API document. 

v2.5 SFL includes the following enhancements (compared to v2.4
SFL releases):

1.	CSM_CertificateChoice changed to reflect the Crytographic
Message Syntax (CMS) update for the CertificateChoice class.  The class
was enhanced with a mechanism to support additional certificate formats
without further changes to the CMS_CertificateChoice interface.  A new
member was added to handle the other significant format types.   You
will find the definition for this type in the SMIME/libCert library of
the SFL.  This requirement could not be fully implemented at this time
because otherCertFormat type has not been defined.  The SFL can only
encode and decode this type.  See CSM_CertificateChoice Class section
for further details. 

2.	Added new classes CSM_RevocationInfoChoice and
CSM_RevocationInfoChoices reflecting the CMS class RevocationInfoChoice
addition.  The new member SNACC::otherRevocationInfoFormat is in this
class to support revocation status information formats without further
changes to the CMS_RevocationInfoChoice. Full implementation is not
available at this time because otherRevocationInfoFormat type has not
been defined.  The SFL can only encode and decode this type.   

3.	The use of version numbers have changed.  The
CSM_CertificateChoice and CSM_RevocationInfoChoice have new members
which required version number logic changes.  

4.	Added support for the Crypto++ Implementation of AES to the
sm_free3 CTIL.  This was done because the Crypto++ implementation is
significantly faster than the previous rijndael reference version.  The
AES rijndael/rijndaelref.zip is no longer needed to build the SMP/SFL
library.  Free3 now provides the Advanced Encryption Standard (AES)
algorithm, and is no longer in the Common Class.

5.	To implement Appendix B of the RFC 3161, the TimeStampToken
verification code now uses the CML to verify that the date/time
indicated by the time stamp authority (TSA) falls within the validity
period of the TSA's signing certificate and that the TSA's signing
certificate was not revoked at the date/time of the time-stamping
operation. To this end, revocation checking by the CML library is
necessary, and the revPolicy member of the InitSettings of the CML
session structure needs to be set to CM_REVCRL.

The SFL is developed to maximize portability to 32-bit operating
systems.  In addition to testing on MS Windows, Linux and Solaris 2.8,
we may port the SFL to other operating systems.

All source code for the SFL is being provided at no cost and with no
financial limitations regarding its use and distribution. Organizations
can use the SFL without paying any royalties or licensing fees.  BAE
Systems is developing the SFL under contract to the U.S. Government.
The U.S. Government is furnishing the SFL source code at no cost to the
vendor subject to the conditions of the "SMP Public License".

On 14 January 2000, the U.S. Department of Commerce, Bureau of Export
Administration published a new regulation implementing an update to the
U.S. Government's encryption export policy
<http://www.bxa.doc.gov/Encryption/Default.htm>.  In accordance with the
revisions to the Export Administration Regulations (EAR) of 14 Jan 2000,
the downloading of the SFL source code is not password controlled.

The SFL is composed of a high-level library that performs generic CMS
and ESS processing independent of the crypto algorithms used to protect
a specific object.  The SFL high-level library makes calls to an
algorithm-independent CTIL API.  The underlying, external crypto token
libraries are not distributed as part of the SFL source code. The
application developer must independently obtain these libraries and then
link them with the SFL.  

The SFL uses the CML and eSNACC ASN.1 Library to encode/decode
certificates, ACs, CRLs and components thereof as well as to perform
certificate path validation.  The CML is freely available at:

The SFL has been successfully tested in conjunction with the Access
Control Library (ACL) that is freely available to everyone from: 

The National Institute of Standards and Technology (NIST) is providing
test S/MIME messages (created by BAE Systems) at
<http://csrc.nist.gov/pki/testing/x509paths.html>. BAE Systems used the
SFL to successfully process the NIST test data.

NIST is using the SFL and CML as part of the NIST S/MIME Test Facility
(NSMTF) that they are planning to host (see
<http://csrc.ncsl.nist.gov/pki/smime/>).  Vendors will be able to use
the NSMTF to help determine if their products comply with the IETF
S/MIME v3 specifications and the Federal S/MIME v3 Client Profile. 

The SFL has been integrated into many applications to provide CMS/ESS
security services.  For example, the SFL was integrated into a security
plug-in for a commercial e-mail application that enabled the application
to meet the Bridge Certification Authority Demonstration Phase II
requirements including implementing ESS features such as security

The Internet Mail Consortium (IMC) has established an SFL web page
<http://www.imc.org/imc-sfl>.  The IMC has also established an SFL mail
list which is used to: distribute information regarding SFL releases;
discuss SFL-related issues; and provide a means for SFL users to provide
feedback, comments, bug reports, etc.  Subscription information for the
imc-sfl mailing list is at the IMC web site listed above.

All comments regarding the SFL source code and documents are welcome.
This SFL release announcement was sent to several mail lists, but please
send all messages regarding the SFL to the imc-sfl mail list ONLY.
Please do not send messages regarding the SFL to any of the IETF mail
lists.  We will respond to all messages sent to the imc-sfl mail list.


Tom Horvath
BAE SYSTEMS Information Technology