[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 specified. Regards Bob > > > - 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]