FYI -----Original Message----- From: Dennis E. Hamilton [mailto:[email protected]] Sent: Saturday, August 13, 2011 12:08 To: 'Hanssens Bart'; '[email protected]' Subject: RE: [oic] FW: [ODFPlugtest] ODF 1.2 signatures
RECOMMENDATION 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 ANALYSIS 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 [mailto:[email protected]] Sent: Saturday, August 13, 2011 07:55 To: 'Hanssens Bart'; [email protected] 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. NEXT 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 <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> 8.2 The LibreOffice <SignedInfo> has <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> 8.3 The <Reference URI="mimetype"> digests are the same. 8.4 The <Reference URI="Configurations2/accelerator/current.xml"> digests are the same. 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 it. 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: <http://tools.oasis-open.org/issues/browse/OFFICE-3712>, 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 [mailto:[email protected]] Sent: Wednesday, July 27, 2011 08:11 To: [email protected] Subject: [oic] FW: [ODFPlugtest] ODF 1.2 signatures Hi, 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 Bart --------------------------------------------------------------------- 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: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
