Hi All, Having a Streaming xml-sec library verification is my pet project. I have written the SAX patch (http://issues.apache.org/bugzilla/show_bug.cgi?id=32657) that it is use by several people in real world. And the still very experimental STaX patch http://issues.apache.org/bugzilla/show_bug.cgi?id=39029 . I'm accepting feedback & more important patches in any of the two things.
Right now I'm very busy with the 1.4 xmlsec release. When I will finish, I begin to work again in the Stax Implementation(finishing inclusive c14n and focus on memory instead of easy of debuging, right now everything is a string and thing is just appended to a the string). Anyway don't expect the same level of features from an tree memory backed several passes library like is the DOM one. To the streaming one pass Sax/Stax one. The first thing is lost is the xpath transform(there is no XPath support for Stax that I'm aware of), but several other things is gone also. So don't expect the Streaming library passing any of the test vectors published by w3c, they all relay in xpath transformations. But I think it will useful for verifying (large) document with known xml signature structs. Or for wire xml protocols(like saml or ws-security). Other problem is that streaming is relative easy for verifying but the other part of the equation signing is not solved at all. All in All, I am interested in streaming xml digital signatures verification. I have created two patches for different streaming parsing (Sax/Stax). I'm more than happy to accept any kind of feedback in any of this two ones. Regards, Raul On 8/7/06, Chris Black <[EMAIL PROTECTED]> wrote:
> > My question is this: Are there any efforts like this currently going > on in the community (none that I could find, outside of a largely > untested SAX based patch)? Nothing I know of, and I spent a fair amount of time looking a few months ago. > If not, would there be interest in helping to advance the state of the > code I have, and if possible modify it to follow the XML Signature > specification? Currently the code suits my needs, which are very > limited, and there would likely be significant effort in bringing it > up to spec. > > However, I feel strongly that a DOM based implementation can be not > much more than a reference implementation if we're ever to make XML > signature (and encryption) a part of large scale enterprise class > systems. > > Any comments or criticisms would be much appreciated. I also have my own very-limited subset of xml signature implemented via StAX. Unfortunately I use many calls to my own XMLUtil methods as well. I am using the XMLStreamReader/XMLStreamWriter rather than the event model as it is slightly faster and is what was being used in our application code already. My big hurdles have been c14n (should be doable for most cases fairly easily) and being able to generate digests in an efficient manner (as you may have already noticed, on reading the token-wise stream position does not necessarily match the position of the underlying stream the factory used to create the XMLStreamReader). I have tried a bunch of approaches with BufferedInputStream, etc without much luck so am currently running with a temp file workaround. I have an idea of how to make it work without this but haven't implemented it yet. I was also unable to integrate with the existing xml-security classes easily since so many of them are tightly coupled to DOM and on first look would need refactoring to be able to interoperate with non-DOM IO. The state of my current code is: Currently only supports detached sigs within enveloped files ([Env][Content][RealData][/RealData][/Content][Signature]...[/Signature][/Env]) Only supports SHA1/DSA keys, no certs or other algorithms Does not do C14N other than newline normalization to 0xA Is tied to our application code in that it uses XMLUtil convenience calls we wrote such as writeAttributes(XMLStreamWriter) and readElement(XMLStreamReader) I think my next immediate step would be a C14N implementation using StAX that was not tied to our utility methods. I already have the merlin w3c test files but haven't started dealing with c14n much yet. Chris
-- http://r-bg.com
