[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] DSIG proposal - FYI
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]