Digital Signature Concerns - Chain of Authenticity with Changes

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

In today's discussion on change-tracking requirements, Svante raised an use case that is a common one in work practices involving review and revisions of documents and, in general, around turnaround documents in which progressively-modified documents are moved among authors and the provenance is verifiable at every stage. 

TAKEAWAYS: 

 1. It appears that ODF 1.2 Part 1 and Part 3 needs to be adjusted in some manner that allows insertion of "external-data/..." parts without invalidating signatures of the manifest.  

 2. At the same time, there is a problem of authenticating a document with particular "external-data/..." parts added.  

 3. In general, the current digital signature provisions, and the limited transform cases, are not suitable for signings of progressive versions that preserve previous signings.

- Dennis E. Hamilton
   tools for document interoperability,  <http://nfoWorks.org/>
   dennis.hamilton@acm.org  gsm: +1-206-779-9430  @orcmid


DETAILS:

On the 2012-02-27 call, there was mention of allowing changes to documents that preserve the signature of the version that is the base on which changes are made.

 1. As an aside, it was asserted that not all parts of a document need to be encrypted.  My objection to that was mistaken.  Thorsten Behrens is correct that choice of parts to be encrypted is entirely at the discretion of the producer.  ODF 1.2 Part 3 section 3.4.1 has the only normative statement that is made in this regard: "OpenDocument packages may be encrypted by encrypting some or all files within the package."  There are no conformance clauses that provide any additional conditions that would moderate 3.4.1.  My bad.

 2. With regard to digital signatures, the situation is different.  Although there may be any number of digital signature parts in a package, the META-INF/documentsignatures.xml file has specific characteristics, defined in ODF 1.2 Part 1 section 3.16: 

   "Document signatures shall be stored in a file called 
    META-INF/documentsignatures.xml in the package as 
    described in section 3.5 of the OpenDocument specification 
    part 3. Document signatures shall contain a <ds:Reference> 
    element for each file within the package, with the exception 
    that <ds:Reference> elements for the 
    META-INF/documentsignatures.xml file containing the signature, 
    and any files contained in the package whose relative path 
    starts with "external-data/" should be omitted." 

Also,

   "Signatures other than document signatures are implementation-
    defined."

That last refers to the full range of document signatures defined in Part 3, section 2.2.1(D), all having full-path names of the form "META-INF/*signatures* (the extension .xml is not required but is advisable).

Note that full-path (not relative path) "external-data/..." is a means for carrying information that might be added and not covered under the original signature.  How those parts might be used in the case of additions of some kind, and how they might be signed (and documentsignatures.xml counter-signed) is left open for implementations to work out.

There are current implementations that support counter-signing in META-INF/documentsignatures.xml.  There are no known implementations that will permit an opened document to be saved with existing signature preserved.  Countersigning is done in the stored form of the opened document, not by resaving an opened document.  When a consumer alters the opened form, there are usually warnings that saving that document will not have the previous signatures.

The provision for other META-INF/*signatures* files (Part 3) is in conflict with Part 1 3.16.  It appears that 3.16 requires that additional signature files must be covered by the META-INF/documentsignatures.xml signing.  Also, it appears that the META-INF/manifest.xml file must be included in the documentsignatures.xml signing.  This creates a conflict with any progressive-signing use case.  Packages section 3.2 requires that all but a few excluded parts must be represented in the manifest, and modification of the manifest will make the META-INF/documentsignatures.xml unverifiable.

There is some troublesome interaction between digital signatures and ODF 1.2 encryption as well.  However, it is difficult to imagine a document being progressively edited by an author that is not able to see its unencrypted form.  Progressive editing needs to allow additions to be added to the encrypted material, however, and that raises a problem for the signing of manifest.xml once again.