Re: [office] DSIG proposal - URI vs.

["Bob Jolliffe" <bobjolliffe@gmail.com>]

Hi Dennis

You are much too prolific for me to keep up.  But I'm trying ...

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