[xmlsec] Transitioning custom XMLDSig verification implementation to xmlsec

Aleksey Sanin aleksey at aleksey.com
Fri Jan 24 08:55:50 PST 2014

Hi Krzysztof,

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:
> Hi,
> 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
> `<Manifest>`.
> 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
> context.
> 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
> 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.
> Cheers,
> Kris
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

More information about the xmlsec mailing list