RE: SFL, CML and Fortezza CTIL comments

Tom,

Thank you very much for your feedback regarding LJL's use of the SFL, CML
and Fortezza CTIL.  During the past weeks, we have been focusing our
resources on supporting Cygnacom's and Raytheon's use of the CML (including
Cygnacom's Cert Path Development Library), SFL and SPEX/ CTIL as part of the
Bridge Certification Authority (BCA) Demonstration that is testing
cross-certified Entrust, Motorola and Spyrus PKI domains.  Raytheon has
successfully integrated the SFL/CML into a plug-in for Novell GroupWise.
Cygnacom has successfully integrated the SFL/CML into a plug-in for Eudora
Pro.  We have used the Cygnacom/Eudora client to successfully verify a
signed message generated by the Raytheon/Novell client.  Cygnacom has
successfully completed interop testing between their SFL/CML/Eudora client
and an Entrust/Eudora client that they also developed.  Also, the CML/CPDL
has been used to successfully build and verify a cross certified path
between the Motorola and Spyrus PKI domains.  Testing continues.   

The aforementioned BCA testing has delayed our release of the CML designed
for use with the CTIL DLLs released in conjunction with the v1.1 SFL.  We
are also enhancing the CML to fix bugs reported during the BCA testing and
to use the libCert library provided as part of the v1.1 SFL release.  The
VDA CML development team has requested enhancements to the libCert library
to support the CML release.  These enhancements will allow the CML team to
take advantage of code already developed and tested as part of the SFL.  The
CML team is now testing these enhancements and will deliver a new release of
the CML after the testing is complete.  We plan to deliver a new SFL release
(v1.2) to include the enhanced libCert library.  We also plan to deliver new
CTILs including fixing the bugs that you previously reported.  The new CTILs
will also include enhancements made to the SPEX/ and Fortezza CTIL DLLs to
support the CML development effort.  We plan on delivering all of this code
during October 1999.

We have the following responses to your comments:

Bug #1: We will ensure that the ENCODE_BUF_NO_ALLOC macro is fixed in the
SNACC baseline.  If necessary, we will deliver a new SNACC release.

Bug #2: We will test and fix.  This will be fixed in the v1.2 SFL.

Bug #3: We also discovered this bug.  It is fixed in the baseline and will
be delivered with the v1.2 SFL release.

Bug #4: We will add these attributes in the next CML release.  Note: The
"mosaicCASignatureCertificate" attribute, when called via ext_get_objects
function, will have the CML CM_CA_CERT_TYPE set; the
"mosaicKeyManagementCertificate" & the "mosaicUserSignatureCertificate" will
have the CM_USER_CERT_TYPE set in the EncObject_LL structure.

Bug #5: We will add this to the next CML release.

Question #6: The CTIL API is documented in the CTIL API document available
from 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 CTIL API is not
proprietary.  To date, it is only being implemented by Van Dyke.  Given the
numerous "standard" crypto APIs, we doubt that any standards committees
would be willing to sponsor yet another standard API. 

Question #7: See above.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc.,
a Wang Government Services Company
[email protected]
============================================ 

-----Original Message-----
From: Thomas Fronckowiak Jr. [mailto:[email protected]]
Sent: Monday, September 27, 1999 5:35 PM
To: [email protected]
Subject: SFL, CML and Fortezza CTIL comments


We (LJL Enterprises) have continued our effort integrating the S/MIME
Freeware Library into our front-end.  Just a few things about
SFL and related items - I apologize if any of these issues are
off-topic for this list.

1. Encrypting large files
We've had a problem using SFL to encrypt large files.  This error occurred
when the total length of the encrypted data was over 100,000 bytes,
which is what the buffer size define VDASNACC_ENCDEC_BUFSIZE is
(sm_vdasnacc.h).

The new VDA enhanced SNACC that was just delivered had a fix in the
ENCODE_BUF macro (sm_vdasnacc.h)

	free(outputBuf.BlkPtr()/*pchBuffer*/);

This initially fixed the problem, until a few more 1000 bytes were
added to the message to be encrypted.

Modifying the ENCODE_BUF_NO_ALLOC macro with this same change fixed
the problem.

2. CSM_MsgToEncrypt ASN.1 Encode
I've experienced asn.1 encode problems particularly where additional
certificates were added to encrypted messages.  In some cases, and
this *seems* to be file-length dependant, a certificate which has
been added CSM_MsgToEncrypt::m_pMsgCrtCrls does not appear
in the EncryptedData, but the ASN.1 length that surrounds the cert
sequence includes the missing cert's length.  As a result, an inner
ASN.1 length is larger than then the entire ContentInfo length.

For example, four certs are added to CSM_MsgToEncrypt::m_pMsgCrtCrls,
only 3 show up in the EncryptedData, and the ASN.1 encoding from the
beginning of the ContentInfo looks like:

30 83 01 86 46
   06 09
      2A 86 48 86 F7 0D 01 07 03
   A0 83 01 86 36
      30 83 01 87 DE

Notice that length of the last sequence is greater than the
other lengths.

This was seen before the new VDA enhanced SNACC library was
integrated. I haven't spent much time on this but I will try the
same scenario with the latest snacc code.  Let me know if there's
any more info I can provide.

3. Fortezza CTIL
In sm_fort.cpp, CSM_Fortezza::SMTI_Decrypt() returns an error 7
(invalid data size) from ci_decrypt when decrypting a large
buffer because the wrong parameter is being checked against
largestBlockSize.

Line 758:
 if (pData->Length() > largestBlockSize )
should be:
 if (pEncryptedData->Length() > largestBlockSize )

Also in sm_fort.cpp,
	line 681:
            SME_THROW(error, "CI_Encrypt() faile", NULL);
	//failed

	line 734 :
	   SME_SETUP("CSM_Fortezza::SMTI_Encrypt()");
	//should be SMTI_Decrypt

	line 789:
           SME_THROW(error, "CI_Encrypt() failed", NULL);
	//should be CI_Decrypt

4. CML DSA attributes
What's the chance of getting DSA certificate attributes added to
the CML? To work correctly with current DSAs we needed to change
CM_ldap.c, to include:

	"mosaicCASignatureCertificate",
	"mosaicKeyManagementCertificate",
	"mosaicUserSignatureCertificate",

to the list of cert attributes:

static char* certAttribs[] = {
	"userCertificate",                  /* 2.5.29.36 */
	"cACertificate",                    /* 2.5.29.37 */
	"mosaicKMandSigCertificate",        /* 2.16.840.1.101.2.1.5.5 */
	"sdnsKMandSigCertificate",          /* 2.16.840.1.101.2.1.5.3 */
	"fortezzaKMandSigCertificate",      /* 2.16.840.1.101.2.1.5.5 */
	"crossCertificatePair",             /* 2.5.29.40 */
	NULL };

5. CML parsing CRL extensions

In X_CM_CRL.c, function cvt_CRL_IssuerDistPts(), the lines:

  if(data->onlyContainsCACerts != 0)	/* defaults to false if not here */
    who->only_cAs_flag  = *(data->onlyContainsUserCerts);

should be changed to:

  if(data->onlyContainsCACerts != 0)	/* defaults to false if not here */
    who->only_cAs_flag  = *(data->onlyContainsCACerts);

Note: This was found in an earlier version of CML and may have been
fixed in the latest release (v1.53?).

6. I was wondering about using the Fortezza CTIL for other applications in
order to have a common interface to the Fortezza card.  Is the CTIL
interface
a documented standard or is this a VDA construction? I'm almost certain it's
VDA. If so, is there any push to make this a more commonly accepted crypto
interface?

7. Has SFL v1.2 and the new CTILs been released yet? I know they were
scheduled
for earlier this month - I just haven't seen them yet.

Thanks,
Tom Fronckowiak