The discussion of privilege/capability lists above suggested that a
trusted access control system manage storage of the lists. In a
distributed system, it would instead be possible to have untrusted
subjects manage the storage of those lists. Alice could keep track of
the capabilities issued to her, Bob of those to him, and so forth. But
now the *authenticity* of those capabilities must be ensured: we would
not want subjects to be able to manufacture capabilities never issued to
them by the access control system.
### Cryptographic capabilities
Digital signatures provide a mechanism to implement capabilities in this
distributed setting. To issue a right `r` to a subject named `S` for an
object named `O`, the access control system can construct a capability
`cap`, where `cap=(S,O,r)`, and sign that capability, producing a
signature `s`, where `s=Sign(cap; k_AC)` and where `k_AC` is a private
signing key for the access control system. The pair `(cap,s)` can be
given by the access control system to the subject. Whenever the subject
wishes access, it presents `(cap,s)` back to the access control system,
which verifies the signature and the rights contained in the capability.
This scheme can be modified support delegation:
- The subject's name could be omitted from the capability. This would
enable subjects to easily delegate capabilities, simply by giving
another subject a copy of the capability.
- Instead of using a single key pair, many key pairs could be
employed. For example, there could be one key pair `(K_O, k_O)` per
object `O` in the system. The access control system could delegate
management of access control for `O` to a subject `S` by giving
`k_O` to `S`. Any component that needed to verify capabilities for
`O` would need to know `K_O`.
Revocation, however, now becomes a problem, much like it did for digital
certificates. It might not be possible to delete capabilities once they
have been issued. So the access control system might need to include
validity intervals (so that capabilities expire), or maintain revocation
lists (which must be consulted by the reference monitor).
Moreover, these capabilities are expensive. Creating keys and verifying
digital signatures both take time, and storing the signature takes
### Other implementations of capabilities
Prof. Schneider also discussed tagged memory, protected address space,
and type safety as means to implement capabilities.
And he discussed issues involved with the revocation of capabilities.