Does knowledge of the manifest URL conveys authority to enqueue a message in a mailbox or authority to attempt to open a channel?<br><br>How does revocation work? Say Alice tells Bob that he should talk to Charlie, and gives Bob Charlie's manifest URL. If Charlie realizes Bob is a crank, can he revoke Bob's ability to spam him without closing an established channel to Alice?<br>
<br><br><br><div class="gmail_quote">2009/1/14 Anupam Simlot <span dir="ltr"><<a href="mailto:gurudevdas@gmail.com">gurudevdas@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello everyone,<br>
<br>
This is probably a dumb idea. My ignorance is definitely<br>
betrayed here. Forgive me if someone has already<br>
proposed a similar or better idea. I came up with this<br>
while trying to figure out exactly what waterken is.<br>
<br>
E-mail is currently the most anarchic and abused part of<br>
the wild wild west, err sorry, the internet. I'm sure<br>
you're all aware of what's wrong with it so I won't<br>
delve into that here. What I would like to propose is an<br>
alternative, yet backwards compatible, system based on<br>
the concept of ocaps.<br>
<br>
In this system, messages are not one way but form a part<br>
of a transaction to request the target to perform<br>
certain operations. One such operation might be to read<br>
some text. Another might be to request a mailing list to<br>
delete a stored message.<br>
<br>
One party would be represented to another by the<br>
following:<br>
1. storage pools<br>
Where messages are stored until retrieved<br>
by the target of the message. They are<br>
represented in the traditional e-mail<br>
address format: ye.olde@email.adrs.<br>
2. public key<br>
For encrypting messages. While this serves<br>
as one's primary id, one can not do<br>
anything with it alone.<br>
2. capability ids<br>
Represent which operation the sender is<br>
allowed to request of the target. A<br>
capability may allow for anonymous<br>
requests even.<br>
<br>
For example, let us say Alice wants to send her resume<br>
to Bob whom she met at a job fair. At the fair, Alice<br>
gave Bob the URL to her manifest file and Bob gave her<br>
the URL to the company's manifest file (or may be just<br>
his). A manifest file would include just enough<br>
information for the first transaction between two<br>
parties.* An exchange of manifest files is required if<br>
the capabilities do not allow anonymous transactions.<br>
Otherwise, only the target's manifest file is needed.<br>
When Alice goes home, she'll import Bob's manifest into<br>
her client. She would then instruct her client to send<br>
her resume along with an introductory letter to Bob. The<br>
client would assemble the instructions along with<br>
information to respond to the request. This would be<br>
encrypted with Alice's private key. The encrypted text<br>
along with Alice's public key would be encrypted with</blockquote><div><br>If a public key exchange is piggybacked on the original message, does that mean that if Alice wants to signs subsequent messages to Bob with her private key then that has to happen via a different protocol?<br>
<br>So initial message is of the form (encrypt BobPublicKey (list AlicePublicKey MessageBody)) or (list (encrypt BobPublicKey ThrowawaySymmetricKey) (encrypt ThrowawaySymmetricKey (list AlicePublicKey MessageBody)))<br>and subsequent messages would be of the form (sign AlicePrivateKey (encrypt BobPublicKey MessageBody)) or the symmetric key equivalent?<br>
<br>Instead of piggybacking the key exchange on the first message, maybe the sender could include their manifest URL by way of address. So all messages would be of the form<br> (list SenderManifestURL (sign SenderPrivateKey (list (encrypt RecipientPublicIKey ThrowawaySymmetricKey) (encrypt ThrowawaySymmetricKey MessageBody))))<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Bob's public key (taken from the manifest). This is then<br>
sent as a MIME attachment to the appropriate storage<br>
pool (via SMTP, etc.). Bob's client would then extract<br>
the resume and letter and post them in HR's database.<br>
Finally the client would construct a reply to Alice<br>
(based on the information in her message) informing her<br>
of the success of the transaction.<br>
</blockquote><div><br>If the messages are properly signed, then Bob would here be delegating the authority to respond on his behalf, but he would not be giving the authority to impersonate him -- that authority resides in his private key.<br>
<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
I understand object capabilities would not place<br>
restrictions on the identity of the requester but this<br>
is useful for combating certain attacks. Since messages<br>
include the sender's identity, this an open option for<br>
clients.<br>
<br>
Additionally, this system would be akin to edge<br>
addressing where a capability would represent the party<br>
who uses them. If the party abuses their authority, such<br>
as by sending spam, the capabilities can be revoked.<br>
(New capabilities can be reissued if the abuse was due<br>
to a system compromise rather than a malicious<br>
attack).<br>
<br>
There is probably more to say regarding pseudo-anonymity<br>
and decentralization.<br>
<br>
* There is nothing inherent in manifest files that<br>
require them to provide only information for first<br>
transactions. I imagine them to be a useful vehicle<br>
for transmission of capabilities and identity.<br>
<br>
I hope most of that made some sense. :/\)<br>
<br>
---<br>
_______________________________________________<br>
cap-talk mailing list<br>
<a href="mailto:cap-talk@mail.eros-os.org">cap-talk@mail.eros-os.org</a><br>
<a href="http://www.eros-os.org/mailman/listinfo/cap-talk" target="_blank">http://www.eros-os.org/mailman/listinfo/cap-talk</a><br>
</blockquote></div><br>