I've tried to knock down the security issue. I'm using Microsoft's data protection API (DPAPI) to encrypt the document. If it works as advertised, it should only be feasible to decrypt it 1) on the machine it was encrypted on 2) with secondary entropy known only to my app. This is happening on a Web server, so passwords are a bit problematic. (Part of the reason for using the keys file is that it's easy and fast to check if it's been updated and reload the keys. I gave serious thought to just loading PKCS12 files as you describe, though, so I have a pretty good idea how to perform a similar check on a directory's contents with reasonable efficiency.)
The logical issue is harder to solve. Unless one of us gets inspired over the weekend, I may have to abandon the keys file approach. -----Original Message----- From: Aleksey Sanin [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2003 3:51 PM To: Jesse Pelton; xmlSec Subject: Re: X509 data not reloaded from keys file 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. > > _______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
