[Cryptography] Next steps in the Mesh

[Phillip Hallam-Baker]

So, I have completed the specs for DARE: Data At Rest Encryption. There is
a message format and a container format. I am now working on applying those
to the design of the Mathematical Mesh in the hope I can simplify greatly.

When I first proposed the Mesh I realized that if Alice is going to join
her laptop and her phone together in some sort of personal PKI, I was going
to require some form of 'postbox' service to allow messages to pass between
the devices in a fluent way. It is not possible to expect two consumer
devices to communicate directly as peers. It is not possible to expect a
consumer to have a server. So I ended up with an untrusted cloud service to
act as a dead drop.

By 'untrusted' I mean that the cloud service has no confidential data that
is not encrypted and has no control over the user's actions other than
refusing service. So if I am using Google as my sole service provider and
get into a row with them and they drop me, I can simply create a new
account on Yahoo, synchronize my profile and continue with almost no
interruption. Since my contacts all know my profile fingerprint, all I need
to do is send out an (automated) contact update notice and I am back in
business. They can talk to me and I can talk to them.

Having developed the Mesh concept, I then started defining applications
based on the Mesh capabilities and specified these as separate services. I
now realize that was a mistake. Users should only have to worry about one
type of service and one type of account. Separating the Mesh profiles from
other types of application data does not help, it only hinders.

Here, my applications are of two basic types, one is an application that
makes an existing infrastructure such as SMTP mail or SSH secure and easy
to use by managing key information. The second is entirely new applications
that make use of the three key cryptography I use.

So in the new approach, Alice has a Mesh profile that is hers and she
controls absolutely. She can use a single Mesh profile to connect to Mesh
services offered by multiple sites and create multiple accounts at a single
site that are all linked to one profile. If Alice wants to connect a new
device to her profile, she can use any of her accounts for this purpose.
Every Mesh application service has to support the subset of messages that
enable devices to be connected to a profile.

I also noticed that most of my Mesh applications consist of nothing more
than synchronizing a set of discrete objects across a set of devices, for
example usernames/passwords, calendar entries, contacts entries, SSH client
and host descriptions, email account descriptions. In the new approach, I
have a single protocol that synchronizes a 'catalog' of such objects (and
updates thereof) across the devices.

Messaging applications are very similar with the important proviso that the
request to append a message to a catalog comes from a third party which I
may or may not wish to grant that access to. So I have a series of layered
message types:

1) Connection request
2) Text only message
3) Message with attachments
4) Task item (calendar entry, task entry, buy this at Costco entry)

Connection requests should be short but not too short and allow just enough
information to know if someone is a person I want to add.

Task items and other messages that might interrupt me are obviously going
to require authorization. At minimum they have to be a contact but I
suspect I will require rather more personally!

I have not yet considered synchronous messaging but one feature that I have
always wanted is 'callback when free' integrated into the system. So if I
want to talk to someone, rather than set up an appointment, I ping them and
if they are busy, my request goes in their queue and when we are both free,
we are connected automatically.

Make sense?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180823/ba2e8725/attachment.html>