Re: [office] DSIG proposal - FYI

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

Hi

2009/1/5 Michael Brauer - Sun Germany - ham02 - Hamburg
<Michael.Brauer@sun.com>:
> Hi,
>
> On 05.01.09 14:26, Bob Jolliffe wrote:
>
>>>  2.2 In the <ds:Signature> element, there will be one or more
>>> <ds:Reference> elements.  Those elements will need to refer to Zip items
>>> within the ODF package for there to be signing of those items or elements
>>> within them (in the case that the item is an XML document).
>>>  2.3 It is probably important to point out that the use of relative paths
>>> in the <ds:Reference> element URI is subject to the interpretation for
>>> ODF
>>> 1.2 relative paths and that the reference is understood to be [in]to the
>>> uncompressed form of the Zip package item.
>>
>> If you go back to the long discussion we had about relative URIs in
>> ODF you might remember that I was a bit confused because current
>> implementations of ODF signatures do not actually follow the
>> convention ie. the base URI in these signature references is in fact
>> always the root of the package rather than relative to the file which
>> contains the reference.  This is historical and not much we can do
>> about it.  I don't want to mandate a behaviour which makes the only
>> existing implementations non-conformant.  What I would rather see is a
>> new interoperable signature format which uses XAdES basic signature
>> and "proper" relative URI's, at which point we can start to deprecate
>> the existing signatures.  So for the moment I'm silent on this one.
>
> 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.
>
> So, I think one may find arguments for and against both options, and I
> honestly don't know whether I consider the one or the other to be more
> correct.

You are right - an argument could be made either way.  And we don't
want to invalidate existing signatures.  Going forward we would have
to either:
(1) specify that this is the way relative URI's should be interpreted
in a digital signature, because of its particular role and place
within the package; or
(2) provide some mechanism for describing how relative URI's should be
interpreted for particular signature types or profiles.  This might be
one example of a metadata item to consider.

Regards
Bob

>
> Best regards
>
> Michael
>
> --
> Michael Brauer, Technical Architect Software Engineering
> StarOffice/OpenOffice.org
> Sun Microsystems GmbH             Nagelsweg 55
> D-20097 Hamburg, Germany          michael.brauer@sun.com
> http://sun.com/staroffice         +49 40 23646 500
> http://blogs.sun.com/GullFOSS
>
> Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
>           D-85551 Kirchheim-Heimstetten
> Amtsgericht Muenchen: HRB 161028
> Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
> Vorsitzender des Aufsichtsrates: Martin Haering
>
>