Abstract

This document describes the design principles for the OpenSign, a free open source Java-applet for digital signing in a browser environment.

The main idea behind OpenSign is to provide a general applet which can be integrated in solutions where an application owner need an extra commitment from the user. This is done using PKI to generate digitale signatures based on the xmldsig format as defined by The World Wide Web Consortium (W3C). It is important by design to have consistency over time and robustness to latent disbutes on what was signed.

The key issue is to get as close to WYSIWYS but still being able to use OpenSign in practical solutions. A flow for signing text based on structured data is suggested.

Copyright Notice

Copyright (C) OpenOCES Project (2004). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind.

This document and the information contained herein is provided on an "AS IS" basis and THE AUTHOR DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Table of Contents

1.  Introduction
2.  What-you-see-is-what-you-sign (WYSIWYS)
3.  Format of the signed data
4.  OpenSign in use
§  Author's Address

1. Introduction

OpenSign is a subproject of OpenOCES open source project. OpenSign is a Java-applet licensed under LGPL and distributed as a free open source component for digital signing in a browser environment.

The OpenSign applet can be used in web based application were digital signatures are needed for further commitment from the end user. SSL (with client certificate authentication) isn't enough while it only protects the communication between client and server. Note that OpenSign does not address encryption of the signed data so the applet will usually be use in a SSL-encrypted environment. It is also important to note that OpenSign in itself does not constitute a secure solution. In order to get a complete setup all classical security and PKI consideration must be addressed. In other words, OpenSign is not intented to be an out-of-box security solution but a general component which can be integrated as a part of a system.

Further information on OpenOCES and OpenSign can be found on http://www.openoces.org.

2. What-you-see-is-what-you-sign (WYSIWYS)

When signing data in a analog paperbased world such as application forms, we have the opportunity to validate the data prior to adding our signature. We also have operations to protect against alterations of data after the signature is applied (e.g. carbon copies). In the analog world we might say that we have What-you-see-is-what-you-sign or in short WYSIWYS.

The goal of getting WYSIWYS is not not as easy to achieve in a digitale world for several reasons:

• Data and presentation might be separated (e.g. stylesheets)
• Data might be dynamic (e.g. dhtml, script and macros)

So one can argue that true WYSIWYS is only achived if you're using trustworthy encapslated systems with limited functions and absolute GUI control such as ATMs. This indeed is a impractical solution in largescaled deployed PKI, so what is needed is to get as close to true WYSIWYS but still being able to make solutions which can be implemented.

3. Format of the signed data

In order to get as close to WYSIWYS OpenSign presents plain unformatted text for the user. Data signed in OpenSign is the presented text with a simple base64 encoding. In this manner users are not fooled into signing dynamic data or data which appears differently depending on the current stylesheet. The security in OpenSign is rated higher than "nice" appearance.

For system management reasons OpenSign is in fact able to carry formatted data in the xmldsig signature, but these data will be marked "not visible to signer", such that this can be taken in account in a dispute at a later time. This method is also used to display a number of OpenSign configuration parameters the xmldsig document.

Using plain text has another advantage in the sense that data is preserved in a format which is expected parsable over time. It is not needed to save information on the specific format and version of the format whereas the format is as simple as it gets.

4. OpenSign in use

It should be noted that most signatures are primary made to ensure a commitment such that later potential disbutes can be handled. This means that signatures mainly is a log-issue and will only be handled manually at a later stage if needed.

This gives rise to the following suggested solution setup (depicted in Figure 1). Note that this is only an example which can give inspiration to a system design.

+-----------------+   Transformation    +-----------------+
| Structured data | ----------------->  | Visualized data | ----------+
+-----------------+                     +-----------------+           |
         |                                       |                    |
         |                                       | Sent to OpenSign   |
         |                                       | and signed by user |
         |                                       |                    |
         |                               +-------+--------+           |
         |                               |  Signed data   |           |
         |                               +-------+--------+           |
         |                                       |                    |
         |                                       | Returned to server |
         |                                       | for signatur       |
         |                                       | validation         |
         |                                       |                    |
         |                               +-------+--------+           |
         |                               |   Validated    |           |
         |                               |  signed data   |           |
         |                               +-------+--------+           |
         |                                       |                    |
         |                                       | Server extracts    |
         |                                       | visualized data    |
         |             Signal "OK"               | and checks         |
         | <------------------------------------ | consistency       <+
         |                                       | with the original
+-----------------+                              | visualized data
| Structured data |                              |
+-----------------+                      +-------+--------+
         |                               |     logged     |
         | Continued                     |  signed data   |
         | workflow                      +----------------+
         | 
        \|/
         | 
                    

Note that the signed data is never used in the operations done after the signature was validated against the original visualized data.

Finally it must be noted that the design choices made means that the signed data is not easily parsed by machines. This means that special precautions must be made in applications where signatures are made to give power of attorney to the application.

Author's Address