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


Inline - 

-----Original Message-----
From: office@lists.oasis-open.org [mailto:office@lists.oasis-open.org] On Behalf Of Svante Schubert
Sent: Tuesday, February 28, 2012 12:04 AM
To: office@lists.oasis-open.org
Subject: Re: [office] Digital Signature Concerns - Chain of Authenticity with Changes

On 27.02.2012 23:01, David LeBlanc wrote:
> We should have a provision for not putting external-data/... in the manifest - it is the easiest way to deal with it. The alternative is to make a transform on the manifest, but then we have to define the transform, current implementations break, etc. I'd even go as far as to suggest an external-data/META-INF.

[ss]Before proposing the design, could you rephrase the requirement of the external-data/ directory? Is this directory like an area that does not have to be signed? If this is the case, what shall we do if multiple users desire to sign content? (ODF work flow scenario).

[dcl] The concept behind external-data was to have a place to put files that will not be signed by a full document signature. Maybe it is metadata needed by some server - SharePoint does this sort of thing with OOXML signed files. What we really didn't define very well (which is largely my fault) in 1.2 was how it should work, and how it should interact with the actual manifest. We have to sign the manifest, and so it should not contain references to things in the unsigned area, which could be removed, changed, etc. We did not define that, and should have.

If you want multiple parallel signatures, then we already provide for that right now. There is a specific file for signatures, and any number of <Signature> nodes could be present. If you want countersignatures, then that's provided for as well through XAdES.

> Signatures and the current encryption scheme are completely incompatible and broken. This is really an independent discussion, and one I'd like to help solve for this release. IMHO, we should table that portion of the problem, and just focus on the desire to add comments, etc.

[ss]Even if this might be a topic for later discussion, please provide references, when claiming "encryption scheme are completely incompatible and broken". Otherwise your statement might be mistaken with spreading FUD.

[dcl] There is no FUD here. We had extensive discussions on this previously. It is well documented in the archives of this list. First, the current encryption approach has a good number of fairly serious cryptographic flaws, completely independent of signatures. We had what I thought was good agreement that it wasn't ideal, but we came to this conclusion very near the end, and there was no time to put together a proposal in time to ship in 1.2.

With respect to signatures, you have a big problem. So first consider the case of a signed document you wish to encrypt. The manifest has been signed, and cannot be changed without breaking the signature, but the encryption operation demands that the manifest be changed. This is clearly incompatible. In the second case, consider an encrypted document which has been signed. If you wanted to permanently decrypt the document, or even merely re-key the document - perhaps a password change - there is no possible way to do this without breaking the signature.

So the current encryption approach and signatures clearly cannot co-exist and still properly function. I think it is fair to term this incompatible. While 'broken' is perhaps an overly harsh term and I should apologize for that, you would certainly end up with a poor user experience. I'm also including the fact that the current encryption approach has multiple cryptographic flaws which are unrelated to signatures. Dennis Hamilton put together a list of (IIRC) 10 of these.

We also had some good discussion of alternative approaches that could be used to both correct the cryptography and solve the signed-encrypted problem, which we should resume and get into the standard for this release.

> BTW, the portion of XAdES that you want to use for (counter-)signature commentary is the CommitmentType element - it basically takes an extensible purpose for signing and an optional free-form comment field, and incorporates it in the signature. Thus, if the use case you're trying to support is making some comment on what the signature means to you, then we already have that, and it can be extended by leveraging counter-signatures, where you could have an entire Object element that contains rich information. Or the counter-signature could contain a reference to something in external-data/...
>
> What should not be done under any circumstances for a whole document signature is to alter the appearance of the signed content on the basis of anything added after the primary signature.

[ss]In the scenario provided to the collab list, new XML content (undo.xml) would be added to the package, referencing to the existing content. The existing content would not be altered.

[dcl] if you're trying to have some change tracking, I'm not sure that really works with a document which is previously signed. The point is that there should be no more changes.
Perhaps I'm confused what the user scenario is for adding the new XML content.

> Partial signatures are hard, both in terms of defining the spec, and in terms of implementation. Without a really strong customer demand that can't be solved any other way, I'd be very reticent to add it to the standard, especially without a prototype implementation.

[ss]Do you have a pointer to get up to speed on this topic. I would like to train myself some basics, before I get in contact with the Chaos Computer Club here in Berlin to get advise on this topic.

[dcl] yes - the most recent version of the XAdES spec is http://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.02_60/ts_101903v010402p.pdf  I've spent quite a bit of time on it, as we have quite a bit of it implemented for Microsoft Office. I'd be happy to help if you have questions. The XAdES standard doesn't really speak to partial document signatures - that's more for us to try and define - but it does have a bunch of complexity to it.


Thanks,
Svante
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Monday, February 27, 2012 11:25 AM
> To: David LeBlanc; 'ODF TC List '
> Cc: 'ODF TC Collaboration SC '
> 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
>
>
>


---------------------------------------------------------------------
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]