[xmlsec] Transitioning custom XMLDSig verification implementation to xmlsec

[Aleksey Sanin]

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

http://www.aleksey.com/xmlsec/api/xmlsec-keysmngr.html#XMLSECKEYSTOREKLASS

The findKey method is the one you need.

* registering transformation URIs

Easy one :)

http://www.aleksey.com/xmlsec/api/xmlsec-transforms.html#XMLSECTRANSFORMIDSREGISTER

Aleksey

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
> `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
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
>