incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: RE: [odftk-dev] Re: request help on ODF data signature issues
Date Fri, 05 Aug 2011 16:32:09 GMT
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:hanbiao@cn.ibm.com] 
Sent: Thursday, August 04, 2011 23:15
To: ooo-dev@incubator.apache.org
Cc: ooo-dev@incubator.apache.org
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 <wolf.halton@gmail.com>
> To: ooo-dev@incubator.apache.org
> 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" <Bart.Hanssens@fedict.be> 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: robert_weir@us.ibm.com [robert_weir@us.ibm.com]
> > Sent: Thursday, August 04, 2011 4:36 PM
> > To: dev@odftoolkit.odftoolkit.org; ooo-dev@incubator.apache.org
> > 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 <Bart.Hanssens@fedict.be> wrote on 08/04/2011 05:39:32
AM:
> >
> >> From: Hanssens Bart <Bart.Hanssens@fedict.be>
> >> To: "dev@odftoolkit.odftoolkit.org" <dev@odftoolkit.odftoolkit.org>,
> >> "ooo-dev@incubator.apache.org" <ooo-dev@incubator.apache.org>
> >> 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:hanbiao@cn.ibm.com]
> >> Sent: donderdag 4 augustus 2011 11:19
> >> To: ooo-dev@incubator.apache.org
> >> Cc: dev@odftoolkit.odftoolkit.org
> >> 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: hanbiao@cn.ibm.com
> >> 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
> >


Mime
View raw message