[xmlsec] Using XMLSec with other crypto engines
aleksey at aleksey.com
Wed Nov 6 01:28:14 PST 2002
Nobody prevent you from supporting native formats for your crypto library.
Again, all these functions were primerely written to run interop tests
in pem, pkcs12 and plain formats. If your crypto engine does not support
formats then this means that you'll not be able to run these tests
convert the keys to your crypto engine native format (however, this might
invalidate interop tests but it's another story).
And *nobody* forces you to use these formats in real application.
Tejkumar Arora wrote:
> Aleksey Sanin wrote:
>>> You mention above that these functions will likely be implemented for
>>> NSS. However, these file related functions don't make sense for NSS.
>> I really doubt that NSS does not have a function to load a cert from
>> a pem file. And if so then you might want to ask NSS guys to add it.
>> Most of the examples for xmlsec are based on the keys and certs in
>> the files. I would suggest to think about finding a way to support this.
> Well, that's a workaround not a solution :-).
> I understood that supporting NSS or whatever crypto lib means supporting
> its native environment properly.... so the xmlsec API should fit
> the crypto libs, not the other way around...
> If you had stuck EXCLUSIVELY to pkcs12 format (which is standard across
> crypto libs) in your APIs, things would have been slightly better but
> lacking the usability of supporting native formats.... The pkcs12 file
> is primarily used for transporting certs/keys.
>>> to handle crypto differences....
>>> By the way these functions are in keys.h, keysmngr.h, and x509.h,
>>> and I don't
>>> think are limited to the xmlSecSimpleKeysManager alone.. Here's a list:
>> All these functions are about loading keys and certs into keys and
>> x509 certs manager.
>> And they call each other.
More information about the xmlsec