[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] DSIG proposal - URI vs.
Hi Dennis You are much too prolific for me to keep up. But I'm trying ... 2009/1/6 Dennis E. Hamilton <firstname.lastname@example.org>: > On reflection, I realize that there are a couple of ways to anonymously > refer to the package itself as an octet stream although it is definitely a > special case: > > If "/" refers to the (hypothetical) directory in which the package content > appears as a subdirectory, the canonicalization for message digest could be > that the package itself is the octet-stream canonicalization. This could be > extended to any "subdirectory" within the package although proper definition > is tricky. (It has to be as if there was a Zip that contained only those > items, I think, and there are some edge cases to nail down) Whether we need > to identify a canonicalization method for this is something that we can look > at for later. For now, I think the idea is to find an approach that does > not preclude this future option. > > This does get into the problem of embedding a signature in compressed > content, but there are already rules that should be adaptable provided that > (1) any <signature> element that ends up effectively signing the element as > part of its container is in an uncompressed item of the package and (2) the > usual rules for handling the signing of an object that embeds the resulting > signature are followed. (This sort of thing is already done when signing > executable code.) There would probably need to be an explicit statement of > the rules because of the need to have some dummy values in parts of the > signature process and in the checking process. Again, I don't think that > has to be resolved now, so long as it is not precluded for the future. An > application note or something on how to do this could come along later. > It's actually quite fun. Am I reading you right that you are talking about embedding a signature which effectively signs the entire zip container? If so then I think the zip specification (http://www.pkware.com/documents/casestudies/APPNOTE.TXT) already addresses how this should be done and I would see it as outside of our immediate scope. > > I am satisfied that, if we can align on what the URIs "/" and "." refer to > in the URL attribute of a <ds:Reference>, it will work, and having the Base > URL be the notional directory of the hypothetically-extracted package should > work once word-smithed properly. We might want to tidy up the ODF 1.2 > equivalent of 17.5 at the same time. In my understanding a digital signature in an odf document is supposed to apply to contents of the package of that document. In that sense, there is not really a case where a <ds:Reference> should dereference to anything outside of the package. So it should always be a relative path. There is no need to have Reference to a path beginning with "/" - I would prefer to see that as impermmissable. Regards Bob > > - Dennis > > PS: We do need to think about the situation of xml-dsig elements appearing > elsewhere than the top-level META-INF/ and whether we are precluding that or > not. (Sigh.) > > -----Original Message----- > From: Bob Jolliffe [mailto:email@example.com] > Sent: Tuesday, January 06, 2009 04:55 > To: firstname.lastname@example.org > Cc: Michael Brauer - Sun Germany - ham02 - Hamburg; office TC; Jomar Silva > Subject: Re: [office] DSIG proposal - URI vs. > > Hi Dennis > > 2009/1/5 Dennis E. Hamilton <email@example.com>: > [ ... ] > >> 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:firstname.lastname@example.org] >> 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: email@example.com; 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. >> [ ... ] >> >> > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >