[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [209.85.167.195]) (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 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
- [Mathmesh] What part(s) of the Mesh should we cha… Phillip Hallam-Baker