One difference is that a capability is normally implemented to locate the intended object so as to efficiently deliver a message. There is not usually a presumption that knowing someone’s public key helps to find the person in order to deliver a message. Also it is usually thought that public keys need not be kept secret.
There is no sense of “non-repudiation” as provided by public key signature here. Diffie-Hellman can thus be used in place of RSA as non-repudiation is not required.
Some applications of the concept bridge from capabilities to crypto:
Some languages such as Joule and systems such as Mach (I think) separate the authority to receive messages from the identity of an object. I may pass you the authority to receive on a channel (Joule) or port (Mach), whereupon you will receive the messages. This is like multiple people knowing a private key.
This concept bridge is also useful in the design of distributed capability systems or distributed object systems. See Distribution.
Mixing the two schemes suggests the following. Imagine objects in an infrastructure where there is relatively reliable delivery service but no communications privacy. We want to build reliable systems. Each object chooses a key pair upon creation and disseminates a bundle consisting of the public key and a locator suitable to the infrastructure. This bundle serves as a capability to the new object. The bundle suffices to send a message to the object that only the object can read.
A variation on the above bundle it to bundle the locator with a hash of the public key, perhaps the key’s standard fingerprint. Perhaps a 70 bit hash will do if there are no birthday attacks. Otherwise about 140 bits might be needed. There is a latency penalty here as X, the bundle holder, must first send a message to Y, the private key holder, to get the public key of Y. This message can include X’s public key so as to protect Y’s public key in the return message. I assume here that objects have public keys with which they make such queries that are distinct from the public keys whose dissemination controls who is permitted to ask service of an object. The fingerprint becomes the authority to invoke the object. If elliptic curve public keys are as small as promised then this scheme has little to recommend it.
Assume a system with mailboxes for each of which there is a capability to withdraw messages, and a different capability to insert messages. Each mailbox has an internal message queue. Some capability systems bottom out this way. The isomorphism with sealers is closer in this case, but the mailboxes arrange for delivery while the sealers do not. Just now it is not clear to me whether one can be built on the other.
There is some math to be done here.