On Wed, Jul 08, 2009 at 04:21:47PM -0400, Will Young wrote: > 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.
> [...] I didn't mean to get into a design discussion. I meant that it's not clear what "switch...from using the OpenSSL module to a new module" meant. But I think it was a thinko on my part: I think you implied that libxmlsec has "modules" and currently the only one is for using OpenSSL. > > 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. The nice thing about KMF is that it gives you a single interface to OpenSSL and NSS keystores. > But this combination also doesn't solve anything for all store types so > its is not a worthwhile immediate investment. I don't understand this last statement. > Meanwhile, OpenSSL solves the basic needs with no investment and can > potentially solve PKCS#11 requirements with small investment. Indeed. > > 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. The thing is that xyz-config programs are typically used in autoconf scripts (think ./configure) to auto-detect 'xyz' and compiler/linker flags needed to build against 'xyz'. On second thought, I think it's best not to worry about this (you might replace it with a .pc file later).
