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 > [email protected] > http://www.aleksey.com/mailman/listinfo/xmlsec > _______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
