Subject: [Mathmesh] FW: mathmesh materials

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Nov 2019 20:33:30 +0000

Greetings!

Wes Hardaker and I are co-chairs of the Mathematical Mesh BoF which is meeting Monday, first session.

We are still working out the agenda – the biggest goal will be what parts of the problem to address – but here is a list of drafts, from Phillip. Thoughts on the agenda and process should be posted here.

1. Architecture [draft-hallambaker-mesh-architecture.html]

Provides an overview of the Mesh as a system and the relationship between its

constituent parts.

2. Uniform Data Fingerprint [draft-hallambaker-mesh-udf].

Describes the UDF format used to represent cryptographic nonces, keys and

content digests in the Mesh and the use of Encrypted Authenticated Resource

Locators (EARLs) and Strong Internet Names (SINs) that build on the UDF

platform.

3 Data at Rest Encryption [draft-hallambaker-mesh-dare].

Describes the cryptographic message and append-only sequence formats used in

Mesh applications and the Mesh Service protocol.

4 Schema Reference [draft-hallambaker-mesh-schema].

Describes the syntax and semantics of Mesh Profiles, Container Entries and

Mesh Messages and their use in Mesh Applications.

5 Protocol Reference [draft-hallambaker-mesh-protocol].

Describes the Mesh Service Protocol.

6 Cryptographic Algorithms [draft-hallambaker-mesh-cryptography].

Describes the recommended and required algorithm suites for Mesh applications

and the implementation of the multi-party cryptography techniques used in the

Mesh.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Nov 2019 17:43:21 -0500

So just to explain the constraints here, the mesh consists of three
technology components and the Mesh itself built on top. The technology
components are:

UDF (part 2)
DARE (part 3)
Meta-Cryptography (part 6)

The Mesh itself is described in parts 1, 4 & 5. Part 1 is the high level
overview and parts 4 and 5 are essentially reference.

So we can do any of UDF, DARE, Meta-Cryptography without doing the Mesh.
But the Mesh is built on top of the three tech components. It is not
possible to do the Mesh without the dependencies.

The Mesh is designed as a platform, it can be used to configure any
application and provision keys for pretty much anything. But I suggest that
we initially focus on just the one application, preferably one that
provides good 'test coverage'.

My preferred test application would be maintaining a password catalog
across connected Mesh devices. This tests out the full Mesh functionality
without requiring consideration of any external specifications. But if we
can do passwords, then the additional work required for SSH, OpenPGP,
S/MIME, etc. will be focused on the issues that are created by those
applications.

On Fri, Nov 8, 2019 at 3:33 PM Salz, Rich <[email-masked]> wrote:

> We are still working out the agenda – the biggest goal will be what parts
> of the problem to address – but here is a list of drafts, from Phillip.
> Thoughts on the agenda and process should be posted here.
>
>
>
> --
> Mathmesh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mathmesh
>