Subject: RE: [office] DSIG proposal - URI vs.
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:email@example.com] Sent: Wednesday, January 07, 2009 02:18 To: firstname.lastname@example.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 <email@example.com>: 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 [ ... ]