Re: [xml-dev] Normalizing and signing XML -- Xoxa

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2015-05-27 14:34 +0100, Norman Gray wrote:
> Normalising and signing XML is a well-known pain in the neck.
I think I disagree with that statement.

I undertook a project to sign UBL documents and inject into the UBL 
instance the scaffolding with which to contain its digital 
signature.  Features include adding multiple signatures and adding a 
"final" signature (such that at that point no further signatures can 
be added) [1].

I also recently created the library to sign BDE documents, that don't 
need scaffolding and simply put the digital signature at the end of 
the document (thus the library works with any XML document that 
accepts digital signatures as the last children of the document element) [2].

For both of these projects I used the free library:

  https://www.aleksey.com/xmlsec/

Given that the library exists and is free, I didn't find it a 
pain-in-the-neck at all.

> XML DigSig is hard because XML Canonicalization is hard
What evidence do you cite for that?  You state it in your blog post, 
but I'm trying to find out what it is that is considered to be hard to do.

This isn't an idle question:  I've never implemented canonicalization 
because I'm using it off-the-shelf, so I honestly don't know the 
answer myself to the question ... what is so hard about 
canonicalization?  When I looked at the specification long ago it 
seemed straightforward to me.

You say ...

> ; and that's hard because, I think, it's happening at the wrong 
> level (lexical rather than structural).
... and ...?  I don't see any explication of that statement.

> I believe it's possible to define an alternative canonicalization...
Possible, sure ... but alternatives are always difficult to elbow out 
established and already-implemented specifications that don't fail.

> which accepts a larger range of input documents as equivalent
Hopefully provided that the content of the information set is not 
different ... if two different infosets are considered equivalent, 
won't there be integrity issues?  If the infosets are the same, why 
use something other than the infoset?  Where is the difficulty with 
working with the infoset?

I just read the Gutmann paper you cited ... parts are 
disingenuous.  Reading the following "Much more worrying though is 
the fact that at the semantic level XML, like MS Word, consists of 
highly dynamic content, but about two orders of magnitude more 
complex than Word." near the start of the document immediately throws 
me off his perspective.  I disagree right there.  I don't think 
well-formed XML has semantics (other than inherent hierarchical 
relationships) and I don't think DTD-valid XML has very many 
semantics (other than referential integrity).  I believe XML defines 
syntax and users define semantics.

And that lead me to read the James Clark blog post that cites, among 
other things, about the awkwardness of signing things other than XML 
when combined with XML ... but I see that as out of scope of your 
post today.  Your post today is talking about the signing of an XML 
document, not a combination of XML and other stuff (or did I miss something?).

> , and which has fewer bells and whistles (and gongs and bugles), but 
> which is much simpler both to define and to implement. I describe 
> that in a preprint at arXiv [2], and it's illustratively implemented 
> in both C and Java in a library called Xoxa[3]
>
> I've expanded on this in a blog-post at <http://text.nxg.me.uk/2015/b65m>.
Your "normalization" looks a lot like James Clark's NSGMLS output ... 
was that your inspiration?  I've used that in my "n2x" free resource 
that converts SGML to XML [3].

How much of an XML processor is needed to create your 
normalization?  If one needs a conformant XML processor in order to 
create your normalization, how is it making things that much simpler 
than working with the infoset?  I thought a SAX processor gives one 
an infoset, and you are talking about using SAX.

> I'd be very interested in thoughts from ... xml-dev.
I think it would be a challenge to justify moving away from the 
established standards.

If two parties wish to do whatever they want with your specification 
or with any other non-standard way of expressing an XML document as 
being signed, that is up to those involved.  But there already exists 
a deployed solution for standalone XML documents.

I hope this is considered constructive.

. . . . . . . . Ken

[1]  http://www.CraneSoftwrights.com/resources/ubl/#digsig
[2]  http://www.cranesoftwrights.com/resources/#dsig
[3]  http://www.cranesoftwrights.com/resources/#n2x


--
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Free 5-hour lecture:  http://www.CraneSoftwrights.com/links/video.htm |
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/x/ |
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com |
Google+ profile:       http://plus.google.com/+GKenHolman-Crane/about |
Legal business disclaimers:     http://www.CraneSoftwrights.com/legal |


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com