[xmlsec] Transitioning custom XMLDSig verification implementation to xmlsec

[Krzysztof Konopko]

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
`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.

Cheers,
Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20140124/859762a1/attachment.html>