All statements in CRISIS, including statements of identity, statements of privilege, and transfer of privilege, are encoded in certificates. CRISIS certificates are signed by the principal making the statement and then counter-signed by a principal of the signer's choosing. Each signature uses a separate timeout: the principal's signature is issued with a long timeout, while the counter-signature is issued with a short timeout. The counter-signer (i) checks if the statement has been revoked and (ii) refreshes its endorsement (by applying a new counter-signature with a new timeout to an expired certificate) of certificates, indicating that the rights are are still valid. Since we are building a public key system, the certificate's author need not be aware of the certificate's destination when it is created. Any principal with access to the certificate can determine the statement's author. Our certificates use the X.509 [Con 1989] standard format. CRISIS employs two basic types of certificates:
Of course, identity certificates must be signed by an authority trusted by both endpoints of a communication channel (see section 4.3 for the case where no single authority is so trusted by both parties). This trusted third party, called the Certification Authority (CA), maps public keys to principals and maintains a Certificate Revocation List enumerating all public keys that have changed or that have been knowingly compromised. In CRISIS, CA's sign all identity certificates with a long timeout (usually weeks) and identify a locally trusted on-line agent (OLA) responsible for counter-signing the identity certificate with a relatively short timeout (usually hours).
The redundancy of a split CA/OLA approach offers a number of advantages. First, to successfully steal keys, either both the OLA and CA must be subverted or the CA must be subverted undetected. By making key revocation a simple operation (as described below), we are able to pro-actively revoke keys when a CA comes under attack. Further, the CA is usually left off-line since certificates are signed with long timeouts, increasing system security since an off-line entity is more difficult to attack. Another advantage of the split CA/OLA approach is that a malicious CA is unable to revoke a user's key, issue a new identity certificate, and masquerade as the user without colluding with the OLA [Crispo & Lomas 1996]. Also, while a malicious OLA can mount a denial of service attack, the CA is still able to re-issue new certificates employing a different OLA. Finally, this approach improves system performance because certificates can be cached for the timeout of the counter-signature, removing the need for synchronous three-way communication in the common case.
We generalize the OLA to make revocation a first class operation in CRISIS. All certificates are revocable modulo a timeout. To revoke a particular privilege, the OLA which endorses the certificate must be informed that the certificate should no longer be endorsed. Once the timeout period for the endorsed certificate expires, the rights described by the certificate are effectively revoked because the OLA will refuse re-endorsement for that certificate. Revocation is used not only for exceptional events such as stolen keys. For example, the rights of a remote job are revoked upon its completion or when a user decides to kill the job. As another example, privileges associated with a login session are revoked on user logout.
The use of transfer certificates in CRISIS also simplifies both the implementation of and reasoning about delegation, which allows one principal to act on behalf of a second principal. Such delegation is useful in many contexts. For example, a database server will receive requests from many users, with individual operations executed in the context of the rights of a single user. It is important that a user's privileges are not amplified by employing the rights of the server. Such delegation is difficult to properly design. For example, early versions of UNIX sendmail were setuid root to allow the program to write to any user's mailspool. However, a bug allowed users to write any system file to a mail message addressed to themselves.
In CRISIS, users sign transfer certificates allowing servers to act on their behalf for accessing files, running jobs, etc. Servers provide these certificates to reference monitors when making requests on behalf of a user (as opposed to certificates describing their own rights), reducing the chance of the server being granted access on its own behalf when acting on a user's behalf. Relative to the SRC system [Lampson et al. 1991], where reference monitors use a pull model to search for proof that a principal should be granted access, CRISIS transfer certificates reduce complexity and hence the chance that an implementation error will lead to unauthorized accesses.