# Capabilities 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 space. ### 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.