Other remarks: don’t forget to also get a timestamp from a trusted third party.

Actually, finding a trusted third party is the easy part here (I’m sure Certipost and the likes will be happy to sell you these services)

Agreeing on the rendering is difficult, that’s where ODF could take a page out of PDF’s book…
Or even better, PDF/A-1a. That is: no scripting, fonts must be embedded etc. (Yes Rob, I should write this down as a profile :-))

By the way, is font embedding scheduled for ODF 1.2 ? IIRC there was a proposal to include it, but I’m not sure if this is on the roadmap for ODF 1.2 or Next…

That would require sending the final from of the document to all parties. That largely defeats the point of electronic documents in the first place.

However, something similar would be to upload the document to a Web site, have it rendered in a Web app using the HTML <canvas> element or something, and then have the parties sign the document via the Web app. That's a bit better than sending a large set if image files or mailing it in paper form, though not much.

All:

I really think that if you don't have some baseline standardized rendering, you can't solve the problem of WYSIWYG document signing. For legal documents that must be signed, extensions that effect rendering can't be tolerated. Therefore, I suggest that prior to signing a legal document electronically, ODF applications must show the user a presentation of the document using ONLY the basic standardized rendering.

This would solve most problems, but I still see situations where people can exploit bugs in the software to hide content. Also, if people are able to get a hold of a person's digital signature, they could fake a document signing at will. Perhaps a Web-based application for signing documents is actually the cleanest way to do this. (Of course, that assumes the document hasn't been manipulated to exploit bugs in the Web app so that it emits content that is browser-specific, but that's rather unlikely.)

A trusted authority may be one solution. Another solution maybe to turn it into a trusted format (pdf, tiff, png, …(paper :-))).

Hans

Even if we both used the same platform software, different revisions of that software could introduce risk. It isn’t enough for the agreement to look the same to both of us today. It needs to look the same someday in the future such as when we end up in court.

On the other hand, it could be that neither one of us have trusted editors, but if there is a web site that allows is to upload our document and view a semantically equivalent version. So you don’t really need your editor to be trusted, but you do need to have access to a document renderer that is trusted and correct.

So it comes down to correctness and trust.

Suppose you from the provider of the office suite get a hash that show how an installed program should be then you are safe to sign…provided that you trust the OS that report the hash and that some authority verify that you indeed did get the reference hash from the real provider of the program.

If we move even more steps forward compilation from source code is not a fail proof solution either. The compilator can have been tampered with and do insertion of extra code when you build your program. This includes when building the actual compiler so having the compilers source code is not enough either.

The only way you stand alone can totally sure about the intrigity of the program is if you build OS, compiler, editors and program from scratch with extensive bootstrapping. (this is provided you can trust the hardware to flawless and non tampered with)

In all realistic cases your only option is to have a trusted authority. The effort to go without is simply not worth the money.

Fortunately the GNU ecosystem and its many eyes is pretty close to being such guarding force against tampering. The reason I say they are only pretty close is that GNU basically started from nothing so they can actually verify they don’t have poisonous software stack…provided that you trust the GNU people to begin with.

At the end of the day ODF standard can define how a application should act to claim to have signed a document, but there is no replacement of having a chain of trusted partners.

/Fiery Spirited

@Alex, I’m certainly in favor raising the bar for what an application must implement in order to claim conformance. We do have a feature set defined for the various application types, currently as an annex. I need to see how much support there is on the TC to turn these into conformance targets.

Interesting post. I think you put your finger on it when you say:

“The application used to view and sign the electronic document must conform to standard, specifically those stated parts of the standard necessary to render a semantically equivalent document.”

Is there any ambition to do the necessary work to make this possible for ODF? Currently a conformant ODF application is free not to render features of a document so there is no WYSIWYS guarantee arising from conformance to the spec. This could be solved by introducing something like OOXML’s “application description” feature. An application description could then be defined for ODF consumers so that they had to implement “those stated parts of the standard necessary to render a semantically equivalent document”, and there would be a guarantee that for such apps you should be seeing what other like apps would show.

- Alex.

That is why part of the specification is the provision for identification of transforms on the digital document that represents some canonical rendition of the visible content that is subject to the signature. It is my understanding that it is the transformation-derived rendition content that should be signed under the conditions that you set forth. Signature verification requires retransformation followed by the usual steps for cconfirmation of the digital signature(s) on the canonical renditions.

My understanding of the incorporation of XML DSig into ODF 1.2 working drafts, so far, is that no transformations have been specified for accomplishing this in a standard way with ODF packages.

I agree that it is not enough to sign untransformed canonicalizations of the XML Documents that are the parts of an ODF package, even with any extensions eliminated as part of that procedure. For example, it is not the formulas of a spreadsheet that would normally be signed, it is the presented values that are signed.

It should be clear that the application of XML Digital Signatures with respect to conventional office documents is quite challenging, involving substantial future work to be addressed satisfactorily in the specification and especially in implementations. The implementation on which the draft ODF 1.2 provisions appear to be based has not dealt with WYSIWYS at all, as well as I can tell.

As an extreme example, if the program has code that says if(user==”Rob Weir) then fee=fee*1.25 then we have a problem, right? We would sign the same document but actually not be agreeing to the same terms. So my question is what are the necessary properties of a file format standard that would ensure that this problem cannot occur. Certainly ASCII text documents or even a bitmap format would be safe. But is it possible to make strong assurances with more complicated formats? I think it can be done, and I’m outlining what I think the requirements are.

The semantics developed for this, through a pre-xml markup language called FSML, supported the necessary semantics for check payments, but in addition supported a flexible structure which allowed for the removal of document parts while maintaining the integrity of the signatures of other parts of the documents.

Some of the signature mechanisms eventually were used as input into the XML Digital Signature work, but I don’t think they survived intact.

If you are interested in more information on this, let me know. The effort was quite extensive.