[Mathmesh] What part(s) of the Mesh should we charter a WG to address

[Phillip Hallam-Baker <[e-mail]>]

My objective with the Mesh is to address three problems I see as critical
for addressing current Internet security concerns.

* Management of private keys across devices and accounts.
* Obtaining and verifying public keys for devices and accounts.
* Securing data at rest

To meet these needs, I have developed a technology platform that has three
separable parts:

* The UDF identifier infrastructure which encapsulates naming an addressing
functionality,
* The DARE envelope and sequence formats which applies JSON and JOSE to
support PKCS#7/BlockChain/more
* The Mesh infrastructure consisting of the Mesh Schema and Mesh Service.

While it is in principle possible to separate the last two, I can't see
that as having any point as they are designed to be interdependent.
Similarly, DARE is built on UDF and the Mesh 3.0 is built on DARE so you
can't do just the Mesh without UDF but the reverse is possible.

So the question raised in Montreal was should we address one, two or all
three?
I am currently trying to complete the specifications for the Mesh part. By
complete, I mean that the specifications should be implementable with no
essential functionality missing with running reference code that does not
show obvious gaps.

Complete does not mean final. We can certainly make changes and that is the
point of having a standards process. The point of getting to a complete
stage is that it should no longer be necessary to make a change. We could
decide it was all a bad idea, publish the document set as 'experimental'
and walk away quietly.

>From a research point of view, the primary novel contributions are as
follows:

* UDF identifiers provide 'Rails for cryptography'. Choosing a single
identifier and applying it consistently greatly simplifies design.

** Strong Internet Names allow any Internet address containing a DNS
component to be bound to a security policy that determines its
interpretation. This mechanism may be used a means of representing the
outcomes of a traditional CA based trust mechanism (e.g. PKIX/WebPKI) or as
a direct trust mechanism.

* DARE envelopes enable the use of threshold cryptography (i.e. splitting
the decryption key) to enable data to be shared with dynamic groups of
users of devices.

** A user who has acquired a new device can immediately enable decryption
of end-to-end messages and data previously received while retaining the
ability to remove the capability if the device is lost or stolen.

** Sharing of encrypted documents and data between groups of users enables
the subset of DRM capabilities that are useful and may be implemented
without relying on trustworthy hardware.

* DARE Sequences support incremental authentication (aka BlockChain) and
incremental encryption.

** DARE Catalogs provide a lightweight persistence mechanism well suited to
small data objects which permit straightforward implementation with ACID
properties.

* The Mesh overcomes the challenges presented by private key generation and
distribution in traditional PKI through use of threshold cryptography
techniques in reverse.


PHB