This is exactly why we incorporated a provision to have an unsigned portion of the package. You could certainly add any sort of additional information into the unsigned area.
A progressive signature may be accomplished in two ways. First, the XAdES specification provides for inclusion of countersignatures, which could be used to contain additional information, which would then be signed.
In the second case, a provision would need to be made to support partial signatures, which is a much harder problem.
I believe that the use case described could be achieved within the existing specification. Note that the additional information could be wholly contained within the countersignature, or could be a file within the external data. If that approach were used, then
we might need to change a must not to a may, but that's arguable.
Sent from my Windows Phone
From:
Dennis E. Hamilton
Sent:
2/27/2012 9:26 AM
To:
ODF TC List
Cc:
ODF TC Collaboration SC
Subject:
[office] Digital Signature Concerns - Chain of Authenticity with Changes
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/>
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.
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
