incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject FW: [oic] FW: [ODFPlugtest] ODF 1.2 signatures
Date Mon, 15 Aug 2011 18:03:51 GMT

-----Original Message-----
From: Dennis E. Hamilton [] 
Sent: Saturday, August 13, 2011 12:08
To: 'Hanssens Bart'; ''
Subject: RE: [oic] FW: [ODFPlugtest] ODF 1.2 signatures


We need an advisory that recommends use of a default namespace on <Signature> elements
in the META-INF/documentsignatures.xml.  

Producers should employ the default namespace binding in order to maximize interoperability
with existing implementations.

Consumers should be fully [xml-names] compliant and correctly consume <Signature> elements
with a prefix binding (e.g., <dsig:Signature> or a default binding).

There might need to be additional advice with regard to child elements that are signed separately
(to achieve the proper canonicalization).  There also needs to be identification of the canonicalizations
that are to be recognized.

Finally, we should get clear on what should be in the manifest and what should be signed versus
what might also be in the manifest and what might also be signed whether or not in the manifest.

 - Dennis


OK, I think I have configured my XML Editor to assess XML Schema compliance for instances
of an XML DSig.

According to the schema checker, there is no problem with your original file (with ds prefix)
or with the one with default namespace for the <Signature> element.

So as far as the XML Schema goes, it looks like there is no prohibition for using a prefix-binding
namespace declaration instead of a default namespace declaration.

The XML DSig specification says the XML Schema is normative, the XML DTD is not.

I downloaded the XML Schema and the XML DTD from the links in the W3C specification.  

I notice that the DTD does not use parameter tricks to allow use of a prefix-binding on the
namespace.  So the DTD is written to use a default namespace.  But that is not a requirement.

-----Original Message-----
From: Dennis E. Hamilton [] 
Sent: Saturday, August 13, 2011 07:55
To: 'Hanssens Bart';
Subject: RE: [oic] FW: [ODFPlugtest] ODF 1.2 signatures

Hi Bart,

I finally got around to messing with your signed document having XAdES-supplemented signature.

I did a simply thing.

 1. Confirmed that the version you created opens in LibreOffice 3.3.2 as if there is no signature
at all.

 2. Extracted the META-INF/documentsignatures.xml file and noticed how the <ds:Signature>
is recorded with a namespace prefix on the Element tag QNames.

 3. Systematically removed the ds: prefixes on start and end tags.  Changed the namespace
declaration from xmlns:ds= ... to xmlns= ... .

 4. Replaced META-INF/documentsignatures.xml with the modified file using WinZip.

 5. On opening the modified document with LibreOffice 3.3.2, the existence of the signature
is recognized and the signature is reported as being invalid.  The Test-issued certificate
 is recognized and identified as not being verifiable also. 

 6. This is a hint to me that there is a canonicalization problem around handling QNames and
namespace bindings.


 7. I saved the "suspicious document" so that there was no signature on it, and then signed
it myself.

 8. I compared the two digital signature documents to see what was different other than the
use of QNames and namespace binding:
    8.1 The XAdES <SignedInfo> has 
    8.2 The LibreOffice <SignedInfo> has
    8.3 The <Reference URI="mimetype"> digests are the same.
    8.4 The <Reference URI="Configurations2/accelerator/current.xml"> digests are the
    8.5 The <Reference URI="META-INF/manifest.xml"> digests are different and the Transform
algorithms are different the same way the CanonicalizationMethod elements are different.
    8.6 The <Reference URI="content.xml"> digests are different (cf. 8.5), and this
continues for all of the XML files.
    8.7 Although manifest.rdf is an XML file, LibreOffice defaults the transform for it. 
There is no manifest.rdf in the XAdES-signed document, and hence no <Reference> for
    8.8 The LibreOffice 3.3.2 signature also signs Thumbnails/thumbnail.png.  The XAdES signature
excludes that file.

 9. Not much information there.  I don't know that the canonicalization / transform URIs being
different matters or not.

 10. I also wonder whether the reason for using a default namespace is in order to have canonicalization
work.  I looked up XML DSig and it is the XML Schema that is normative, not the DTD, but I
don't understand the interaction between XML Schema and XML Namespaces to know if using an
explicit prefix binding is not allowed in the schema or not.

 11. FROM AN ADVISORY POINT OF VIEW I would recommend that the default namespace be used by
producers but that consumers process namespaces correctly.  I haven't dug deep enough to understand
if there are canonicalization issues that go with binding namespaces in different ways or
LibreOffice just gets it wrong.  The ODF Toolkit folks are struggling with this same problem.

 12. Note that this ODF Issue was inspired by this situation: 
<>, although I think the digital
signature problem is specific to DSigs and not a problem with namespaces in general.

 - Dennis

-----Original Message-----
From: Hanssens Bart [] 
Sent: Wednesday, July 27, 2011 08:11
Subject: [oic] FW: [ODFPlugtest] ODF 1.2 signatures


As mentioned during today's conference call, I'm trying to get our eid applet in line with
ODF 1.2 signatures.

In attachment the unsigned test document and a signed copy (XAdES, although the XML-DSIG part
should be recognized by ODF consumers implementing signatures).
Now, the unsigned document wasn't 100% ODF-1.2 valid to begin with, but after signing :

- a validator complained about missing a META-INF/documentsignatures.xml file entry in manifest
(not mandatory per spec ODF 1.2 part 3, section 3.2)

- other consumers either ignored the signature because they don't like namespace prefixes,
or crashed

Feedback is welcome of course

Best regards


To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at: 

View raw message