PSARC/2009/374 libxmlsec

[Nicolas Williams]

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.

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

>     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?)

Nico
--