RE: [office] DSIG proposal - URI vs.

["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.  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.

 - - - - - - - - -

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).  

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 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.)


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.  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).


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).

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?

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?  

 - 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

[ ... ]