OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [office] DSIG proposal - URI vs.

I don't think it is that hard to choose.  I agree that it is rather
arbitrary which choice is made.

Here's my thinking:

1. [xml-dsig] specifies URI, so it seems rather difficult to borrow from
that namespace and not use the same scheme.  We can't easily insert the
package-root type with out major surgery on the xml-dsig schema to have an
alternative to the <ds:Reference> URL attribute. 

2. However, relative URIs (including those beginning with "/", ".", and
anything else other than a URI-scheme identifier) are subject to definition
by the application, especially where we are talking about resolution of
paths within an ODF package.  So for ODF, we have the freedom to say which
way it should work.

3. SUGGESTION: In this case I would recommend using the definition of 17.5
(which is in the package section for ODF 1.1 and which still needs to be
cleaned up to resolve some defect-report concerns) with the modification
that "/" is the root of the package and not of the directory containing the
package.  (It is important not to have to know the filename of the package
in order to refer to it.)

4. I see the following value in this choice:

   4.1. It is often the case that one wants to refer to siblings of a
detached-signature file in order to sign material in those siblings
(including the manifest.xml package item).  Reference to elements of the
same file is accomplished by xml:id and fragment identifiers, so that works

   4.2. It is useful to have a way to signify the entire package by "/"
(comparable to fragment ID reference "#" for an entire file) and effectively
have an embedded signature for it.  (This is rather tricky, as are all
embedded-signature cases, but it can be done so long as the file containing
the signature is not allowed to be compressed and the digest and the
signature will each be of known-in-advance fixed-length).  

 - Dennis

-----Original Message-----
From: Bob Jolliffe [mailto:bobjolliffe@gmail.com] 
Sent: Monday, January 05, 2009 13:25
To: Michael Brauer - Sun Germany - ham02 - Hamburg
Cc: dennis.hamilton@acm.org; office TC; Jomar Silva
Subject: Re: [office] DSIG proposal - FYI


2009/1/5 Michael Brauer - Sun Germany - ham02 - Hamburg
[ ... ]
> It is indeed an interesting question whether the rules we define for the
> resolution of relative URIs within packages should or should not apply
> to the relative URIs used within digital signatures.
> On the one hand, the references to the signed streams of zip files are URI
> references. Therefore, it may be reasonable if they follow
> the same rules that apply to relative URIs in a let's say content.xml.
> One the other hand, digital signatures are part of the package
> specification itself, and are for that reason stored in the META-INF
> folder which holds data about the package itself, rather than its content.
> Which means they occur on a different level. The paths in the
> META-INF/manifest.xml for instance all are relative to the package root,
> one may argue that other files in META-INF should not behave differently.
> The difference however is that the paths in the manifest.xml are just
> not URIs.
[ ... ]

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]