PKCS#11 wrapper around OpenSSL

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

PKCS#11 wrapper around OpenSSL

Victor B. Wagner
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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 wrapper around OpenSSL

Peter Waltenberg
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" <[hidden email]>                                                                    
                                                                                                                         
  To:         [hidden email]                                                                                    
                                                                                                                         
  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                       [hidden email]
Automated List Manager                           [hidden email]


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 wrapper around OpenSSL

Victor B. Wagner
On 2007.11.19 at 20:46:36 +1000, Peter Waltenberg wrote:

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

Since 0.9.9 engine modules can add new algorithms, not only new
implementations (i.e. hardware supported) of existing algorithms.

My problem is actually to use existing implementation of GOST algorithms
(ccgost engine) in the Mozilla-based products. It seems that libnss already
includes some support for these algorithms if their implementation is
provided by PKCS#11 module.

Of course, it has nothing to do with FIPS. In this case, if we would
have to certify our solution it would be quite different certification
body. Actually, in this case we don't need certification of this module
at all (as well as ccgost engine is not certified by Russian
authorities). We need open-source implementation which can work in the
Mozilla and can be used for testing and debugging.

Really, I suppose not all users need FIPS-certified version of
cryptographic module. If server is FIPS-certified, client browser need
to be interoperable, but non neccessary certified. Suppose that client
is under another jurisdiction. It has its own certification bodies.
Or even under same jurisdiction it is not neccessary that private
person's browser has to be certified.
> 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.

It is interesting. I'd look into it.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 wrapper around OpenSSL

alon.barlev (Bugzilla)
In reply to this post by Victor B. Wagner
On Nov 6, 2007 11:07 AM, Victor B. Wagner <[hidden email]> wrote:
> 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 guess you mean software token... You wish to have PKCS#11 token that is
implemented using OpenSSL libraries.

PKCS#11 usually used in order to access hardware cryptography, it would
be nice if the engine interface of OpenSSL would have PKCS#11, it would
have been more standard, and allow supporting features that are not currently
supported by the engine interface, such as loading certificates from engine or
authenticating to the agent during usage etc..

In order to allow OpenSSL based application to use PKCS#11 properly with
minimum changes, I've written pkcs11-helper library [1].

But if you wish only have PKCS#11 soft token implemented using OpenSSL,
it should not too complex to achieve.

Best Regards,
Alon Bar-Lev.

[1] http://www.opensc-project.org/pkcs11-helper
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 wrapper around OpenSSL

Steven Bade
In reply to this post by Peter Waltenberg
OpenCryptoki's Soft token based on openssl, was never intended to be a
FIPS capable function,  its simply intended to be an example for those
who might wish to
a) test PKCS#11 applications without having to have a card
b) implement a token for an accelerator,  other examples in opencryptoki
are ICA (IBM Cryptographic Accelerator - which has also been permuted on
Z Linux to access what ever crypto exists in a CLEAR KEY format.), the
Broadcom support.

As peter points out, there are some design decisions in the accelrator
token model which preclude FIPS.  Integration of a FIPS module under OC
is possible, but the integration points need to be much higher up in the
actual token stack, because one really needs to be passing encrypted
"blobs" as keys to the module and have a true separation of the Module,
from the API... Possible, yes, just does not exist today

Peter Waltenberg wrote:

> 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" <[hidden email]>                                                                    
>                                                                                                                          
>   To:         [hidden email]                                                                                    
>                                                                                                                          
>   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                       [hidden email]
> Automated List Manager                           [hidden email]
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       [hidden email]
> Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 wrapper around OpenSSL

Steven Bade
In reply to this post by alon.barlev (Bugzilla)
I believe that Sun contributed a pretty robust PKCS#11 engine for openSSL.

Soft token exists in opencryptoki today,  if i ever find time, I will be
porting this to OSX
Alon Bar-Lev wrote:

> On Nov 6, 2007 11:07 AM, Victor B. Wagner <[hidden email]> wrote:
>> 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 guess you mean software token... You wish to have PKCS#11 token that is
> implemented using OpenSSL libraries.
>
> PKCS#11 usually used in order to access hardware cryptography, it would
> be nice if the engine interface of OpenSSL would have PKCS#11, it would
> have been more standard, and allow supporting features that are not currently
> supported by the engine interface, such as loading certificates from engine or
> authenticating to the agent during usage etc..
>
> In order to allow OpenSSL based application to use PKCS#11 properly with
> minimum changes, I've written pkcs11-helper library [1].
>
> But if you wish only have PKCS#11 soft token implemented using OpenSSL,
> it should not too complex to achieve.
>
> Best Regards,
> Alon Bar-Lev.
>
> [1] http://www.opensc-project.org/pkcs11-helper
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       [hidden email]
> Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 wrapper around OpenSSL

alon.barlev (Bugzilla)
On Nov 19, 2007 10:52 PM, Steven Bade <[hidden email]> wrote:
> I believe that Sun contributed a pretty robust PKCS#11 engine for openSSL.

It support a single static (compile time) provider, and even does not
login to the token...
I don't understand why it is packed as a patch and not as separate
shared library...
Anyway, from reading the code this is not really usable.

Alon.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 wrapper around OpenSSL

Jan Pechanec-2
On Mon, 19 Nov 2007, Alon Bar-Lev wrote:

>On Nov 19, 2007 10:52 PM, Steven Bade <[hidden email]> wrote:
>> I believe that Sun contributed a pretty robust PKCS#11 engine for openSSL.
>
>It support a single static (compile time) provider, and even does not

        the idea is that if you have pkcs#11 engine then everything else you
get through Crypto Framework to which you can connect hw providers.

>login to the token...

        there's a preliminary patch for that on blogs.sun.com/janp

>I don't understand why it is packed as a patch and not as separate
>shared library...

        crypto with a hole problem. Some countries didn't allow delivery of
such systems. I'm not sure if that's still the case, at least Solaris
(s10u4) is now shipped with the "strong" crypto -- keys above 128 bits etc.
That was the same problem -- not US export but import in some coutries until
recently.

>Anyway, from reading the code this is not really usable.

        correct, not with the current bits in Solaris (I guess we talk about
accesing tokens). We plan to work on that but it's not top priority for now.

        cheers, Jan.

--
Jan Pechanec
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 wrapper around OpenSSL

Peter Waltenberg
In reply to this post by Victor B. Wagner
I was just using FIPS as one of the examples where PKCS#11 OVER OpenSSL is
a potentially better solution than the engine backends.  I'm dealing with
FIPS certification issues all the time, so this was the obvious example -
it's caused me the most pain.
The other obvious problem is where you have to export crypto. code all over
the world - having the engine interface available in OpenSSL makes that
problematic.
I guess it's also potentially one less API for the hardware vendors to
support, they could just concentrate on implementing PKCS#11 - but getting
the OpenSSL PKCS#11 backend working properly would also do that. (I havn't
tried to use that, but I'm assuming from the other comments that there are
problems there now).

To make that really useful though, OpenSSL's SSL layer would have to be
capable of functioning while using PKCS#11 instead of libcrypto. Probably
possible, but it'd require some fairly major surgery. You'd really need
libcrypto. factored into "crypto" and "support" functions (like certificate
parsing/X509/OCSP etc) first.

Peter



                                                                                                                       
  From:       "Victor B. Wagner" <[hidden email]>                                                                  
                                                                                                                       
  To:         [hidden email]                                                                                  
                                                                                                                       
  Date:       19/11/2007 21:03                                                                                          
                                                                                                                       
  Subject:    Re: PKCS#11 wrapper around OpenSSL                                                                        
                                                                                                                       





On 2007.11.19 at 20:46:36 +1000, Peter Waltenberg wrote:

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

Since 0.9.9 engine modules can add new algorithms, not only new
implementations (i.e. hardware supported) of existing algorithms.

My problem is actually to use existing implementation of GOST algorithms
(ccgost engine) in the Mozilla-based products. It seems that libnss already
includes some support for these algorithms if their implementation is
provided by PKCS#11 module.

Of course, it has nothing to do with FIPS. In this case, if we would
have to certify our solution it would be quite different certification
body. Actually, in this case we don't need certification of this module
at all (as well as ccgost engine is not certified by Russian
authorities). We need open-source implementation which can work in the
Mozilla and can be used for testing and debugging.

Really, I suppose not all users need FIPS-certified version of
cryptographic module. If server is FIPS-certified, client browser need
to be interoperable, but non neccessary certified. Suppose that client
is under another jurisdiction. It has its own certification bodies.
Or even under same jurisdiction it is not neccessary that private
person's browser has to be certified.
> 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.

It is interesting. I'd look into it.

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


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 wrapper around OpenSSL

Victor B. Wagner
In reply to this post by Steven Bade
On 2007.11.19 at 14:51:16 -0600, Steven Bade wrote:

> OpenCryptoki's Soft token based on openssl, was never intended to be a
> FIPS capable function,  its simply intended to be an example for those
> who might wish to
> a) test PKCS#11 applications without having to have a card

It is what I need. Really there is just two applications I really want
to test - Firefox and Thunderbird.

But it is interesting to know how fully PKCS#11 specification is
implemented in OpenCryptoki. How much effort would be needed to add new
profile for new cryptography algorithms, which are supported by recent
OpenSSL, but, probably, never taken into account by authors of
OpenCryptoki.  
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 wrapper around OpenSSL

Peter Waltenberg
The only problem you might have with opencryptoki is that it can be hard to
build, and it can be "interesting" to configure the first time - BUT it
matches hardware cards in that.

As far as extending the algorithms go - check the PKCS#11 specs, make sure
the algorithms you want are already present, you'd need to update the
opencryptoki headers to provide the new definitions if those aren't up to
date. If they aren't in the PKCS#11 specs you have a problem.

For hashes and symetric ciphers it should be trivial, asymetric is ugly,
but not necessarilly difficult. It's mainly a matter of mapping PKCS#11's
key representation to the underlying crypto's. Check how RSA/DSA/DH are
handled now.

Good luck.
Peter




                                                                                                                         
  From:       "Victor B. Wagner" <[hidden email]>                                                                    
                                                                                                                         
  To:         [hidden email]                                                                                    
                                                                                                                         
  Date:       20/11/2007 16:45                                                                                          
                                                                                                                         
  Subject:    Re: PKCS#11 wrapper around OpenSSL                                                                        
                                                                                                                         





On 2007.11.19 at 14:51:16 -0600, Steven Bade wrote:

> OpenCryptoki's Soft token based on openssl, was never intended to be a
> FIPS capable function,  its simply intended to be an example for those
> who might wish to
> a) test PKCS#11 applications without having to have a card

It is what I need. Really there is just two applications I really want
to test - Firefox and Thunderbird.

But it is interesting to know how fully PKCS#11 specification is
implemented in OpenCryptoki. How much effort would be needed to add new
profile for new cryptography algorithms, which are supported by recent
OpenSSL, but, probably, never taken into account by authors of
OpenCryptoki.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 wrapper around OpenSSL

Steven Bade
In reply to this post by Victor B. Wagner
Victor B. Wagner wrote:
> On 2007.11.19 at 14:51:16 -0600, Steven Bade wrote:
>
>> OpenCryptoki's Soft token based on openssl, was never intended to be a
>> FIPS capable function,  its simply intended to be an example for those
>> who might wish to
>> a) test PKCS#11 applications without having to have a card
>
> It is what I need. Really there is just two applications I really want
> to test - Firefox and Thunderbird.

We have successfuly used it with Firefox and Thunderbird. We also tested
 (LONG time ago) with Netscape Web Server.

>
> But it is interesting to know how fully PKCS#11 specification is
> implemented in OpenCryptoki. How much effort would be needed to add new
> profile for new cryptography algorithms, which are supported by recent
> OpenSSL, but, probably, never taken into account by authors of
> OpenCryptoki.  

Adding new Mechanisms is pretty straight foward.  Corhent added the DH
mechanisms, and their developer was able to do it in about 1 month time.
 Some mechanisms maybe more difficult than others to integrate.

We tried to make the code modular and be extensible for new mechanisms
and new crypto providers, but that said, nothing is perfect.

We implement the full spec of API's, we don't implement all mechanisms,
that is not required of Tokens (I've never seen a token which implements
all the mechanisms).

Any questions etc, should be addressed to the opencryptoki mailing list,
which is linked to off the sourceforge project page.
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       [hidden email]
> Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

OpenSSL test dir and "dummyfile"

Peter Waltenberg
Anyone know what trips "dummyfile" being symlinked over files in the tests
subdir ?.

And more importantly - how to prevent that happening.

Thanks
Peter

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 wrapper around OpenSSL

Robin Bryce-2
In reply to this post by Victor B. Wagner
Hi Victor,

Not sure if this is a useful response, but here it is anyway!

In the context of both this thread and your other I had two key
difficulties in making pkcs#11, OpenSSL and apache play well together:

The first lay in the the fight to make the later two meet the
requirement that there be exactly one application library context per
process [p 17 PKCS #11 v2.2 6.6.1]. Given you are talking about apache
support of some kind, that problem remains regardless of whether you are
"under" or "over" openssl.

The second was password management, apache mod_ssl is *very* wedded to
PEM files and password protection thereof. For my case (Hardware
Security Modules) I simply wanted to turn it all off. In your case you
may be looking at providing coverage for all the password management
cases that are presently supported by apache. The httpd-dev list can
definitely better advise you on this one. IMV it is far from trivial.

http://www.mail-archive.com/dev@.../msg36902.html
http://issues.apache.org/bugzilla/show_bug.cgi?id=42687
http://issues.apache.org/bugzilla/show_bug.cgi?id=42688


To be clear, I am _not_ an apache developer nor even a contributer. I
once upon a time submitted a patch (commercially sponsored) and I don't
believe its gathered any interest from the community.


Other notes from the trenches:


* I found the lifecycle api and internal reference counting model used
by openssl's internals excessively complicated to deal with.
* Just precisely how some of openssl's process global state interacts
with apache's process, worker threads and shared memory is something I
still don't understand.
* Using bang up to date (trunk) apache for feasabillity work is a good idea.
* Pick a single apache MPM and don't bother about the others.

My guess is that this thread really belongs on http-dev, but in my view
the issues of mod_ssl development straddle many camps.

Best of luck ;-)

Robin


Victor B. Wagner wrote:

> 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                       [hidden email]
> Automated List Manager                           [hidden email]

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