RE: Issues compiling auto_hi classes (and others issues)

Simon:

The following information answers #1:

1.)  You need to remove the references to RSA in your dependency list for
the BuildAll project(s).  You should remove all CTIL library builds you do
not have (spex, fortezza, pkcs11, etc.).  The project is setup to build all
CTILs.  No, you do not need the BSafe libraries to build autoHi; it is there
to facilitate testing (autoHi is our lo-level UDF test program).  There are
no compilation flags for general use of any CTIL; simply load that
particular DLL (e.g. sm_free3DLL.dll; see
SMIME/testsrc/util/sm_CfgLogins.cpp).

<snip>

Bob Colestock
VDA

-----Original Message-----
From: Nicholas, Richard [mailto:[email protected]]
Sent: Monday, March 19, 2001 1:31 PM
To: 'Simon Blanchet'
Cc: [email protected]
Subject: RE: Issues compiling auto_hi classes (and others issues)


Simon,

I'll leave question #1 for someone else, and try to answer #2.

> (Question #2)
> 
> From my understanding of SFL - CML - SRL now it looks like 
> CML (v1.9) is
> only used to provide Cert Path Validation and High Level 
> access to "the real
> implementation of a cert store".  The Storage is handled by 
> SRL.  I got some
> questions concerning CML vs SRL:
> 
> 2.1 Is there a way to use Crypto++ (instead of RSA BSAFE) for 
> cryptographic
> function needed by CML for path processing?  How?

The CML has two cryptographic interfaces, an internal one to make DSA,
SHA-1, RSA, MDx calls directly for signature verification, and the SFL CTIL
interface.  If you want to use the CTIL interface, simply provide a pointer
to a valid CSMIME object during the call to CM_CreateSessionExt().  (CSMIME
is sort of a container for CTIL instances.)

> 2.2 Is there a way to use SFL with CML (for path validation 
> processing and
> high level access to storage) with SRL (for storage only) and 
> finally with a
> custom-made CallBack_Function (only for certificate 
> retrieval).

Not with the current version of the SFL, which doesn't use the CML at all.
The next version (v2.0, I believe) will support some level of CML & SRL
integration.  Exactly how tightly they will be integrated is TBD.

> To be more
> precise:  Let's say that someone want to use SRL to store the 
> certificates
> but he don't want to use the default retrieval using a 
> LDAP_Client provided
> library.  What he want to do is more:
> 
> I- SFL needs someone's certificate to encrypt
> II- SFL calls CML to ask for certificate
> III- CML calls SRL to ask for certificate
> IV- SRL don't find the certificate asked for...
> V- CML (or SRL at this point?) use the "Custom_Made" CallBack 
> Function to
> retrieve the certificate
> 
> At step V let's just say that the certificate is not found 
> locally nor it is
> available to a LDAP directory.  The certificate can be found 
> at another
> place using a Custom_Made function...  I hope you got it.  
> The question is:
> Is it feasible?  How?
> I was reading in CML API doc (v1.9) that there are 3 
> different functions
> that can be provided to CM_CreateSessionExt()...  I have kind 
> of a idea
> about how to do it but I'm really not sure if it will work 
> (or if CML was
> designed for this specific case mentionned above).

As mentioned above, the current SFL does not call the CML.  I don't know if
the specific scenario you describe will be implemented in SFL v2.0 or not
(i.e., SFL calling CML to get a recipient's encryption certificate.)  I
suspect the finding of the correct recipient's certificate for outgoing
messages will likely still be an application responsibility.

I don't think the processing steps you listed above (I - V) would be the way
to go in any case.  The CML architecture already supports app-provided
callback functions for requesting objects (certs & CRLs).  (The CML
architecture was designed this way so that the SRL can be eliminated
altogether.)  I'd suggest you simply implement those callback functions to
call the SRL directly first and then if the cert or CRL is not found there,
then the function can call your app-specific retrieval/search function.

Hope that helps.

- Rich
---------------------------
Richard E. Nicholas
Principal Secure Systems Engineer
Getronics Government Solutions, LLC
[email protected]
(301) 939-2722

> |=========================================
> | Simon Blanchet
> | Software Designer
> |
> | Email: [email protected]
> |=========================================
>