User interface

   

Figure 2: Elements from the user interface components to create delegation certificates.

The bandwidth of the channel defined by human conversation is relatively low. The core of an offline delegation system is the dual ability to generate a valid certificate on a PDA and making it ``readable'' in a form which is simple to both send and receive on such low-bandwidth communication channels. To facilitate offline delegation, we have designed and implemented a supporting application on the PDA. The appearance is such that it enables two users to exchange sufficient information to send a certificate on one end, and receive it on the other.

In general, the process of building a certificate consists of entering the required information into the application, and then let the application generate it. The following information is required:

Filename:

It is the users' responsibility to ensure that file names are unique within the scope of a server; the name of the file is prefixed by the name of a server. In the implementation, applications synchronize with the file server and has a cache of filenames available. If access is delegated to a file which name is not available, the name must be entered manually.

Delegatee:

In all systems where users are represented by their public keys, names must be unique within the system. More precisely, the name appearing in the certificates must be unique. As with file names, the software keeps a cache of frequently used user names.

Created, Expire:

In order to ease the process of entering dates, calendars are used (with the current date as default). Figure 2(a) shows how time is entered into the application; the user taps the boxes with the stylus.

Rights:

A certificate can delegate authority [9]. In our setting, such authority can be read or write (or both).

Figure 2(b) shows how general information is entered into the application.

The assumed operational procedure is that Alice enters information into the data fields on her PDA while she talks with Bob, and Bob enters the same information into his PDA. The software has been designed to be used in this way, that is, the order in which information is entered when a certificate is created is matched on both sides. By going through the fields together, they build up the certificate. When Alice is finished entering information, she will sign the data with her private key.

   

Figure 3: Elements from the user interface to send and receive delegation certificates.

As will be explained below, the signature is 256 bits long. On the sending side, the bits are presented to Alice as 16 4-digit hexadecimal numbers; see Figure 3(a). Notice that the checksum in the right hand column is a simple error detection scheme. She can now read the signature bits out to Bob, one group at a time.

As Bob listens to Alice, he needs means to enter the signature bits as fast as Alice reads. To facilitate this, a dedicated form is presented on the PDA. By tapping on the screen of the PDA he is able to enter data (receive as it were). The design is such that users can receive bits fast enough for the system to be usable. See Figure 3(b) for a signature that has been partly received. The checksum is calculated as data is entered. Although only a proper verification of the signature can determine whether it was properly transferred, the checksum is used to give Alice and Bob some confidence in its integrity. In this implementation the checksum is an exclusive-or computed over the four 16-bit numbers. As a result, two bits in any number of row of bits will go undetected. If experience shows that a stronger integrity check is requrired, it can easily be incorporated into the application.