[jdom-interest] XML Signature
per.norrman at austers.se
Fri Sep 17 15:51:15 PDT 2004
David Wall wrote:
> That would be wonderful in my opinion. The more I can do with JDOM and not
> have to resort to DOM for processing XML the better!
Yep, that would be the point.
> My understanding is that the XPath with XML DSIG isn't even a true use of
> XPath, so you may find that no XPath solution really works for you. I'm not
> sure exactly what this all means, but it seems that the XPath isn't for
> traversing the XML, but for applying a test to each node as it's processed.
XPath is, or may be, used for selecting a certain subset of the document nodeset
that should be used for digesting or signature processing. Some of the example
use cases become, in my opinion, rather contrived; such as signing an already
signed document, or selecting disjoint parts and subtrees of a document.
> I think so, but then I wouldn't be able to directly contribute, though I'd
> be happy to test. In my own world, I only need pretty basic enveloped
> signatures (for wrapping XML deployment info to ensure that nothing has been
> tampered with -- probably doing an XML DSIG over the entire XML doc --
> starting with the root node), and detached signatures that can point to
> several XML elements (some of which are simple elements, and others that are
> complex and contain additional nested elements).
Yep, a glimpse of what I have in mind:
Enveloped signature, basic case (working):
XMLSignature sig = XMLSignature.sign(document, keypair);
XMLSignature sig = XMLSignature.sign(document, cert, privateKey);
Enveloping signature of one element, placed in an Object element:
XMLSignature sig = XMLSignature.sign(element, keypair);
XMLSignature sig = XMLSignature.sign(element, cert, privateKey);
Detached signature with document-internal ID references:
Document doc = ....
Element e1 = ...
e1.setAttribute(new Attribute("id", "element1", Attribute.ID_TYPE));
Element e2 = ...
e2.setAttribute(new Attribute("id", "element2", Attribute.ID_TYPE));
XMLSignature sig = new XMLSignature(doc);
Plus, of course, the possibility to override the default selection
of digest and signature methods, etc, etc.
> The question, though, is do we really need it since there's a JSR for
> standard Java APIs for DSIG? Is there a true benefit for having it work
> directly within JDOM? Can the API be truly simplified to handle 80+% of the
> XML DSIG needs? Or should we just get a DOM from JDOM and pass it into the
> standard DSIG APIs?
I don't know. Catering for a few basic signing scenarios is doable and verifying
for those same scenarios is also doable. But verifying an arbitrary document
implies a lot of work.
More information about the jdom-interest