There are some things that are "quite hard" problems doing it the other way
round. FIPS certification with the OpenSSL engine plugin active is probably
the worst.
With PKCS#11 on top of OpenSSL you have an "industry standard" API, which
most hardware cards support. So you could swap a FIPS certified hardware
card with a FIPS certified PKCS#11 on top of OpenSSL.  Using OpenSSL with
the engine code underneath doesn't make much sense in this context.

Note that IBM does have an open source PKCS#11 which sits on top of
OpenSSL, search for opencryptoki. That doesn't solve the FIPS problem
though due to some details of it's design.

There are downsides in PKCS#11, various vendors have interpreted the
standard in their own unique manner - so even though it's "standardized",
you still need some implementation specific code to function across vendor
implementations. It also has more (a lot more) setup overhead than OpenSSL
and although the user API isn't bad to implement, the provider side is
painful.

I can guarantee it's feasible, but it is a lot of work.

Peter




                                                                                
                                         
  From:       "Victor B. Wagner" <[EMAIL PROTECTED]>                            
                                        
                                                                                
                                         
  To:         openssl-dev@openssl.org                                           
                                         
                                                                                
                                         
  Date:       19/11/2007 20:27                                                  
                                         
                                                                                
                                         
  Subject:    PKCS#11 wrapper around OpenSSL                                    
                                         
                                                                                
                                         





I was asked by one user if we are planning to provide PKCS#11 module,
based on OpenSSL (it was in the context of adding GOST algorithms
support to the Mozilla-based software).

I doubt is this solution is technically feasable.

As far as I know, most people do it other way around - write interfaces
which allow to USE PKCS#11 modules from within OpenSSL. I've seen at
least two engines which interface external PKCS#11 modules, and both are
incomplete, so if there is a PKCS#11 module which implements new public
key algorithm, they wouldn't allow to use it.

But question is - is it a good idea to write PKCS#11 module which uses
OpenSSL (with all its engine support) for cryptography and supports
everything OpenSSL supports.

I haven't studied PKCS#11 specification in great detail - it is very huge.
 From the first glance it looks like just a big enough coding effort -
 OpenSSL contains all neccessary cryptography routines and ASN.1 support
 to provide PKCS#11 interface.

May be someone on this list hav dug a bit deeper in the PKCS#11
specification and can give more arguments pro or contra?

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


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

Reply via email to