[Cryptography] A naming and key distribution infrastructure for the Mesh

[Phillip Hallam-Baker]

On Sat, Sep 26, 2020 at 5:08 PM Francis Pouatcha <
francis.pouatcha at adorsys.com> wrote:

> For the mesh to work at scale, onboarding and discovery will have to build
> on top of existing naming infrastructures (telephone, SMTP, banking, ...),
> regardless of how spammy they are.
>
> Let assume Alice (resp. Bob) is the mesh participant that can prove
> possession of Alice's mesh record (public key).
>
> If Bob has Alice's email contact entry named "alice at gmail.com", Bob wants
> to use this to discover Alice's mesh record.
> If Bob has Alice's phone contact entry named "+1-617-666-1234", Bob wants
> to use this to discover Alice's mesh record.
> If Bob knows Alice's bank account number (IBAN), he wants to use this to
> discover Alice's mesh record.
>

This gets away from my naming system and back to the original core of the
Mesh. I must say that nobody seems to have raised the expected objections.
So folk are ok with the basic structure I am proposing, thats fine.

On the bridging issue, that is where I started. One of the really important
contributions to the Web was the scheme part to the URL which was
originally proposed by Dan Connoloy. The two most important parts of the
strategy to me are the Credentials Catalog and the Contacts Catalog.
Combined with an intelligent client, they help us move from where we are to
where we want to be.

The key to both is that all Alice's devices are glued together to form a
single Gestalt UNDER HER CONTROL. So she adds a password on her mobile, it
is on the laptop and desktop. So Alice can get out of the business of
remembering site passwords which are stupid and no longer functional.
Nobody can remember a hundred passwords of any quality. Certainly not a
hundred strong ones. So put them all in a password vault, share it across
every machine Alice owns and she never has to remember passwords. And if
Web sites get bent out of shape about that, well they can get a clue and
use the fact the Mesh provides public key based auth across those devices
as well.

Its the same for Contacts. Alice can put all her walled garden contact
addresses in her contact data she publishes. So people know how to get her
on Skype, Zoom, Signal, etc. etc. And she can reach the people who aren't
yet on the Mesh in their walled gardens. But here is the thing, an open
system always beats a walled garden in the long run. Skype has got about as
big as it will get. Signal can grow quite a bit still. But there are limits
to any closed system.

What the Mesh does which I have yet to see anyone else do is address the
problem of managing keys across devices. And that is really hard to do in
PKI. In fact I tried to do that for 20 years before I realized that PKI
can't do that, you need threshold so its a TKI.

So if someone else tries to create an open system, well I will add them to
my scheme and I guess they will add mine to theirs if I have any user base.
At which point they will just be two views of the same space.

Yes, privacy is an issue. BUT from the start I have wanted to design a
system that would allow Madonna or Lewis Hamilton to use their own names as
identifiers and not get spammed to heck as a result: Everything is under
access control. So one way to approach privacy is to mitigate the cost of a
privacy breach. I think we need to use that more.

If people want their actions to be untraceable by the authorities... well
they better use identifiers that are opaque and not publicly link them to
their other identifiers. At this point I am trying to avoid giving out
metadata unnecessarily but there are pragmatic limits to the amount of
traffic analysis resistance can go into the base system. Maybe we layer on
TOR like techniques later on. Certain aspects of the design are designed to
facilitate that (limit on message size, every MSP has a complete copy of
the naming registry).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200927/4957dbf8/attachment.htm>