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

[Jesse Pelton]

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:aleksey@aleksey.com]
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.
>  
>