On Wed, 2009-07-08 at 14:25 -0500, Nicolas Williams wrote:
> On Wed, Jul 01, 2009 at 11:36:33AM -0400, Brian Utterback wrote:
> >             A future ARC case could also switch us from using the OpenSSL
> >     module to a new module with more direct access to the crypto framework.
> >     Such a module would first need to be integrated in the community
> >     project.
> 
> What sort of module are we talking?  Where would it plug in?  There
> already is a way to access the Solaris crypto framework more directly
> than via the OpenSSL PKCS#11 engine: just use libpkcs11 directly.

        Writing a xmlsec security module for libpkcs#11 is a possible future
project if OpenSSL's engine support is not able to support keys by
reference in the near term.  However OpenSSL is the default crypto
provider for xmlsec and seems to provide better APIs for tasks around
certificates so a PKCS#11 xmlsec module that is an adequate replacement
for the OpenSSL one is non-trivial.

> 
> >     4.4. Out of Scope:
> >     
> >     Support for NSS keystores or usage of gnutls, or libnss in place of
> >     OpenSSL as the underlying encryption provider. 
> 
> Sounds like libxmlsec could use KMF.  You should talk to the KMF project
> team.

        A kmf/PKCS#11 hybrid module seems to be the only possibility aside from
OpenSSL or NSS that adequately covers the needed crypto operations and
certificate management operations.

        But this combination also doesn't solve anything for all store types so
its is not a worthwhile immediate investment.

        Meanwhile, OpenSSL solves the basic needs with no investment and can
potentially solve PKCS#11 requirements with small investment.

> 
> >     4.5. Interfaces:
> > 
> >     The libxslt[4] library is relocated to /lib but otherwise has
> >     the same status.
> > 
> >     The provided commands and underlying crypto provider are 
> >     Volatile and could change based on new bits from the upstream
> >     community and changes to the Solaris selection of crypto
> >     providers.
> 
> It strikes me that /usr/bin/xmlsec1-config should have the same
> commitment level as the API, i.e., Uncommitted in this case.   (Also, I
> thought that -config commands nowadays were being deprecated in favor of
> pc files.  Are there autoconf scripts that depend on xmlsec1-config?)

        I don't know.  I think I felt it prudent to provide whatever libxml2
and xslt provide, but I am on vacation and have no Solaris system handy
to verify this.

        Thanks,
        Will

> 
> Nico


Reply via email to