Timothy C. May asks (regarding my naive proposal):
I don't follow this. How do you know a node (=server) hasn't just "peeked." ... If you meant something else by your question, I don't get it. Please ask it again.
Yeah I think my terseness led to some communication failure. I was imagining the key server publishing a key which thousands of folks might then use to close their time capsules. The key server doesn't know which messages where are closed with their key, and even if they did the messages are simultaneously closed with many different keys, so they'd need wide collusion to peek (including collusion with one of your escrow message holders). And as Dorn suggests the escrow holder of the message can't peek if "message itself could be encrypted using the intended eventual recipients public key". Dorn suggests:
The servers would generate a key pair on request, for a fee. Send you the public key to encrypt the "message" for storage somewhere.
I guess this might work, but now you have to be more specific in telling your escrow service where to look for public keys to decode you message. With just a few standard time-key servers, this isn't needed, and perhaps we could all share the costs of monitoring their trustworthyness. Needing just a few, the need might easily be met by charity. Robin