[messaging] Google End-to-End plans on using key directories with a CT-like verification protocol

[Eduardo' Vela" <Nava>]

Hi

I'm partly responsible for that long and confusing document:
  https://code.google.com/p/end-to-end/wiki/KeyDistribution

I'll try to answer some of the meta-concerns that are misunderstandings.
Thank you all for your feedback, we are listening :)

Regarding Moxie's concerns about auditability by the users. To facilitate a
user to enumerate all her keys in the log without having to download the
entire log, we want to make each entry point to it's older, previous entry.
This means a user doesn't have to rely on the Monitors to notice a key
introduced covertly, they just have to rely on the Monitors to show it's
running a compatible/latest version of the log (as long as the user's
client queries for the user's key).

I agree that the "wingnuts" problem that Moxie touched is there, but we
just want the service to be able to give proper notice to the user when she
is being attacked (either because of phishing, and someone taking over her
account, or because her domain expired and the new owner wants to use that
email too, etc).

For the real-paranoid that wants real-life strong-identity assertions, we
will try to make fingerprint verification easier.

Regarding the "simpler thing" model, it works too! And that's how Mailpile
works as I understand it. One important difference, as other pointed out,
is that this doesn't require users to do introductions every time, which is
unfeasible for some usecases we would really like to support, but I'll try
to be compatible with Mailpile (it seems simple).

About the blockchains. Keybase stores a copy of their STH to the
blockchain! It's kind-of like a gossip channel I guess, and I think it's
not a bad idea.

Regarding the SPAM problem, on publishing a list of emails vs a derived
value (scrypt or so): It's a tradeoff of auditability and semi-anonymity.
We might do it, but we want to be sure sacrificing auditability has been
thought over before deciding against it.

To answer Adam's questions about revocation, whenever a new key is inserted
to the log, we consider the previous one revoked. The verifiable map is
simply used to show that a key is the latest entry.

Some of the other questions raised were about the usability challenges and
how to communicate different edge cases to the user. It's a hard problem
that needs research. We are working on that, I wish I could give a better
answer, but that's the hard part of this project.

Hope that helps, and thanks again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140829/8b1be080/attachment.html>