consider allowing access to the Tub's private SSL key for sealing/unsealing

[Brian Warner]

I'm really not sure this is a good idea, but I figure it's worth discussing:

Since we have a private key inside the SSL certificate for the Tub, it might be useful to provide a way to use it to encrypt/decrypt/sign/verify things. This would let someone with access to the Tub prove that they have access to the Tub, by signing a challenge, for example.

The reason that I suspect this to be a bad idea is because I believe that any conceivable use case for this is already provided for by the references we currently have, and that making it easy for users to test things like "who sent me this message" is counter to the goal of encouraging the use of the object-capabilities model. For example, rather than writing an object which performs some action because the message was signed by some particular key, you should instead only give access to this object to the entity that you wish to be able to perform the action. This simplifies the case analysis and allows for delegation, which (in general) the holder of the capability is able to do anyways (via forwarding), so there's no point in trying to prohibit it.

Anyways, I'm trying to come up with some hypothetical use cases for this sort of functionality, and then identify how they could be accomodated using a more objcaps-oriented approach instead.