Getting back to the specific problem.
It is unquestionably legal to use default namespaces on XML DSig <Signature>
elements and if that works best for interoperability, because of quirks in some
consumers, it would be good to *produce* them that way. This seems to be the
interoperability case that works everywhere.
On the other hand, if you are able to provide complete support for XML
Namespaces (which I believe is applicable to XML DSig in accordance with the
XML Schema), and handle the resulting canonicalization subtleties, you should
do so as a *consumer*, assuming it is confirmed that this is in accord with the
(normative) XML Schema (not the DTD) for the XML DSig <Signature> element and
its subordinate structure. (The ODF 1.2 specification assumes that prefixing
is allowed, but XML DSig is the normative source.)
With regard to consumers that apparently fail in the case of prefixes, such as
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#";
Id="MyFirstSIgnature">
<dsig:SignedInfo>
...
I think bug reports on those implementations are called for. Part of the
problem is that there is an unfortunate line in the first paragraph of
[xml-dsig] section 1.3 and there are no examples of prefixed element names in
the specimens within [xml-dsig]. There is in fact explicit acknowledgment of
prefixing, also in 1.3 and XPath specimens, but that is pretty subtle in
comparison with the reliance on a default namespace everywhere else.
Note that there are consequences for canonicalization of any parts of the
<Signature> element that are themselves signed and/or digested, and that has to
be dealt with by the producer and the consumer as well.
I believe the correct test case is that a <Signature> using the default
namespace could be replaced by a <prefix:Signature xmlns:prefix="...">
throughout and there should be no consequences on confirmation of the signature
so long as the prefix chosen does not create a child-element namespace clash.
If this actually works, I believe your implementation is safe on the consumer
side.
We might have to check with the W3C to confirm that and also have them fix the
first paragraph of 1.3 if the preceding assumptions are correct and the test
case works.
- Dennis
-----Original Message-----
From: Biao Han [mailto:[email protected]]
Sent: Thursday, August 04, 2011 23:15
To: [email protected]
Cc: [email protected]
Subject: Re: RE: [odftk-dev] Re: request help on ODF data signature issues
Agree with supply "standards mode" and "hacks mode". But the default mode
maybe prefer "hacks mode".
We don't want to see that users sign a document using ODF Toolkit, when
open with OOo/LO they find it doesn't work...
> From: Wolf Halton <[email protected]>
> To: [email protected]
> Date: 2011-08-04 23:49
> Subject: Re: RE: [odftk-dev] Re: request help on ODF data signature
issues
>
> +1 default_mode=standards_compliant
>
> On Aug 4, 2011 10:50 AM, "Hanssens Bart" <[email protected]> wrote:
> > Dare I mention "quirks mode" ? :-)
> >
> > In that case, I'd strongly suggest to make the standards mode the
default,
> > not the quirks mode (otherwise it's too easy to let this issue
> proliferate)
> >
> > Bart
> >
> > ________________________________________
> > From: [email protected] [[email protected]]
> > Sent: Thursday, August 04, 2011 4:36 PM
> > To: [email protected]; [email protected]
> > Subject: [odftk-dev] Re: request help on ODF data signature issues
> >
> > So, from the ODF Toolkit perspective, I think it would be best if we
had a
> > flag that the programmer could set, to make it operate in "standards
mode"
> > or "hacks mode" or something like that. It is useful to have a
"reference
> > implementation" mode where it follows the standard strictly. This could
> > be used for interop testing with other products. And it is also useful
to
> > have a mode that is compatible with current OOo/LO.
> >
> > -Rob
> >
> > Hanssens Bart <[email protected]> wrote on 08/04/2011 05:39:32
AM:
> >
> >> From: Hanssens Bart <[email protected]>
> >> To: "[email protected]" <[email protected]>,
> >> "[email protected]" <[email protected]>
> >> Date: 08/04/2011 05:40 AM
> >> Subject: [odftk-dev] Re: request help on ODF data signature issues
> >>
> >> Hi,
> >>
> >> As far as I can tell, these are known implementation issues.
> >> OOo (and most of the other products based on that code base) do not
> >> follow the spec IMHO.
> >>
> >> See also
> >>
> >> https://bugs.freedesktop.org/show_bug.cgi?id=39657 (ds namespace in
> >> LibreOffice)
> >> http://openoffice.org/bugzilla/show_bug.cgi?id=107864 (ds namespace in
> > OOo)
> >> http://openoffice.org/bugzilla/show_bug.cgi?id=66276 (multiple
> >> X509Certificate in OOo)
> >> http://openoffice.org/bugzilla/show_bug.cgi?id=108286
> >>
> >>
> >> Best regards
> >>
> >> Bart
> >>
> >> ----
> >>
> >> From: Biao Han [mailto:[email protected]]
> >> Sent: donderdag 4 augustus 2011 11:19
> >> To: [email protected]
> >> Cc: [email protected]
> >> Subject: [odftk-dev] request help on ODF data signature issues
> >>
> >> Hi all,
> >>
> >> I am the Apache ODF Toolkit developer and working on ODF data
> >> signature feature. Several issues need to help.
> >>
> >> 1. Different from other xml file, such as content.xml, why
> >> documentsignatures.xml is not namespace aware? For example,
> >> "Signature" element, only the local name Signature, not including
> >> "ds" namespace.
> >> 2. Why Open Office generates three same content X509Certificate
> >> elements for X509Data in documentsignatures.xml?
> >> 3. How to generate XML ID datatype value? UDDI is too short...
> >> OpenOffice
> > ID_003a00a40036005c0099001b004900a400960062003000c500f900e300af00f7
> >> UDDI ID_79200773-ec61-43d5-b079-a26a081bfb08
> >>
> >> Thanks & Regards
> >>
> >> Biao Han (Devin)
> >> SOA Standards Growth, Emerging Technology Institute(ETI), IBM China
> >> Software Development Laboratory
> >> Tel:(86-10)82450541
> >> Email: [email protected]
> >> Address: 3/F Ring Building, No.28 Building, Zhong Guan Cun Software
> >> Park, No. 8 Dong Bei Wang West Road, ShangDi, Haidian District,
> >> Beijing, P.R.C.100193
> >
