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.


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]