Improving The Digital Signature Feature

Objectives

Digital signatures on documents can be very useful. What may prevent people from using them are

• complicated usage
• unclear legal status

The first could be solved by a better implementation. For example, for non-Windows user it is quite complicated to maintain their private keys and certificates, because OpenOffice.org (OOo) does not use a system provided key store. Instead the key store of the default profile of Mozilla/SeaMonkey, Firefox or Thunderbird is used. There is no indication or preferences setting as to what key store is to be used.

The second issue is the more complicated one. Different countries and companies may have different requirements for digital signatures. These may affect the type of signatures, such as XML digital signature or Cryptographic Message Syntax (CMS), and used algorithms (hash algorithms, signature algorithms, signature / certificate validation algorithms.) Particularly the validation aspect can be very tricky. Because of the complexity of the validation algorithms and the lack of an legally accepted international standard, it is likely that the signature that complies with legal regulations in country A cannot be used in country B. Therefore it is necessary to provide solutions which are adapted to local requirements.

However, even if a product claimed to comply to those regulations, it would still be a risk to use the signatures unless it becomes certified by some legally accepted organization. For example, a company would not replace paper-written sales contracts by electronic documents because it could turn out later that some flaw in the signature implementation renders all signatures invalid. On the other hand a certified product can give some sort of assurance and help to promote the use of signatures.

Providing a certified signature implementation which can be used everywhere is a huge task and possibly not practical. Certification will certainly cost money and time and it may be necessary to repeat the certification process for every new release of OOo. Therefore the particular implementations and certification should be provided by interested parties.

The signature framework proposed in this document aims at making it easier for them to provide signature components for OOo. But it shall also enable users to easily configure different signature components which are installed in OOo. Those signature components will be distributed as OpenOffice.org extensions and can therefore be updated independent of OOo.

Definitions

Signature Component - Consists of code and data needed to create and verify a digital signature applied to an ODF document. It is delivered as OpenOffice.org extension.

Types of signatures

There are a lot of ways to sign a file. At the bottom there are different asynchronous cryptographic algorithms (RSA, DSA, Elgamal, etc.) and hash functions. These are typically enriched with additional information for the verification of the authenticity of the signer in the form of public key certificates (X.509v2, X.509v3, OpenPGP, etc.).

Signatures and certificates need to be "packaged" in a defined way. These packages may also contain or reference the signed data. For example, for XML data there are the standards XML Digital Signature and XAdES and for binary data there are CMS and CAdES (and probably other). These standards provide different ways of how the signed data is referenced or contained. The signatures (together with certificates, etc.) can be contained in separate files or combined in one file.

The digital signature used by OOo actually uses a "detached" signature. That is, the signature and the signed files are separate. However, they are then all put together into one zip file. One could also think about "fusing" a detached signature file with the actual data file.

OOo currently provides a signature for macros and the whole document (but not for the file as a whole.) One could also think about signing particular paragraphs in a document, or even particular cells in a spreadsheet. That is there could be variable number of signatures for one document.

The signature framework should not dictate a particular way of how the signatures are created. Instead it should be flexible so as to allow different ways of signing.

Using different types of signatures

The signature framework of OOo should allow the installation of several signature components. This would theoretically allow to sign the same document using different signature components which could create conflicts because one type of signature could influence the other. One must also assume that a particular signature component is unaware of the signatures created by other signature components. This increases the danger of damaging or invalidating existing signatures.

For example, there are two signature components A and B. A creates the conventional XML Digital Signature and B creates a detached CMS signature for the entire document file. When B is applied before A, then B's signature will be invalid. That is, writing the signature within the document file (A), like any other modification of the files contents, breaks signature B.

Even if different signatures (over the same content) does not influence each other, they could still check differently (assuming we regard a signature as invalid when the certificate cannot be validated). This can be the case when the certificate validation routines are different, or signatures use different signature policies (XAdES, CAdES). To represent the validation results to the user in an understandable way would probably be a difficult task. One must also keep in mind that many users have only a very basic knowledge about digital signatures.

Because of these problems it seems best to only use one signature type. That is, OOo must prevent that a users signs the document when it was already signed using a different signature type.

Selection of the signature component for writing the signature

When different signature extensions are installed, then users can select in an options page which one they want to use for signing. This options page should also allow to invoke a separate options page for the particular extensions.