[xmlsec] Re: X509 data not reloaded from keys file

[Aleksey Sanin]

Yes, you are absolutelly right. Unfortunately, this is a limitation
of the current 0.0.x design and I am not sure you can go around
it in a simple way. The keys file was not supposed to be used
in production environment because there are some security
(private keys in plain text!) and logical (which cert is the primary
cert?) problems around it.
I can try to think about solution for the 0.1.x branch but I am not
sure there is "good" one (actually, this is very close to the xkms
integration I thought about in 0.1.x but I am not ready to say how
this will be actually designed/implemented).

The best solution I would suggest is to use your own file format
to populate simple keys manager. For example, you can have
your keys stored in pkcs12 files and read a list of file from
simple plain text (or xml if you wish :) ) file. This will give you some
security: you can protect your pkcs12 files with passwords (in the
simplest case it'll be the same password for all pkcs12 files but it's
better than no password at all). IMHO, this is much better than plain
XMLish keys file. And implementation should not take long time
as well.


Aleksey



Jesse Pelton wrote:

>Keys file writing and reading is not symmetrical. If you generate a keys
>file using something like "xmlsec keys --pkcs12 file.pfx keys.xml", each
><KeyInfo> element in keys.xml has <KeyName>, <KeyValue>, and <X509Data>
>child elements.  When xmlSecKeyInfoNodesListRead() reads a <KeyInfo> node,
>however, it stops processing children as soon as it has succeeded in loading
>a key.  Any additional information is ignored.  If the <KeyValue> precedes
>the <X509Data>, the key is created from the <KeyValue> content, the
><X509Data> element is skipped, and so the certificate data is lost.
>
>I need the certificate information. Any suggestions as to how I can get it?
>I'll write my own version of xmlSecKeyInfoNodesListRead() if I must, but
>maybe I'm overlooking a cleaner solution.
>  
>