[xmlsec] Transitioning custom XMLDSig verification implementation to xmlsec
aleksey at aleksey.com
Fri Jan 24 08:55:50 PST 2014
Let me try to answer your questions one-by-one
* IO handlers
To handle the context, you can use a trick with thread local storage:
you can set your data in TLS before calling XMLSec, then use this
data in the context, and cleanup after XMLSec is done.
* additional certificate/key checks
You can also look at implementing a custom keys store
The findKey method is the one you need.
* registering transformation URIs
Easy one :)
On 1/24/14, 5:09 AM, Krzysztof Konopko wrote:
> I'd looked briefly at xmlsec a couple years back when my task involved
> XMLDSig verification. I couldn't find a way a couple of my use cases
> would be handled by xmlsec. So due to the time pressure and
> unfamiliarity with the subject I implemented the verification myself.
> Now when the implementation runs in a real product, I have a chance to
> revisit it and am looking at xmlsec again. Basically I'd like to
> replace my implementation with xmlsec.
> I'm having a closer look now, reading the API more carefully and digging
> in the source code. But it looks like I'm stuck with a couple of problems.
> What I need to do is to verify a file bundle (a ZIP archive) with
> XMLDSig file in it, having a `<Manifest>` with the list of
> `<Reference>`s (files in the archive) and their `<Digest>`s. And I want
> it to be verified without unzipping it onto disk (this is what my
> implementation does).
> When it's unzipped, it's easy. xmlsec simply handles all of it. Since
> the signature is created by Java XMLDSig implementation (I have no way
> to change it), there are few incompatibilities. One of them was white
> spaces removed before running C14N over the transformed part of the
> document. I worked it around by calling `xmlKeepBlanksDefault(0);`. Easy.
> So now I'm looking for any pointers for the problems listed below. I'm
> trying to work them out myself but maybe someone could save me some time
> and point me in the right direction.
> * IO handlers
> Reading the file with signatures from the archive seems easy. Just read
> it into memory from the ZIP archive and load the document from memory.
> But then I need to read the other files from the archive
> when `xmlSecDSigCtxVerify()` goes through each `<Reference>` in the
> I'm a bit surprised that `xmlSecIORegisterCallbacks()` doesn't let to
> pass any user data (context). It's great that `xmlInputOpenCallback`
> returns whatever I like, but I need my context much earlier, in
> `xmlInputMatchCallback` and in `xmlInputOpenCallback` itself. In my
> case this would be a handle to an opened ZIP archive (or whatever
> related context) that would deal with all requests to find, open and
> read files from the ZIP archive without writing them onto disk.
> Is it reasonable to set `referencePreExecuteCallback` and replace the
> first transformation (reading a file from disk) with my own one (reading
> a file from the ZIP archive)? It looks like
> `xmlSecTransformCtxUriExecute()` always creates
> `xmlSecTransformInputURIId` so no chance to inject my own transformation
> there? Or am I missing something?
> * additional certificate/key checks
> I'm using OpenSSL and I need to add some product specific checks
> (policies and some other certificate rules) and then extract policies
> tree once verified. This all is pretty much achieved with setting
> verification params and getting some information from the verification
> With my own implementation this is pretty much obvious while xmlsec
> doesn't seem to expose neither `X509_VERIFY_PARAM` nor `X509_STORE_CTX`.
> Am I right? So probably I'm better off with
> `XMLSEC_KEYINFO_FLAGS_X509DATA_DONT_VERIFY_CERTS` and running
> certificate chain verification myself?
> * registering transformation URIs
> I've got a bunch of legacy transformation URIs
> like http://www.w3.org/TR/xmldsig-core#rsa-sha1. How do I associate
> them with existing transformations in xmlsec?
> Apologies for this being a bit longish. I hope it all makes sense and
> you're able at least suggest me "this is not possible, sorry", or "check
> this or that". Any suggestions are more than welcome.
> xmlsec mailing list
> xmlsec at aleksey.com
More information about the xmlsec