[jdom-interest] XML Signature

[David Wall]

> > 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.

Well, XPath should be used for selecting nodes, but from what I gather, XML
DSIG has mucked up XPath and the tests specified are applied to EVERY node,
so you can't use nice paths like "/mydoc/something/doc/name" to select the
"name" element under the /mydoc/something/doc nodes.  I could be wrong, but
it sure looks that way.

> Yep, a glimpse of what I have in mind:
>
> Enveloped signature, basic case (working):
>
>     XMLSignature sig = XMLSignature.sign(document, keypair);
> or
>     XMLSignature sig = XMLSignature.sign(document, cert, privateKey);
>
> Enveloping signature of one element, placed in an Object element:
>
>     XMLSignature sig = XMLSignature.sign(element, keypair);
> or
>     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);
>     sig.add(new Reference(e1));
>     sig.add(new Reference(e2));
>     sig.add(certificate);
>     sig.sign(privateKey);
>
> Plus, of course, the possibility to override the default selection
> of digest and signature methods, etc, etc.

That would be very cool!  It would also be good if it could do the
sign/verify without requiring a certificate, but could do it all with just
keypairs.  This way, systems that don't rely on PKI-based certs would also
work well.

> > 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.

Well, it seems like if you can pick some good examples, that should suffice
for most.  It wouldn't be a general solution (and JDOM isn't either), but if
it took care of the most common scenarios and of course could validate
anything it could generate, it might be quite useful for certain
applications.

David