Other applications
Public keys with multiple accreditors
It is quite common to assign a person a role whose performance depends on using a role key. However, we can have multiple parties having to approve assignment of such role. This is common in banking, where transactions over a certain amount typically have to be approved by more than one officer, but may be delegated on a limited basis. At present, special key management standards are being developed for banking by ANSI, as multiple signatures are not supported by X.509.
A similar problem arises in medicine, where the signing key used by (say) a doctor on a six month assignment in a hospital would not wish to use his long term personal signing key (hospital systems are often mutually incompatible and quite insecure) but would instead use a key that was signed both by his own personal long term key (in an off-line operation) and the hospital. This dual signature signifies that both the doctor and the hospital accept their joint liability for malpractice suits; it should also be possible for either of them to revoke the key when the relationship is terminated. This multiple revocation requirement is quite a complicated problem if one tries to implement everything as extensions of X.509.
Neither are medicine or banking the only applications in which dual control is required. Almost every substantial organisation has its own rules and procedures for managing dual control. Sometimes these rules may be hidden, as with military intelligence organisations who do not wish to reveal which officers have actual power; at other times, concealment is forced, as with the system of EU grants under which each grant receiving organisation (such as a university) must designate one `official signatory' and the European Commission refuses to take any interest in the procedures that may lie behind this person's use of his official signature. How can we then support realistic trust models using either catalogue based or public key based trust mechanisms?
In the old days of paper-based banking systems, the custom was for each bank to print several hundred copies of a `signature book', which contained the specimen signatures of its managers together with a set of rules defining, for example, which combinations of signatures were required on a letter of credit over $10m. These books were then posted to its correspondent banks.
Our catalogue based trust mechanisms can provide an electronic implementation. In its simplest form, the company authenticates at regular intervals a set of public keys suitable for appropriate purposes and makes them available via web pages bound to the relevant trust trees.
This can even be done if need be in real time; we are experimenting with a mechanism whereby flexible links can be created on request to authenticate a key for a particular purpose. The example in the following diagram (Fig. 2) is where a company lawyer wishes to create a one-time key to conclude a property transaction that involves both internal certification (from his superior officer and the company's CEO) and an external land and property agency.
Figure 2: Publishing key information. Multiple accreditors are
referring to the key that is valid if and only if all self-contained
required links exist and the key-page hash value has not changed.
The effect of this mechanism is that CA functions can be performed on a one-off basis by various people and organisations as they are needed - a flexibility that is still critically lacking in X.509.
