[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] DSIG proposal - URI vs.
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. 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. - 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:bobjolliffe@gmail.com] Sent: Tuesday, January 06, 2009 04:55 To: dennis.hamilton@acm.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 <dennis.hamilton@acm.org>: [ ... ] > 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. > [ ... ] > > --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]