> > 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? > Im'm not the author of it. The @author tag is filled by the CVS with the last guy who has commit the file. Anyhow I can try to answer your questions. Regarding the state machine I think was dessign to not permit what you are trying. i.e. that a xml readed signature can be modified by the program without sending an exception. And that's good idea, to catch problems when you think you are verifying something that you have recived when in reality what are you doing is just verifing something that you have created. Anyhow perhaps you can do a copyForModifing method, that copy everything and put the signature to MODE_SIGN again.
Hope it helps you, Regards, Raul > 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/ >
