OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office] Digital Signature Concerns - Chain of Authenticity with Changes


There is an edge case that was missed in the ODF 1.2 specfication.  The META-INF/documentsignatures.xml appears to require that META-INF/manifest.xml be signed (and current OpenOffice-lineage implementations do so).  But there is no provision for omission of "external-data/..." in the manifest.  And changing the manifest breaks the signature.  META-INF/documentsignatures.xml does not itself appear in the manifest, fortunately (which means the signature can't be encrypted when the rest of the document is, however), and that applies to any other META-INF/*signatures* parts as well (* being the wild-card character).

This probably needs to be cleaned-up independent of any interest in progressive signing (as opposed to counter-signing, which can work already).

I agree about the difficulty of partial signatures in these kinds of packages.  

-----Original Message-----
From: office@lists.oasis-open.org [mailto:office@lists.oasis-open.org] On Behalf Of David LeBlanc
Sent: Monday, February 27, 2012 10:22
To: dennis.hamilton@acm.org; ODF TC List 
Cc: ODF TC Collaboration SC 
Subject: RE: [office] Digital Signature Concerns - Chain of Authenticity with Changes

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







---------------------------------------------------------------------
To unsubscribe, e-mail: office-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-help@lists.oasis-open.org





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]