We generate all keys within our "tokens".... Some tokens such as the 
4758 keep all the token objects within the secure boundary, and rely on 
the proper PKCS#11 attributes to control selection, keys generated stay 
within the FIPS4 boundary.  Others which are accelerators, still use the 
PKCS#11 key generation calls (or object creation functions which could 
be done with the 4758 as well, but then these objects really can't be 
marked as NEVER_EXTRACTABLE because their origin is not really known or 
can be trusted).


I don;t remember exactly what the Trustway patch added, but it would be 
nice to allow for engine specific key generation to be used through the 
normal key generation paths, as well as allow for normal calls to be 
used to instantiate the CERT within the PKCS#11 token....

BTW, afchine, I for some reason always get 2 copies of ALL your posts to 
the mailing list...

afchine madjlessi wrote:

>  "Steven Bade" <[EMAIL PROTECTED]> writes:
> 
> 
>>I'm not sure about the second question, but we found that the eracom
>>engine submission was much more generic.   When one of my co-workers
>>tried to get our PKCS#11 libraries (openCryptoki) used by the Trustway
>>module there were many issues, as well as specific calls directly to
>>PKCs#11 functions rather than through the function list.   If I remember
>>correctly the Eracom submission from last year was much more generic and
>>we had to do nothing except point it to our shared library...  No
>>requirements for GKPCS11 headers, no direct function calls...
>>
>>
> 
> I think that in the case of Eracom card, keys are generated by an external
> way.
> Trustway card generates and stores keys, it's the reason of changes in the
> RSA methods.
> If needed, I can add the include files in the patch, so it doesn't require
> to get gpkcs11
> headers.
> 
> afchine
> 
> 


-- 
Steven A. Bade
UNIX Network Security Cryptographic Strategy and Development Architecture
[EMAIL PROTECTED]
T/L 678-4799
(512)-838-4799

--
To convert from Hogsheads to Cubic Feet - Multiply by 8.4219

"Two-way communication is necessary to proactively facilitate acceptance
and involvement and to get insights about the journey it takes to get where
we want"

this mess is so big and so bad and so tall,
we cannot clean it up, there is no way at all
(Cat in the Hat)



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to