Thanks for you reply Davanum. I would like to contribute and submit a patch, but before doing that, I think it is necessary to discuss these changes. I need some more background information about the existing code. Please, developers, give me some info about the states defined in the org.apache.xml.security.utils.SignatureElementProxy class. I need to know what the purpose of this state-machine is, since the usage of these states in derived classed are restricting the functionality I am looking for. Raul Benito, I believe you are the author of this SignatureElementProxy class, perhabs you can answer some of my questions?
Maarten Gerbrands Communication Networks Branch, Communication and Information Systems Division NATO C3 Agency -----Original Message----- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: vrijdag 22 oktober 2004 15:02 To: [EMAIL PROTECTED] Subject: Re: xmlsec-library lacks support for modification of existing signatures in XML Maarten, I'd encourage you to submit patches for portions of the toolkit that you think need more work...As usual, it's a work in progress and more hands are needed to make it more useful :) i will let others answer the specific questions. -- dims On Fri, 22 Oct 2004 13:11:42 +0200, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I am developing an editor for "XML Security Labels". A "XML Security Label" > includes the W3C XML Signature standard. > I am using your Java library as a toolkit for the creation, verification and > modifications of the XML signatures. > I find some parts of the library very inflexible, particularly the Manifest > class and Reference classes. > In order to use References the developer is forced to use the Manifest > class. > > Mainly the Manifest and Reference objects (classes) are limiting the > flexibility in my opinion. > . There is no possibility to remove existing references. > . It is not possible to create a Reference without inserting it into the > Manifest (since the Reference constructors are protected) . If the manifest > is generated from a XML-document, adding References will be ignored without > throwing an Exception. The "addDocument", method simply returns. > . Regenerating the digest values of the References will be ignored if the > Manifest have been constructed from an existing XML-document. > > Conclusion: > Library can generate XML signatures and store it in XML. > The stored signature can be verified without any problem. > (This is where all the sample scripts and tests are based on as well.) > If a more complex path is required, for example creation of the signature, > modify the signature, resign the signature, it seems to be nearly > impossible. > > Can somebody please explain to me why this state-machine (MODE_SIGN, > MODE_CREATE) in the ElementProxy objects exists and what the benefits are? > For what reason are the constructors of the Reference object not made > public, and why does the Reference need to be constructed with a Manifest > instead of a more abstract object or interface? > > Maarten Gerbrands > Communication Networks Branch, > Communication and Information Systems Division > NATO C3 Agency > > -- Davanum Srinivas - http://webservices.apache.org/~dims/
