[cap-talk] email

[Anupam Simlot]

I'm new with these concepts so I'll respond as I best can. If I make no sense
or get something wrong, do tell me.

Mike Samuel mikesamuel at gmail.com
Wed Jan 14 18:08:35 CST 2009

> Does knowledge of the manifest URL conveys authority to enqueue a message in
> a mailbox or authority to attempt to open a channel?

I should have been clearer. The manifest itself is just a file listing the
capabilities and the necessary information to use them. There is nothing in the
manifest itself that would prevent one from trying to send a message. Whether
the message is accepted or not depends on how the receiver responds to that
capability id. The capability ids are not bound to the manifest file. You can
write them on a napkin if you want to.

> 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?

Yes, it would be closed for Alice as well. However, the way I see it, the
manifest file that allows for a first transaction would only have the
capabilities to request an audience, if you will. That is, having the the
manifest Bob has would give one the authority to request the authority to have
useful conversations. So with this example, Alice and Bob would only share one
set of capabilities but their working sets would be different. This is what I
meant by "edge addressing". While Charlie would revoke Bob's unique sets,
Alice could continue to communicate with Charlie. However, there is nothing to
prevent Bob from assuming a second fake identity to re-establish himself with
Charlie.

> 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?

I don't think I understand your question. I don't think anything is being
piggybacked.

> So initial message is of the form (encrypt BobPublicKey (list AlicePublicKey
> MessageBody)) or (list (encrypt BobPublicKey ThrowawaySymmetricKey) (encrypt
> ThrowawaySymmetricKey (list AlicePublicKey MessageBody)))
> and subsequent messages would be of the form (sign AlicePrivateKey (encrypt
> BobPublicKey MessageBody)) or the symmetric key equivalent?

(encrypt BobPublicKey (list AlicePublicKey (encrypt AlicePrivateKey message)))

If someone has Alice's public key (many could), he still can't impersonate Alice
unless he's also obtained Alice's private key.

> 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
>  (list SenderManifestURL (sign SenderPrivateKey (list (encrypt
> RecipientPublicIKey ThrowawaySymmetricKey) (encrypt ThrowawaySymmetricKey
> MessageBody))))

The identity is the private/public key pair. Key exchange occurs before the
first message. The manifest file exists to make this easier.

Privacy is something I'm aiming at. I do not want admins of storage pools to
read someone's message without that person's permission.

> > Bob's public key (taken from the manifest). This is then
> > sent as a MIME attachment to the appropriate storage
> > pool (via SMTP, etc.). Bob's client would then extract
> > the resume and letter and post them in HR's database.
> > Finally the client would construct a reply to Alice
> > (based on the information in her message) informing her
> > of the success of the transaction.
>
> 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.

I don't understand what you are saying here either. I'll just guess.

Bob's reply would simply be informing Alice that the message was received
and all was in order. May be more depending on what the message requested.
If Bob's client does not respond, Alice could call Bob on the phone and ask
him if he got the resume. I forgot to add that the sending client attaches a
transaction id to a sent message. This id is included in the response so Alice's
client knows which transaction it is referring to.

I hope that made some things clearer.

---