[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
v0.4 SFL Interim Release
All,
J.G. Van Dyke and Associates (VDA) has delivered the fourth interim release
(Version 0.4) of the S/MIME Freeware Library (SFL). It has been
successfully tested with the SunOS 4.1.3 and MS Windows NT/95 operating
systems. The SFL is a reference implementation of the IETF S/MIME v3 CMS
(June 98) and ESS (August 98) I-Ds. We have made significant progress with
the testing of the SFL. The v0.4 SFL has been successfully used to sign,
verify, encrypt and decrypt CMS objects using the mandatory algorithms
(DSA, D-H, 3DES) provided by the Crypto++ library and SHA-1 provided by
Government-furnished freeware. The v0.4 SFL has also been used to sign,
verify, encrypt and decrypt CMS objects using the RSA suite of algorithms
provided by the RSA BSAFE library. The SFL uses the SNACC ASN.1 Library to
encode and decode CMS signedData and envelopedData objects. The v0.4 SFL
release includes: SFL High-level library; SFL Crypto++ Crypto Token
Interface Library (CTIL); BSAFE CTIL; VDA-enhanced GNU SNACC ASN.1 Compiler
and Library; test drivers and test data.
Since the v0.3 SFL release, we have continued interoperability testing
between S/MIME v2 e-mail clients and the SFL as documented in the attached
message. To achieve the results documented in the attached message, we made
minor changes to the SFL v0.3 code such as adding support for additional
object identifiers. The v0.4 release of the SFL includes these fixes.
Specifically, the following enhancements are included in the v0.4 SFL release:
- Finished integration of newest CMS ASN.1
(<draft-ietf-smime-cms-06.txt>) and ESS ASN.1 specifications
(draft-ietf-smime-ess-07.txt) into source code.
- Moved UKM processing from OriginatorInfo to RecipientInfo in all
encrypt/decrypt logic (this code still does not support multiple
recipients under the same UKM, this will be implemented in a future
release of the SFL).
- SMIME test environment updates for more robustness and
interoperability with SMIME v2 vendor software (as a result of the
SecureConnect Conference).
- Created SFL Class diagrams using Microsoft Visual Modeler (can be
viewed using Releation Rose C++ Demo 4.0).
- Based upon requests from SFL integrators, included in this e-mail
message are notes regarding the use of proprietary environment
private keys with the SFL.
Although we have made significant progress with the development of the SFL,
this interim release of the SFL is NOT complete. We are still in the process
of developing and testing the SFL. For example, we will be enhancing the
BSAFE CTIL to store the user's private keys in an encrypted form. Further
releases will be provided as significant capabilities are added. The SFL is
being delivered incrementally to provide software as soon as possible to
allow developers to: work with the API; begin integrating the SFL into their
applications; and to provide feedback to the ongoing SFL development
process. The SFL documents and software are still being developed and are
subject to change. The goal for completion of the SFL is October 1998. The
stability of the S/MIME v3 specifications is a prerequisite for meeting this
delivery goal.
Future releases will include: incorporate S/MIME specification changes;
support for additional attributes; Fortezza CTIL; additional helper
functions; multiple signerInfos in signed receipts; enhanced test routines;
bug fixes; support for other crypto libraries; and support for other
operating systems. The SFL will be thoroughly tested and all memory leaks
fixed. Robustness testing will be performed. The SFL will be tested for
interoperability with S/MIME v2 and v3 products. Other possible future
enhancements include additional example CTILs supporting other Cryptographic
APIs, such as Open Group's Common Data Security Architecture. We will
continue enhancing utilities to generate certificates to be used as test data.
The IMC has established an SFL web page (http://www.imc.org/imc-sfl) which
includes links to the SFL files stored on the VDA SFL Page
(http://www.jgvandyke.com/services/infosec/sfl.htm) and on the Fortezza
Developer's S/MIME Page
(http://www.armadillo.huntsville.al.us/software/smime).
The following SFL files are not export-controlled. They are available at
the Fortezza Developer's S/MIME Page and VDA SFL Page:
1) SFL Documents: SFL Fact Sheet, SFL Software Design Description, SFL
Application Programming Interface, SFL CTI API and SFL Public License.
2) snacc-1.3vda.tar.Z: Compressed tar file containing SNACC ASN.1 Compiler
and Library source code compilable for Unix that has been enhanced by VDA to
implement the Distinguished Encoding Rules. makefiles are included.
3) snaccvc.zip: zip file containing SNACC ASN.1 Compiler and Library source
code that has been enhanced by VDA to implement DER. MS Windows NT/95
project files are included for the SNACC code, MIME++ and Crypto++. Note
that the Crypto++ and MIME++ libraries are not included. See
(http://www.eskimo.com/~weidai/cryptlib.html) and
(http://hunnysoft.com/mimepp/) for these two libraries.
The following SFL files are export controlled and are available at the
Fortezza Developer's S/MIME Page:
1) sfl4Unixtar.Z: Compressed tar file containing all SFL source code
including: SFL Hi-Level source code; VDA-enhanced SNACC-generated ASN.1
source code; SFL Crypto++ CTIL source code; SFL BSAFE CTIL source code;
makefiles. This file also contains test driver source code, sample CMS test
data and test X.509 Certificates. This file also includes test utilities to
create X.509 Certificates that each include a D-H, DSA or RSA public key.
2) smimeR04.zip: Zip file containing all SFL source code including: SFL
Hi-Level source code; VDA-enhanced SNACC-generated ASN.1 source code; SFL
Crypto++ CTIL source code; SFL BSAFE CTIL source code; project files. This
file also contains test driver source code, sample CMS test data and test
X.509 Certificates. This file also includes test utilities to create X.509
Certificates that each include a D-H, DSA or RSA public key. SNACC release
and debug libraries compiled for MS Windows NT/95.
3) csmime.mdl contains SFL Class diagrams created using Microsoft Visual
Modeler (can be viewed using Releation Rose C++ Demo 4.0).
Please note that no changes were made to the SFL documents or ASN.1
encode/decode library. The sfl4Unixtar.Z and smimeR04.zip contain all of
the changes between the v0.3 and v0.4 SFL releases.
Instructions for applying for an account on the Fortezza Developer's S/MIME
Page are available from that page. An account is required to download the
SFL files from the Fortezza Developer's S/MIME Page due to U.S. export
restrictions. See the U.S. Bureau of Export Administration's Commercial
Encryption Export Controls web site at http://www.bxa.doc.gov/encstart.htm
for more information regarding the U.S. export restrictions.
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. VDA is
developing the SFL under contract to the U.S. Government. The U.S.
Government is furnishing the SFL software at no cost to the vendor subject
to the conditions of the "SFL Public License" available from the VDA SFL
Page and Fortezza Developer's S/MIME Page.
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 Crypto Token Interface 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. For example, the SFL uses the freeware Crypto++
library to provide 3DES, D-H and DSA. To use the SFL with Crypto++ the
vendor must download the Crypto++ freeware library from the Crypto++ Web
Page and then compile it with the SFL source code.
The SFL software is developed to maximize portability to 32-bit operating
systems. In the future, support may be added for the following operating
systems: Macintosh, HP/UX 9.x/10.x, IBM AIX 3.2, Sun Solaris 2.6 and SCO ODT
3.0/5.0.
The IMC has 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 software and documents are welcome. We
recommend that comments should be sent to the imc-sfl mail list. We will
respond to all messages on that list.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
START OF PROPRIETARY ENVIRONMENT PRIVATE KEY NOTES
Some application vendors have requested information regarding how they can
add support for proprietary environment
private keys to the SFL. We have concluded that each application vendor
should simply add their proprietary environment
private keys directly to the RSA entries in the SFL CSM_CSInst class as
loaded in the SMRsaInit() global function. The vendor would replace the
"do"/"while" condition to reflect the intended originator private key entry(s).
There are two relevant pieces of information necessary to perform the
sign/encrypt operations relevant to the CTIL: public key and private key.
The following paragraphs describe where this information is stored as simple
"(char *)" and "int" for each. We suggest duplicating the "SMRsaInit"
source code in the vendor's own source file (to avoid being over-written by
SFL updates) and changing to reflect the custom conventions.
For now in the RSA CTIL library, these private keys are store un-encrypted.
In the freeware CTIL they are password based encrypted to make it difficult
for users to snoop into memory to access the keys in the clear, but this
logic has not been migrated fully to the RSA CTIL yet. For the vendor it
makes it easier. In the example logic below (from "sm_rsa.cpp"), simply
assign the length and data to "pRsa->m_RSAX.len" and "pRsa->m_RSAX.data"
from the vendor's clear private key information. Again, the vendor's
"do"/"while" condition would be set to reflect the number of keys required
to be loaded (probably just a single entry for now) looping through the
vendor's private data structures for the private/public keys.
...
void SMRsaInit(CSMIME *pCSMIME, char *pszPassword,
char *pszAddressBook, char *pszPrefix)
{
...
pEntry = AB.m_pEntries->SetCurrToFirst();
do
{
...
(sm_rsa.cpp:LINE 1336)
// store the private key info as a RSA private key
if (*pEntry->m_pPrivateOID == bsafe_id_rsa_encr ||
*pEntry->m_pPrivateOID == rsaEncryption)
{ // convert X from entry file into m_RSAX ITEM
SME(pRsa->m_RSAX.len = (unsigned int)pEntry->
m_pPrivateInfo->Length());
SME(pRsa->m_RSAX.data = (unsigned char *)pEntry->
m_pPrivateInfo->Get());
}
// store parameters and Y in preferred Alg for this instance
pAlgID = NULL;
SME(pRsa->GetParamsAndY(pEntry, &AB, pAlgID));//PUBLIC KEY
...
} while ((pEntry = AB.m_pEntries->GoNext()) != NULL);
In the future, we will probably wrap this load with a password based
encryption and unwrap when necessary as demonstrated in the "sm_free.cpp"
logic. This would simply add a few calls to any new logic that the vendor
creates now custom to the vendor's environment relating to loading different
private keys.
The public key is loaded by decoding the certificate associated with a user
and loading the appropriate data structure. We assume you have the public
key stored separate from the certificate and can thus load it directly into
the CTIL data structures. Our load from the certificate is demonstrated in
the member function: GetParamsAndY; but the vendor can simply load the
bitstring and length (in bytes) into the following CSM_RSA m_RSAY member.
...
SME(m_RSAY.data = (unsigned char *)bufferTemp.Access());
SME(m_RSAY.len = bufferTemp.Length());
...
This operation can be done directly in the "do"/"while" loop above that
loads the private key. This is where the CTIL init now loads the public key
with the call to "SME(pRsa->GetParamsAndY(pEntry, &AB, pAlgID));".
END OF PROPRIETARY ENVIRONMENT PRIVATE KEY NOTES
================================
John Pawling, jsp@xxxxxxxxxxxxx
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
================================
>Return-Path: <owner-imc-sfl@xxxxxxx>
>Date: Wed, 5 Aug 1998 14:10:04 -0400
>X-Sender: jsp@ajsn101
>To: imc-sfl@xxxxxxx
>From: jsp@xxxxxxxxxxxxx (John Pawling)
>Subject: SFL Interop Testing
>Sender: owner-imc-sfl@xxxxxxx
>Precedence: bulk
>
>All,
>
>J.G. Van Dyke and Associates (VDA) is developing the S/MIME Freeware Library
>(SFL) to implement the Internet Engineering Task Force (IETF) draft S/MIME
>version 3 set of specifications. Recently, VDA used the SFL to successfully
>exchange signed and encrypted S/MIME messages with legacy S/MIME version 2
>products. This testing is the initial step in proving the interoperability
>of the current draft IETF S/MIME v3 set of specifications with the S/MIME v2
>specifications (RFC 2315, RFC 2311, RFC 2312) based on the PKCS #7, v1.5
>specification. This testing proves that the SFL code is maturing and will
>soon be a viable candidate for incorporation into applications that require
>S/MIME v3 capabilities including the optional S/MIME v3 security features.
>
>VDA successfully tested the SFL at the Internet Mail Consortium
>(IMC)-sponsored SecureConnect 1 event held on July 23-24, 1998 in San Jose,
>CA. We used the SFL to verify the digital signature of S/MIME version 2
>signedData messages created by RSA (S/MAIL toolkit), WorldTalk, Microsoft
>and Entrust. We used the SFL to create S/MIME v2 signedData messages that
>were verified by RSA, WorldTalk and Microsoft. We used the SFL to decrypt
>an S/MIME v2 envelopedData message encrypted using the RSA S/MAIL toolkit.
>Also at SecureConnect, we began interoperability testing of S/MIME v3
>features with Microsoft. We believe that the SecureConnect event was
>extremely valuable and we plan to participate at the next SecureConnect
>event scheduled for Spring 1999.
>
>Prior to the SecureConnect event, VDA performed interoperability testing
>between the Microsoft Outlook Express (MSOE) S/MIME v2 e-mail client and the
>SFL. We used the SFL to successfully verify the signature of an
>MSOE-generated v2 signedData message. We used the SFL to create a
>signedData message that was verified by MSOE. We used the SFL to decrypt an
>envelopedData that was encrypted by MSOE. We used the SFL to encrypt an
>envelopedData that was then decrypted using MSOE. We also used the SFL to
>exchange a signed and encrypted S/MIME v2 message (i.e. signedData
>encapsulated within envelopedData) with MSOE.
>
>All of this interoperability testing was conducted using the RSA suite of
>algorithms. We plan to test the IETF mandatory crypto algorithms: Secure
>Hash Algorithm-1, Digital Signature Algorithm, Triple Digital Encryption
>Standard and Diffie-Hellman key agreement algorithm.
>
>To achieve these results, we made minor changes to the SFL v0.3 code such as
>adding support for additional object identifiers. We plan to deliver an
>updated release of the SFL that includes these fixes by the end of August.
>
>More information regarding the SFL is available on the Fortezza Developer's
>S/MIME Page (http://www.armadillo.huntsville.al.us/software/smime).
>
>================================
>John Pawling, jsp@xxxxxxxxxxxxx
>J.G. Van Dyke & Associates, Inc.
>================================
>
>