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.

Hi Dennis

2009/1/5 Dennis E. Hamilton <dennis.hamilton@acm.org>:
> 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.

There is no major surgery required.  xml dsig processors simply have
to set a BaseURI to the root of the package.  Most implementations,
such as the JSR 105: XML Digital Signature APIs have a facility to do
exactly this.

> 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.)

Current implementations use the following convention for the
<ds:Reference> URL attribute:
 <Reference URI="content.xml">
 <Reference URI="Thumbnails/thumbnails.png">

The discussion is about the Base URI to be used rather than the root.
If there were no existing implementations, then I would have suggested
the same as you.  But there are and it doesn't make sense to make a
recommendation which will break all existing signatures.  So its about
deciding that URI's in signatures should always be treated as a
special case following Michaels reasoning, or whether we just find a
way to accommodate this in existing signature forms and find a way to
revert to a more 'ODF conventional' form when new forms of signature
are proposed (not here yet, but on the horizon).

> 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
> correctly.
>   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).

This does sound very tricky.  Unless you are talking about an embedded
signature for the un-packaged single xml form of an odf document.  In
which case it should be relatively straightforward - though not yet


>  - Dennis
> -----Original Message-----
> From: Bob Jolliffe [mailto:bobjolliffe@gmail.com]
> http://lists.oasis-open.org/archives/office/200901/msg00028.html
> 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
> Hi
> 2009/1/5 Michael Brauer - Sun Germany - ham02 - Hamburg
> <Michael.Brauer@sun.com>:
> http://lists.oasis-open.org/archives/office/200901/msg00018.html
> [ ... ]
>> 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,
> and
>> 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
> paths,
>> not URIs.
> [ ... ]

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