RE: [office] DSIG proposal - URIs, Packages, and Namespaces - Proposal CORRECTION

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Bob, I think the problem is that it conflicts with the obvious
interpretation of the URL parameter when the expansion into a hypothetical
directory hierarchy takes place, in contrast with the Package section 2.6
rule which, under the stated 2.6 restraints, works the same either way
(ignoring the corner cases involving character sets and encodings).

In fact, if you simply said that the constraint on the xml-dsig <Reference>
URL is that it must target a sub-file of the same package, you'd be done and
be consistent with the 2.6 rule for interpretation of IRIs.  I think that
qualifies under point 2 of my recommended cure.

 - Dennis

PS: Does anyone know if the metadata RDF proposal use of URIs also going to
be an exception to Package section 2.6?  Lets not do that for any of these
borrowed standards that use URI in widely understood ways and that we have
not explicitly constrained very well.  The saving grace for manifest.xml is
the use of an ODF-specific definition for the manifest:full-path attribute.

PPS: Oddly, OO.o 3.0 will open and verify an OO.o 2.4 ODF 1.1 signed
document but it will refuse to sign such a document when in Save as ODF
1.0/1.1 mode.  It will only create signatures on documents saved as OO.o
documents with office:version="1.2" and then with the provisional OASIS
namespace that we have been using in the ODF 1.2 drafts and proposals.

PPPS: The requirement that the URI resolve to a file within the package is
different than saying the URI must be resolved against the root of the
package rather than the (hypothetical) location of the XML document within
the package (a statement that the current Package section 2.6 makes
concerning all uses of URIs in the XML documents of the package and that
17.5 made already for ODF 1.0 and ODF 1.1).  I don't feel responsible for an
existing undocumented implementation that makes an unexpected alteration of
the use of URI by the xml-dsig specification (and also made an exception to
17.5 in its implementation of a foreign extension to the ODF 1.1 package).
I think that is arguably a bug in the particular reliance on xml-dsig, and
the use of an alternative namespace confines the bug and allows
implementations to recognize its occurrence and automatically correct for it
if the implementers so choose.  That is one of the wonders of using
namespaces as a means for differentiation of semantics.  Specifications find
it necessary to break-from existing implementations (and bugs in earlier
versions of themselves) by using a different identifier quite often (a
common practice when there are bugs or defects in an API specification).  I
think this is an appropriate approach in this case, although the TC as a
whole will decide the matter.

-----Original Message-----
From: Bob Jolliffe [mailto:bobjolliffe@gmail.com] 
http://lists.oasis-open.org/archives/office/200901/msg00060.html
Sent: Thursday, January 08, 2009 02:01
To: dennis.hamilton@acm.org
Cc: office TC; Jomar Silva; Michael Brauer
Subject: Re: [office] DSIG proposal - URIs, Packages, and Namespaces -
Proposal CORRECTION

Hello Dennis

First of all, well spotted on the namespace.  I hadn't noticed that
OOo 3.0 had started using the new namespace..

2009/1/8 Dennis E. Hamilton <dennis.hamilton@acm.org>:
http://lists.oasis-open.org/archives/office/200901/msg00057.html
> My (3) in the original note doesn't make sense because I didn't alter the
> namespace in the "e.g." phrase.
>
> I have since confirmed, by generating some signed documents in OpenOffice
> 2.4 and 3.0, that there are indeed documents in the wild that use the
> "urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0" namespace as
> well as  "http://openoffice.org/2004/documentsignatures"; and in both cases
> the URIs look relative but are comparable to manifest:full-path values.
> [PS: With regard to recommendations about digest algorithms, I see only
> SHA-1 being used for digests here.  The signature itself uses PKI and, in
> the case of my certificate, SHA-1 is used as part of the PKCS #1 RSA
> Encryption.  I'm not worried.]
>
> Therefore, here is my revised solution to the dilemma, with the namespace
to
> be changed at once:

This solution is only required if we really see this as a dilemma.  I
admit when I first saw the use of these relative path URI's I thought
it was a bit odd, but in retrospect, I think the rationale which has
been provided is sound enough.  Indeed the 'convention' adopted has
the additional advantage that any URI's that may appear in files in
the META_INF directory must resolve to "files" within the package.
This is, in my opinion a good thing.  The only compelling reason to
allow other URI's would be if you wanted the signature to reference
something outside the package, which you wouldn't.  This is not odd.
For example, even though ECMA376 has quite a different packaging
model, I understand that the same restriction effectively applies -
signatures refer to parts within the package.

So the dilemma is not really a dilemma.  The main effect of your
proposed change would be to make existing implementations
non-compliant.  If this was necessary to solve a real problem, I would
support it, but I don't see that it is.

Regards
Bob

[ ... ]