Re: [office] DSIG proposal - URI vs.

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

Hello Dennis

2009/1/7 Dennis E. Hamilton <dennis.hamilton@acm.org>:
> Bob,
>
> The key part of this note is in (3)-(4) below, where I am having second
> thoughts.  For completeness, there is more information on Zip specifications
> and what ODF does and does not seem to normatively include.  I should have
> put these sections in a different sequence, with the backup analysis below
> the fold.  I am out of time on this for now.  Sorry.
>
>  - Dennis
>
> PS: If you want to confine the <ds:Reference> URI to using straight-forward
> package paths, the way the manifest.xml file does, there is a conflict with
> what is permissible as a URI form, even with the limitations of 17.5.
> Somehow overlaying the xml-dsig specification with a substitution seems a
> little tricky.  This might be the only way to treat the legacy of existing
> implementations though. In that case, I suggest specifying that the
> incorporation of <ds:signature> is modified so that <ds:Reference> does not
> use the xml-dsig URI attribute but instead uses the ODF manifest:full-path
> attribute.  There is probably more schema work required to pull this off.  I
> suppose one could do this in prose, but the problem is that the XML itself
> would not reveal that a special limitation on usable URIs applies.  Maybe
> the xml-dsig specification provides a way to accomplish this as part of an
> application-specific profile without changing the attribute.  It feels like
> we have painted ourselves into a corner here because of an implementation
> decision that is, so far, not offered in evidence.

In my message of 23/09/2008 I pasted in the relevant section of a
signature produced by openoffice (2.3 I think).  In case you missed
it, here it is again;

<SignedInfo>
     <CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
     <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
     <Reference URI="content.xml">
       <Transforms>
         <Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
       </Transforms>
       <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
       <DigestValue>2vBnfURPkfDXxUACDTOIwqlNcjg=</DigestValue>
     </Reference>
     <Reference URI="styles.xml">
       <Transforms>
         <Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
       </Transforms>
       <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
       <DigestValue>B2GzuX3I+kHqRYbvpZ3oHvHLW/s=</DigestValue>
     </Reference>


> Once we make a rule to
> only allow URIs that are interpreted the same as manifest:full-path, it is
> very difficult to ever get out of it.

I agree, but I can't see that we would ever want to get out it.  The
purpose of the signature is to sign what's in the document.  I really
don't see why we would want an ODF package to be the container of a
signature which refers to something else.  In fact I suspect we would
quite deliberately not want to do that.

>
>  - - - - - - - - -
>
> THE NOTE:
>
> 1. APOLOGY.  Bob, sorry for the confusion.  It is my understanding that "/"
> as a URI is considered a relative reference just like "." is (but I'm not
> signing that in blood and will check the URI specs again later).  It remains
> an useful question however.  (See 4, below).

Yes you are right (I think) but this very issue was discussed in that
same thread back in September.  The way Michael put it then was:
"This change is important, because it clarifies what we mean by a
relative-path reference. A relative-path reference is just a relative
path, and differs from the term relative URI. It is one kind of a
relative URI, but there are others. For instance, a URI starting with
a "/" is a relative URI, but it is not a relative path."
In line with this thinking I picked my words carefully above.  It (the
ds:Reference URI) should always be a relative path.

Just because one can create a digital signature with a reference to
any kind of URI, it does not mean that digital signatures used in ODF
should similarly be able to reference any kind of URI.  There are in
fact all manner of constraints one would want to place on such a
specific class (or classes) of signature.  This particular one, that
URIs should be relative paths which resolve to a stream within the
package, seems not to be unreasonable.

>
> As I recall, it's relative because the Base is needed to resolve it.
>
>
> 2. QUESTION: Where do you see a digital signature provision in the Zip
> specification?  [You can skip to (3) though.)
>
> The draft ODF 1.2 package specification and previous versions of ODF make
> reference to "[ZIP] Info-ZIP Application Note 970311,
> ftp://ftp.uu.net/pub/archiving/zip/doc/appnote-970311-iz.zip, 1997" which
> does not define a digital signature mechanism for Zip files, using
> "signature" mainly as a term for 2- and 4-byte magic numbers which are used
> to provide unique binary tags for different kinds of headers.
>
> The two exceptions are: (1) use of MD5 digests as a way to create
> near-unique identifier strings for files (not part of any signing or
> encryption function) and (2) indication that extra-field  Header ID 0x0007
> is reserved for the PK Zip Authenticity Verification (AV) header.  This
> proprietary feature is not defined here and I doubt that it is meant to be
> supported in the ODF Package.  It would also be great if ODF did profile
> what is required to be supported for ODF and that a better specification
> with some sort of authority were included via normative reference.
>
> Now, if we actually use the specification provided by PKWare at
> http://www.pkware.com/documents/APPNOTE/APPNOTE_6.2.0.txt (last updated in
> 2004), there are a variety of encryption methods and provision for a digital
> signature at the end of the central directory structure.  There are also
> extra-field Header IDs defined for digital signatures and certificates.  The
> only explicit description for the use of digital signatures is actually for
> encryption, not simply signing the Zip or any part of it.  A digital
> signature is used as part of encryption using public-key infrastructure,
> where the encryption (of the decryption key) is done using a public key that
> only a holder of the private key can decrypt.
>
> I don't believe this is a meaningful alternative to using xml-dsig, however,
> because (1) these PKware features are not completely specified, (2) these
> features are not normatively supported in any way in the ODF specifications,
> (3) the features seems dedicated to support of encryption, not simple
> signing of the package, and (4) PKware claims proprietary rights and
> prospective patent protection over (some of?) these provisions of the Zip
> format.
>
> There is more information about this at
> http://www.pkware.com/support/zip-application-note
> and I find the archive page particulary intriguing:
> http://www.pkware.com/support/application-note-archives
> with 6.2.0 being the only currently-provided APPNOTE.

The appnote I read was for 6.3.2
http://www.pkware.com/documents/casestudies/APPNOTE.TXT.  As far as i
can see there is nothing which says you can only use the signature as
part of the encryption mechanism.  Either way, my point was you should
probably be looking there if you are interested in signing the zip
file octet stream.  I don't think PKWare have patent protection in
South Africa for this stuff but I can still understand how it might be
a problem for everyone else :-).

>
> (The ECMA specification effort referred to on the PKWare archive page did
> incorporate a precise application profile for the compliant use of Zip
> packaging.  The last time I checked, dependence on any of the
> PKware-proprietary elements is carefully avoided.  Jomar and I disagree on
> whether ODF-relevant aspects are safe to crib by reference to IS
> 29500-2:2008, thus saving ourselves the effort of duplicating that thorough
> effort.)

One day we will might have a single package specification which might
well be a good day.  Mind you there are aspects of the Open Package
Specification which do have patent protection in South Africa.  We're
not going to solve these issues in a hurry.

>
>
> 3. SECOND THOUGHTS: On reflection since yesterdays posts, I am having a
> change of heart.
>
> Signing the entire Zip, creates two problems:  First, any alteration of the
> Zip breaks any signature that covers the entire Zip.

Which is why you need to make use of reserved headers and blocks
defined by the binary format with all the problems you mention above.

> Secondly, it is messy
> to determine whether or not the entire Zip has been signed or not.  (This is
> a problem in general where one intends to insert additional signature
> elements anywhere into part of a package that may already be signed.)
>
> So I am not so attached to signing the entire Zip, even though I think one
> should not rule out being able to extend from 1.2 to have room for it in the
> future (just in case there is a non-obvious but compelling use-case for it).

I think if there is a case for it, it would have to be handled quite
differently from the current xx-signatures.xml, because that file,
wherever it might be located within the package, of necessity is part
of the content (payload?) of the the zip.  Looking again at the zip
specification I can see how it might actually be done but I don't
think using an xml digital signature would make much sense here
anyway.

>
>
> 4. WHO DO WE BREAK WHEN?  It now seems to me, after considering more
> prospective use cases, that it is more natural to have the base URL be the
> hypothetical URI of the XML stream containing the <ds:Reference>.  This
> makes it natural to refer to peers, and it makes the treatment of the URI
> the same if the signature is created in a file hierarchy before the zipping
> and checked after unzipping (assuming no corner-case problems).  That is to
> say, the 17.5 approach [as eventually tightened up] should be used, since
> the URIs are then consistent with actually using a directory structure
> and/or being internal to the Zip package (and its hypothetical directory
> structure).

We come full circle.  I think it is probably neater to do it this way
as well.  But using a fixed base url also works, and there is a case
than can (and has) been made for it.  I can live with that.

>
> THIS BRINGS ME BACK TO MY EARLIER QUESTION: What implementations are known
> to be broken by our having 17.5 apply to URIs in <ds:Reference> URL
> attributes of digital signatures within packages?

As far as I know it is currently only openoffice and staroffice which
are well known examples.  But perhaps I speak out of turn.  Of course
there is also our own code which I have written to validate these
signatures.  Probably others have too.

> Also, in the approach used in these implementations, is URI
> "./META-INF/mumble-sig.xml" equivalent to "META-INF/mumble-sig.xml" or is it
> something else?

To the best of my knowledge these would resolve to the same thing.
Mind you the first form is not commonly seen.

With regards the proposal of Jomar and myself none of the above
discussion is directly addressed.  The current situation is that the
signature should be a valid xml-dsig and the rest is application
specific.  We have proposed that it is made clear that XAdES is a
legitimate way to extend the signature form.  Period.  I would like to
have specified this further but time has not been kind to me and there
are a number of issues (beyond the resolution of relative URI's) to
consider.  Including a flexible mechanism for describing different
signature forms and policies.  This will have to wait for the next
version to be done properly.

Regards
Bob

>
>  - Dennis
>
>
>
> -----Original Message-----
> From: Bob Jolliffe [mailto:bobjolliffe@gmail.com]
> Sent: Wednesday, January 07, 2009 02:18
> To: dennis.hamilton@acm.org
> Cc: office TC; Michael Brauer - Sun Germany - ham02 - Hamburg; Jomar Silva
> Subject: Re: [office] DSIG proposal - URI vs.
>
> 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>:
>
>
> 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
>
> [ ... ]
>
>