Re: [Secdispatch] [saag] The Mathematical Mesh

Phillip Hallam-Baker <> Mon, 22 April 2019 19:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 432D2120124; Mon, 22 Apr 2019 12:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 75fwr7JsmECN; Mon, 22 Apr 2019 12:33:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 47B5D120123; Mon, 22 Apr 2019 12:33:34 -0700 (PDT)
Received: by with SMTP id v10so9363415oib.1; Mon, 22 Apr 2019 12:33:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vGnOJfZDvIOCpeXXnimpAv895YNN7/o1N5nVDiI/kBc=; b=sUnXM5uwPZzoTnrwpZl7xhWjai/Plirs1sdUEBnBpXTq5ExiEXfqgDAnxQoXUdFpHY Okn1vsjzBPgteUn1mOZV+uIiHNDm4NEk2Dc49o3LQST0Xie6bmJOTNdGHy5cDs+0ORrp lDaLho+3ViWkhuKDpDiR9iNoGxPyV7h112QuHpuZQWVPy9DHIKfVps1Vde2GH8ivgRZB 5m9s8r8jrUSv7LvBbXVCOtbrXWYrOvBxdEQYK3YLtjJ78t543ea8Dy/I7U05tQBxO7Pk YlrWgpepJD+czAdIGQ8Pe+XYw3YqhkpcFHn/sEA3dTK1UfzM1j3ndk9fSQNX10Dt9jmR AFlw==
X-Gm-Message-State: APjAAAXGyXu48UHi1o8E81JOjiLflXFkdrOhDoBanD9E/jIDg3QBmu5D fZrU0QI6zgDRVAJtNotdhwW2/oIqcis/CsBLfmsk81Ig
X-Google-Smtp-Source: APXvYqxOhXW8pq7cW8B+4/zwPwvXD1sGCsNyXXKRDAmr+DY9Zh3F1ypTj/DlSJdDvgZSkoDKad97yPtPhM+tEp0JUb8=
X-Received: by 2002:aca:b8c4:: with SMTP id i187mr11351077oif.6.1555961613481; Mon, 22 Apr 2019 12:33:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <20190422190302.GA3137@localhost>
In-Reply-To: <20190422190302.GA3137@localhost>
From: Phillip Hallam-Baker <>
Date: Mon, 22 Apr 2019 15:33:22 -0400
Message-ID: <>
To: Nico Williams <>
Content-Type: multipart/alternative; boundary="000000000000417c1d0587238bad"
Archived-At: <>
Subject: Re: [Secdispatch] [saag] The Mathematical Mesh
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Apr 2019 19:33:36 -0000

On Mon, Apr 22, 2019 at 3:03 PM Nico Williams <> wrote:

> Is it fair to characterize this as something of a PGP trust mesh on
> steroids?  If not, how does it differ?
> (Yes, I do see that your scheme has decentralized device management for
> individuals, which is a bit of a new thing and very welcome.)

The objective is to give users the power to control their own security

This includes but is not limited to the ability to make use of Web-of-Trust
approaches or delegated trust, delegated distrust or a combination of all
three which is actually the approach I think works best.

The primary focus is enabling real users to manage public key pairs on
their devices without being aware that they are doing it. Securely
establishing a set of public key pairs on each device and providing a
validation path to the user's personal axiom of trust is the main idea
here. Because if we achieve that, we are 80% of the way to securing almost
any communication pattern.

Trust topology is something I think we should be opportunistic on and use
every available option. For example:

* We meet at an IETF and exchange our master profile fingerprint directly
using the QR code exchange.
* You meet Alice at another meeting and directly exchange credentials using
the QR code exchange.
* I add Alice to the GitHub repo for the project based on your
* I add my personal banker to my account based on an Extended Validation
certificate authenticating his bank and an assertion issued by the bank
credentialing him as a current employee.

Right now, I am doing everything in JSON and the Mesh Assertion
infrastructure. It is pretty obvious that some of this is SAML territory.
But where should the boundary be and should we make use of the XML SAML
binding or switch it to a JSON encoding? I don't know what the right
decision is there or have time to think about it.

I have only scratched the surface as far as applying the key co-generation
and splitting techniques I use. We could use them to distribute TLS
certificate key pairs as well.