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

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 19 September 2019 16:42 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: mathmesh@ietfa.amsl.com
Delivered-To: mathmesh@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 578C91201E3 for <mathmesh@ietfa.amsl.com>; Thu, 19 Sep 2019 09:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nr66evm7uoF1 for <mathmesh@ietfa.amsl.com>; Thu, 19 Sep 2019 09:42:38 -0700 (PDT)
Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD6E120077 for <mathmesh@ietf.org>; Thu, 19 Sep 2019 09:42:38 -0700 (PDT)
Received: by mail-oi1-f195.google.com with SMTP id k25so3230654oiw.13 for <mathmesh@ietf.org>; Thu, 19 Sep 2019 09:42:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0Z/KeT+oBrjcpUM5TvLkqwsuNEEBa0bQG4mttMJsHfk=; b=e1c0FC4S/MhH3jW/bE2NrbjJcOjPWLsy8JMMGpmrWWaPiMJ1HhMsWPAv1F4kFUjBQJ Hfo/kR+5/qN6bM44dGkx5TqRz7WVRME/zGaS5Z0Lbwt0kvYcHN12jkgVp+Lg8K4HTos6 Cd3htKTyt8pEy+O5HbKi4xS5+1Zu5GI2LBbkm1g3ByedUgrQJ2s02qbLzIY5zv7zV+9X OHHH38XjHy20iGPPuJRMhOVD4n6MaKDgmQDrdsDycwDzDu2j+IJ7RrTNlnzCZOzLO2Y1 r4f4PJMIKALldomq+W0S7Lwq/PBSdQfFmkLwMlDLFcQvYJrYuiG4DaLKgcs0x0aX47Pe qhKw==
X-Gm-Message-State: APjAAAXZW5GpcEpJGAHd23fVZ1turjVmvQSI/GqDva/JDA8HJVKKzCN8 skVVpE/TRn1GsdpPHJbGAuIprWubNynYbe43siUQLyKa
X-Google-Smtp-Source: APXvYqz5mUYv9DnjqkSWIGjRqnJtft1QnKg7Wk+zbz9/7XPNYNYZ+uwS6HHWtOR63wbLJan/cjlkXzy0LzakymU1+kU=
X-Received: by 2002:aca:32d4:: with SMTP id y203mr2265088oiy.17.1568911357343; Thu, 19 Sep 2019 09:42:37 -0700 (PDT)
MIME-Version: 1.0
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 19 Sep 2019 12:42:27 -0400
Message-ID: <CAMm+LwjYg4uh6AsMNSw_5VVhYhqBo_0jdctpz+G2zUNn1QWFSQ@mail.gmail.com>
To: mathmesh@ietf.org
Content-Type: multipart/alternative; boundary="000000000000237c2f0592eaa43e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mathmesh/Swd80apIAWhTYVWomZkGaM1B_oo>
Subject: [Mathmesh] What part(s) of the Mesh should we charter a WG to address
X-BeenThere: mathmesh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <mathmesh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mathmesh/>
List-Post: <mailto:mathmesh@ietf.org>
List-Help: <mailto:mathmesh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Sep 2019 16:42:40 -0000

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
* 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
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

* 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

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