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
