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. The advantage of a contained signature is that one doesn't needs to keep track of the additional signature file(s) when copying or moving the document. That is, that in case there is a "real" detached signature, it could make sense to attach it to the document again and hence create a single file. This, however, is not to be confused with a document containing a signature.

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.

With all these possibilities in mind it becomes clear, that there can be a wide variety of implementations. The signature framework should therefore be very flexible as to support as many implementations as possible.

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 (see Signature meta data).

Signature meta data

The signature meta information are contained in a new stream in the ODF document. It provides additional information about the signature. It is used to:

• prevent using different types of signatures (see Using different types of signatures )
• uniquely identifying the signature component (validation, removal, resigning, countersigning)
• inform the user that they need a signature component to verify the signatures
• identify the signature files which can be copied from a template to a document

A signature component which creates a detached signature (e.g. a separate file is created) must also write the meta information into the document.

Whenever a document is loaded, then it is investigated for signatures. Because of the meta data it is not necessary to invoke the signature components just to find out about them. Doing so may cause the loading of the Java or other runtimes, which can be costly. That is, the performance impact for unsigned documents at load time will be little.

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.

Note: signature components may need to be configured. The options button in the image above could open a new modal Window. But then there would be a stack of three windows. The option window could also replace the current options page. Then it would have to offer some kind of Back button to restore the previous view. This would be the best integration but difficult and time consuming to implement. Another possibility is to introduce a new node "Signature Components". Its first child element (leaf) would then contain all the available components and all other leaves under that node could be the options pages of the respective signature components.

Selection of the signature component for validating the signature

To verify a signature it is necessary to determine the proper signature component which is to carry out this operation. The framework will utilize the Signature meta data to choose the correct component. If the document contains a signature for which no suitable signature component is installed, then a message is displayed that tells users that they need to install a particular component before the signature can be validated. The message box should contain:

• Information about the used standards, profiles, specifications, etc. which the signature complies with
• Information about the signature component which created the extension. It could contain a link to the web page (e.g. OpenOffice.org Extensions Repository) where this component can be downloaded.
• A note that the document can only be modified if a suitable signature component is installed. See Removing signatures.

These information are only available if the signature meta data are accessible, that is, the document must be loaded and the meta data must exist. While the latter can be made mandatory, the first condition may not always be met. This can be the case if the document file has a signature file attached, or the document is contained in a CMS “envelope”, etc. Loading this document requires a particular filter which would be provided by the respective signature component. And if it is not installed, the document will not be loaded at all. For further information and possible solutions refer to New file type for signed documents.

Dependent on if we introduce no, one or several new file types, the user can be displayed:

• No particular message, if we do not introduce a new file extensions. The office would treat the document as every other unknown file format.
• A message, indicating that the document is signed. The message box can offer to forward to the OpenOffice.org extensions repository to look for signature components. The link could contain a search request for “signature component”. Users must, however, know what kind of signature is used. They can obtain this information from the author, the web page where they got the document from, etc.

• A message, indicating the specification which the signature complies to. The message box can offer to forward to OpenOffice.org extensions repository to look for signature components which implement this specification. The link would therefore contain an respective search request.

Removing signatures

Signatures are removed in two situations:

• the user actively removes a signature
• the signed part of the document was modified

The latter mentions explicitly the "signed part". This is because signatures may be created for parts of the document, such as paragraphs, regions, particular streams within the zip package, etc. Modifications outside of the signed areas do not render the signature invalid. In these cases, signatures need not be removed. For example, the current implementation allows to sign the macros separately. Modifying the text in the writer document does not invalidate the macro signature.

Different signature components can write there signatures in different ways. Even if they two components adhere to the same standard, they still may write the signature differently. For example, certificate revocation lists could be contained in a signature (signature refers here to the whole "package" containing the actual signatures, countersignatures, certificates, certificate revocation lists, time stamps) or they could be referenced. In first case the signature would be in one file and in the second case it would be in two or more files).

Similarly, the current signature implementation creates two separate signatures, one for the whole document and the other for macros. Another signature component, which also complies with the W3C XML Digital Signature standard, but only signs the whole document, would not be aware of the macro signature.

On must also be aware, that removing a signature not just means to delete a file. In many cases the signature data structure must be modified. For example, there could be a separate signature file, which contains a couple of "real" signatures (pure RSA, DSA, etc.) from different persons. Deleting the signature of one person requires to modify the data structure itself.

These examples show, that deleting requires specific knowledge of the signature. Therefore the deletion of a signature or part of it must be performed by a suitable signature component. See Identifying a suitable signature component for details about how the signature component is determined.

If there is no suitable signature component installed, then signatures cannot be removed. The consequence is, that the document must not be modified which also prohibits the creation of additional signatures. That is, the document with an unknown signature type (that is, no suitable signature component is installed) will be loaded as read-only. How this is communicated to the user is explained in paragraph Selection of the signature component for validating the signature.