Bruce Stephens | 18 Jan 2010 17:52
Favicon

Suspected typo in CRL_hash.cpp


A colleague noticed that certificate revoked with reason
privilegeWithdrawn were still being reported as valid (while other
reasons were correctly being regarded as revoked).  I think this is due
to a typo in cml/crl/srv_dll/src/CRL_hash.cpp:

 <at>  <at>  -245,7 +245,7  <at>  <at>  bool CRLInsert (HashTable *table, Revocation *element, ulong hash_value)
                        element->GetRevocation()->exts &&
                        element->GetRevocation()->exts->reasonCode &&
                        element->GetRevocation()->exts->reasonCode->value &&
-                       (*(short *)element->GetRevocation()->exts->reasonCode->value & CM_CRL_REMOVE_FROM_CRL))
+                       (*(short *)element->GetRevocation()->exts->reasonCode->value == CM_CRL_REMOVE_FROM_CRL))
                {
                        // Remove the entry
                        delete element;

(privilegeWithdrawn is 9, and CM_CRL_REMOVE_FROM_CRL is 8.)

PKamra | 14 Aug 2007 08:47

RSA KEM test vectors

Hi All,
 
I need RSA KEM test vectors for testing my implementation of RSA KEM.
Can some one please help me by providing the same or share some link from where I can get it.
 
Thanks in advance.
 
Regards,
Pooja


The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.
Rupe, Jonathan C UTCFS | 18 May 2007 20:07
Favicon

RE: Problem(s) verifying signed message with detached content

Tom,
 
The updated version of sm_free3_RSA.cpp solves the problem! Thanks for the heads up on the certificate path validation as well. This is the next task to work on... Thanks again for your help!
 
-Jon

From: Horvath, Tom (US SSA) [mailto:tom.horvath <at> baesystems.com]
Sent: Friday, May 18, 2007 1:52 PM
To: Rupe, Jonathan C UTCFS; imc-sfl <at> vpnc.org
Subject: RE: Problem(s) verifying signed message with detached content

Jon,

 

Here is a corrected version of smp/SMIME/alg_libs/sm_free3/sm_free3_RSA.cpp that supports RSA with SHA256 signature verification.  Give it a try and let me know if it solves your problem.

 

P.S. I just want to make sure that you know that certificate path validation does not occur when you create the CSM_MsgToVerify object the way you did.  If you did want the SFL to use the CML for path validation, then you have to call the constructor that takes the CML and ACL settings.  For more information see the API documents on the web at http://www.digitalnet.com/knowledge/smime.htm.

 

--Tom

 

From: Rupe, Jonathan C UTCFS [mailto:jrupe <at> lenel.com]
Sent: Thursday, May 17, 2007 11:58 AM
To: Horvath, Tom (US SSA); imc-sfl <at> vpnc.org
Subject: RE: Problem(s) verifying signed message with detached content

 

Tom,

 

Thank you very much for your quick response! I added the code for SHA256 and this fixed the first problem as you said. Thanks for looking into the second problem as well. I appreciate your help!

 

-Jon

 

From: Horvath, Tom (US SSA) [mailto:tom.horvath <at> baesystems.com]
Sent: Thursday, May 17, 2007 11:24 AM
To: Rupe, Jonathan C UTCFS; imc-sfl <at> vpnc.org
Subject: RE: Problem(s) verifying signed message with detached content

Jon,

 

Your usage of the SFL looks appropriate you have just found one bug and I am not sure yet about the second problem.

The first problem you reported "encapsulated content digest != message digest attribute" happens because the SHA-256 message digest reference algorithm that we use does not return the digest in platform independent endianness, so the digest comparison fails.  The first problem was easy to fix, simply add the following code at line 4674 of smp/SMIME/alg_libs/sm_free3/sm_free3.cpp:

 

      }     else if (oidDigest == SNACC::id_SHA256 ||

             oidDigest == SNACC::id_ecdsa_with_SHA256)

      {

            bool bLastBlock = false; // set to true when this is the last block

            CryptoPP::SHA256 sha256;

 

            int bytesProcessed=0;

            int loop = pData->Length() / sha256.DigestSize();

 

            SME(pData->Open(SM_FOPEN_READ));

            while (!bLastBlock)

            {

SME(pchData = pData->nRead(sha256.DigestSize(), (SM_SIZE_T&)lBytesRead));

                  if ((lBytesRead != sha256.DigestSize()) || (pchData == NULL))

                        bLastBlock = true;

                  sha256.Update((const unsigned char *)pchData, lBytesRead);

            }

           

            CryptoPP::SecByteBlock digest(sha256.DigestSize());

            sha256.Final(digest);

 

            SME(pDigest->Open(SM_FOPEN_WRITE)); // open the digest buffer

            SME(pDigest->Write((char *)digest.data(), digest.m_size));

            status = 0;

      }

 

If you do this then the SFL Free 3 CTIL will use crypto++ SHA-256 message digest algorithm which works correctly and returns the digest in the correct endianness.

 

I am still looking into the second problem and will get back to your shortly. 

 

--Tom

 

From: owner-imc-sfl <at> mail.imc.org [mailto:owner-imc-sfl <at> mail.imc.org] On Behalf Of Rupe, Jonathan C UTCFS
Sent: Wednesday, May 16, 2007 11:47 AM
To: imc-sfl <at> vpnc.org
Subject: Problem(s) verifying signed message with detached content

 

I am having a problem (or two) verifying a signed message that has detached content. I am getting the error "encapsulated content digest != message digest attribute". However, I have been able to successfully verify the message with another API (that I cannot use). If I skip past where this exception is thrown (in sm_msgsignerinfo.cpp) I also get the following error: "RSA OID Unknown or Not Handled Yet!" The hashing algorithm is SHA-256 and signature algorithm is RSA. Is this supported?  Below is my code and attached are the sample files.

I'm new with all this stuff so any help (especially sample code :)) will be greatly appreciated!

Thanks!
Jon

 

CSM_AppLogin appLogin;
appLogin.AddLogin(CTIL_FILE_NAME, NULL);

CSM_Buffer contentInfoBuf("./CHUIDSig.bin");
CSM_Buffer* pSignedDataBuf = NULL;

CSM_ContentInfoMsg contentInfoMsg(&contentInfoBuf);
if (contentInfoMsg.IsSignedData())
{
        SM_RET_VAL retVal = 0;

        CSM_MsgToVerify msgToVerify; //(&contentInfoMsg);
                       
        pSignedDataBuf = new CSM_Buffer(        contentInfoMsg.AccessEncapContentClear()->m_content.Access(),
                                                        contentInfoMsg.AccessEncapContentClear()->m_content.Length() );
                       
        retVal = msgToVerify.PreProc(&appLogin, pSignedDataBuf);
        if( retVal != SM_NO_ERROR )
        {
                tcout <<_T("Failed to process verification message.") <<endl;
                return 1;
        }

        CSM_Buffer encapContent("./CHUIDData.bin");
        CSM_Content content(&encapContent);
        SNACC::AsnOid encapAsnOid = ID_PIV_CHUIDSECURITYOBJECT;
        msgToVerify.SetEncapContentClear(content);

        if( (retVal = msgToVerify.Verify(&appLogin)) == SM_NO_ERROR )
        {
                tcout <<_T("Verification passed!") <<endl;
        }
        else
        {
                tcout <<_T("Failed signature verification.") <<endl;
        }
}
else
{
        tcout <<_T("Content doesn't contain SignedData") <<endl;
}

<<TestData.zip>>

Rupe, Jonathan C UTCFS | 16 May 2007 17:46
Favicon

Problem(s) verifying signed message with detached content

I am having a problem (or two) verifying a signed message that has detached content. I am getting the error "encapsulated content digest != message digest attribute". However, I have been able to successfully verify the message with another API (that I cannot use). If I skip past where this exception is thrown (in sm_msgsignerinfo.cpp) I also get the following error: "RSA OID Unknown or Not Handled Yet!" The hashing algorithm is SHA-256 and signature algorithm is RSA. Is this supported?  Below is my code and attached are the sample files.

I'm new with all this stuff so any help (especially sample code :)) will be greatly appreciated!

Thanks!
Jon


CSM_AppLogin appLogin;
appLogin.AddLogin(CTIL_FILE_NAME, NULL);

CSM_Buffer contentInfoBuf("./CHUIDSig.bin");
CSM_Buffer* pSignedDataBuf = NULL;

CSM_ContentInfoMsg contentInfoMsg(&contentInfoBuf);
if (contentInfoMsg.IsSignedData())
{
        SM_RET_VAL retVal = 0;

        CSM_MsgToVerify msgToVerify; //(&contentInfoMsg);
                       
        pSignedDataBuf = new CSM_Buffer(        contentInfoMsg.AccessEncapContentClear()->m_content.Access(),
                                                        contentInfoMsg.AccessEncapContentClear()->m_content.Length() );
                       
        retVal = msgToVerify.PreProc(&appLogin, pSignedDataBuf);
        if( retVal != SM_NO_ERROR )
        {
                tcout <<_T("Failed to process verification message.") <<endl;
                return 1;
        }

        CSM_Buffer encapContent("./CHUIDData.bin");
        CSM_Content content(&encapContent);
        SNACC::AsnOid encapAsnOid = ID_PIV_CHUIDSECURITYOBJECT;
        msgToVerify.SetEncapContentClear(content);

        if( (retVal = msgToVerify.Verify(&appLogin)) == SM_NO_ERROR )
        {
                tcout <<_T("Verification passed!") <<endl;
        }
        else
        {
                tcout <<_T("Failed signature verification.") <<endl;
        }
}
else
{
        tcout <<_T("Content doesn't contain SignedData") <<endl;
}

<<TestData.zip>>

Attachment (TestData.zip): application/x-zip-compressed, 1930 bytes
Horvath, Tom (US SSA | 30 Oct 2006 22:08

v1.7.4 Enhanced SNACC Freeware Compiler and Run Time Libraries Now Available


All,

BAE Systems has delivered the v1.7.4 eSNACC Abstract Syntax Notation.1
(ASN.1) Compiler, C++ library and C library source code compilable for
Linux, Sun Solaris 2.8 and Microsoft (MS) Windows NT/98/2000/XP.  The
eSNACC software is freely available from:
<http://digitalnet.com/knowledge/snacc_home.htm>

v1.7.4 eSNACC enhancements (compared to v1.7.3 release):

1. Fixed a bug where the C library BEncAsnBitsContent() function
incorrectly encoded empty BIT STRINGs. 

2. Fixed a bug with C-code generation where the tag decoding code for a
choice within a set is incorrect. 

3. Fixed ExpBufSetWriteError() function to pass in a double pointer
instead of a single pointer to preserve allocated memory. 

4. Fixed a bug where numbers greater than 4 bytes were not passing
constraint tests even though the range was defined as up to MAX, which
is much greater than 4 bytes. 

5. AsnBits::SetSize() function now uses a safer memory copy instead of a
string copy when re-sizing. 

6. Code now compiles on GCC compilers up to v4.1.1 

7. Fixed memory leaks when freeing an AsnAny data type 

8. Fixed bug in IA5String constraint checking which was ignoring null
characters when checking the size. 

9. Fixed a bug in generated C code when a tagged choice is within a
sequence. 

10. Fixed a bug in the AsnAny C code generation where an optional field
is incorrectly checked for its existence.

The eSNACC ASN.1 library is totally unencumbered as stated 
in the Enhanced SNACC Software Public License.  All source code
for the eSNACC software is being provided at no cost and with no
financial limitations regarding its use and distribution.  
Organizations can use the eSNACC software without paying
any royalties or licensing fees.

Point of Contact:
David Abarbanel
David.Abarbanel <at> BAESystems.com

Horvath, Tom (US SSA | 30 Oct 2006 21:59

v2.5.2 Secure Message Protocol (SMP) Now Available


All,

BAE Systems has delivered the Version 2.5.2 of the Secure Message
Protocol (SMP) Freeware Libraries for Microsoft Windows, Sun Solaris and
Linux. The patch is freely available from: 
<http://www.digitalnet.com/knowledge/download.htm>

SMP v2.5.2 includes the following enhancements (compared to v2.5.1 SMP
release):

1. Corrected a bug where certificates added to the database from a URL
are not found locally with the SRL_RequestObjs() function. 

2. Corrected a bug where certificates added to the database from a URL
do not include the flag to include the crossCertificatePair directory
attribute. 

3. Set the default LDAP client behavior from v2 to v3. 

4. Removed memory leaks from the ACL and SFL libraries. 

5. Fixed the incorrect algorithm in Findcrlissuer() function that was
causing performance problems. 

6. Fixed a code bug where the base class for a CRL is added to the cache
instead of the derived class. 

7. Delta CRL processing now occurs if the freshest extension is in the
CRL, not just in the certificate. 

8. CRL processing code now works around not having an AsnInt::operator
>() function by using < and == operators. Also fixed a problem with a
delta CRL being issued at the same time as a base CRL. 

9. Added support to more extended key usages in the CML. 

10. Removed a memory leak from the ACL. 

11. The code now considers a delta CRL applicable to a base CRL if the
CRLNumbers in the delta and base are equal. 

12. Fixed a problem with CRL updates to the database using improper hash
values. 

13. Can now build CML into static libraries. 

14. Various fixes in the ACL, CML, and SFL libraries. 

15. Now supports Crypto++ 5.2.1 and GCC v4.1.1 and below. 

16. Fixed a bug in the dbu_read_entry.

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

Point of Contact:
David Abarbanel
David.Abarbanel <at> BAESystems.com

Horvath, Tom (US SSA | 16 Dec 2005 19:18

RE: how far is SMP from being 64-bit clean?


Nick,

We do realize that some of the SMP code currently makes assumptions
about the size of certain types that will break when compiled using a 64
bit compiler.  We are eventually planning a 64-bit port of the SMP
libraries; however, the time frame has not yet been determined.  We will
keep the list informed as we decide upon a time frame.  If prior to our
decision anyone has contributions we will gladly accept them and try to
incorporate them into the baseline if possible.

Thanks,
Tom Horvath
BAE Systems IT
Tom.Horvath <at> BAESystems.com

-----Original Message-----
From: owner-imc-sfl <at> mail.imc.org [mailto:owner-imc-sfl <at> mail.imc.org] On
Behalf Of Nick Hudson
Sent: Friday, December 16, 2005 11:37 AM
To: imc-sfl <at> vpnc.org
Subject: how far is SMP from being 64-bit clean?

Has any qualification been done on the SMP libraries for 64-bit
environments?

I'm trying to build on SMP 2.5 on Fedora Core 3 x86_64, and although the
build
reports no obvious problems, I get errors at run-time which on
inspection seem to
be caused by the fact that there are some pieces of the code which are
not 64-bit
clean.

For example:

SRL_db.c has:
    SRLi_FlipLongs(le_data, numbytes >> 2);

while the function definition in SRL_util.c is:
    void SRLi_FlipLongs(void *data, long numlongs)

i.e. SRL_db.c is assuming that a "long" contains 4 bytes.  Furthermore,
inside
SRLi_FlipLongs(), there is various manipulation going on which also
seems
based on the assumption that a "long" is made up of 32 bits.

A cursory look through the code suggests that there is quite a lot of
usage of
"long"s, many of which appear to have similar problems.  So I wondered
whether
there's anything going on with 64-bit ports, or whether anyone has a
feel
for how pervasive these problems might be?

thanks

nick

Nick Hudson | 16 Dec 2005 17:37
Favicon

how far is SMP from being 64-bit clean?


Has any qualification been done on the SMP libraries for 64-bit environments?

I'm trying to build on SMP 2.5 on Fedora Core 3 x86_64, and although the build
reports no obvious problems, I get errors at run-time which on inspection seem to
be caused by the fact that there are some pieces of the code which are not 64-bit
clean.

For example:

SRL_db.c has:
    SRLi_FlipLongs(le_data, numbytes >> 2);

while the function definition in SRL_util.c is:
    void SRLi_FlipLongs(void *data, long numlongs)

i.e. SRL_db.c is assuming that a "long" contains 4 bytes.  Furthermore, inside
SRLi_FlipLongs(), there is various manipulation going on which also seems
based on the assumption that a "long" is made up of 32 bits.

A cursory look through the code suggests that there is quite a lot of usage of
"long"s, many of which appear to have similar problems.  So I wondered whether
there's anything going on with 64-bit ports, or whether anyone has a feel
for how pervasive these problems might be?

thanks

nick

Pawling, John | 12 Aug 2005 01:26

SFL/CML/ACL/eSNACC Support

All,

Our US Government sponsor plans to fund BAE Systems (formerly DigitalNet) to
provide minimal maintenance and technical support to the open-source,
freeware Certificate Management Library (CML), S/MIME Freeware Library
(SFL), Access Control Library (ACL) and Enhanced SNACC (eSNACC) ASN.1
libraries during FY06.  However, additional funds are required to
enhance these libraries to meet the evolving requirements of the user
community and to implement changes to the security standards required by the
Government.  

Earlier this year, BAE Systems delivered a new release of the SFL, CML, ACL
and eSNACC libraries which included support for new features such as the
On-Line Certificate Status Protocol (OCSP) and time stamp tokens.  There is
still a significant amount of valuable work that needs to be performed to
enhance these libraries.  Unless additional funds are provided by the
Government and/or other customers, we will be unable to make any further
significant enhancements to these libraries. 

The SFL, CML, ACL and eSNACC libraries are currently being used
and are planned for use in many applications to meet Government security
requirements.  We believe enhancements for these security libraries are
required in addition to basic maintenance support.  If your organization
requires enhancements to these libraries, please send me a message stating
your requirements.  If possible, please indicate the Government program that
will be impacted if the enhancements are not made.  I will forward this
information to our Government sponsor to discuss possible funding options
for your requirements.

Also, please inform me if your organization is interested in obtaining
additional enhancements and support for the aforementioned security
libraries directly from BAE Systems. 

See http://www.DigitalNet.com/knowledge/sec_libraries.htm for information
regarding the SFL, CML, ACL and eSNACC open-source, freeware libraries.

Thank you for your consideration of this request.

=============================
John Pawling
BAE SYSTEMS Information Technology
John.Pawling <at> it.baesystems.com
141 National Business Pkwy, Suite 210
Annapolis Junction, MD  USA  20701
=============================
Attachment (smime.p7s): application/x-pkcs7-signature, 4688 bytes
Horvath, Tom | 29 Apr 2005 20:17

RE: SFL Memory Leaks

Michel,

 

Good catch. I verified that both are indeed memory leaks and that your modifications were appropriate. We will include these modifications in the next SFL patch or release.

 

Thanks,

 

Tom Horvath
Principal Security Systems Engineer
_______________________________
BAE SYSTEMS Information Technology
141 National Business Pkwy. Suite 210
Annapolis Junction, MD 20701

tom.horvath <at> baesystems.com
(301) 939-2728

From: Michel Kinasz [mailto:MKinasz <at> iwsinc.com]
Sent: Tuesday, April 26, 2005 4:53 PM
To: Horvath, Tom
Subject: SFL Memory Leaks

 

Hello Tom,

I am using SFL 2.5 with visual studio 6.0.

I had to modify SFL sources to fix some memory leaks:

sm_SignBuf.cpp Line 226:

Changed

         if (*pTmpAlg == oidDigestEncryption)
         {
             break;
         }

To

         if (*pTmpAlg == oidDigestEncryption)
         {
             break;
         }
         else
         {
                free(pTmpAlg);
                pTmpAlg = NULL;
         }

 

sm_free3_RSA.cpp Line 2123

Added

        if (NULL != pszPasswordMAC)
        {
                free(pszPasswordMAC);
                pszPasswordMAC = NULL;
        }

Could you confirm that these modifications are valid?

Thanks,

Michel Kinasz
ImageWare Systems Inc.

 

The information contained in this transmission contains potentially privileged, export controlled and/or confidential information of Imageware Systems, Inc. or its customers or partners.  It is intended only to be read by the person(s) named above and for no other purpose.  You are hereby notified that any dissemination, distribution, duplication of this communication or use of its contents for any purpose not authorized expressly by Imageware Systems, Inc. is strictly prohibited and could lead to both civil and/or criminal penalties.  If you are not the intended recipient, you are prohibited to review the contents herein and please contact the sender by reply e-mail and destroy all copies of the original message.  To reply to our e-mail administrator directly, please send an e-mail to emailadmin <at> iwsinc.com

Horvath, Tom | 6 Apr 2005 20:35

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


All,

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 
<http://www.digitalnet.com/knowledge/sfl_home.htm>.  

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"
document.

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:
<http://www.DigitalNet.com/knowledge/cml_home.htm>.

The SFL has been successfully tested in conjunction with the Access
Control Library (ACL) that is freely available to everyone from: 
<http://www.DigitalNet.com/knowledge/acl_home.htm>.

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
labels.

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
www.BAESystems.com


Gmane