Re: [saag] The Mathematical Mesh

[Nico Williams <[e-mail]>]

On Mon, Apr 22, 2019 at 11:17:07PM -0400, Phillip Hallam-Baker wrote:
>                    [...]. One distinction I do feel very strongly on is
> that the configuration of trust relationships between devices belonging to
> the same entity is a completely different issue to the problem of trust
> between entities.

So much so that it's even separable from the rest.

When it comes to one's own devices (for some value of "own"), the
introducer problem is trivially solved: one is the introduced, and
assuming physical access, the rest is trivial.

Indeed, smartphone vendors have even solved that -- within their walled
gardens anyways.

Getting an interoperable protocol for device key management widely
implemented would be a real coup.

> > But I do feel that the device management part is separable, even though
> > it's certainly critical for the UX.
> 
> I have no objections to an a-la-carte approach. The device management part
> is certainly the core here.

I'm not asking for it to be separated, just noting that it is separable.

Again, I'm looking for a pithy description of the proposal.  It's now
"all ove the above as to trust" + "open device key management".
Anything else?

> > > 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.
> >
> > It's always tempting to start from scratch...  But it's already been
> > done via OAuth/JWT.  Don't feel bad for not using SAML/XML.  Just make
> > the right choice.
> 
> Naturally and this is one of the reasons I have steered clear of the
> inter-trust problem because it has been the part of the problem we like to
> beat on most.

On the other hand, to follow an all-of-the-above path means
interoperating with existing protocols wherever that helps.

For example, there's no need for a replacement for PGP or S/MIME.  What
is needed is a way to simplify introductions and key exchange, to get it
down to scanning a QR code and pressing a button.  Ditto TOFU (though
that's trickier, naturally).  Ditto WebPKI.

I've this idea that DANE stapling in TLS could be used to provide not
just server authentication to clients, but also user authentication to
servers, using client EE certificates with rfc822Name SANs and DANE to
authenticate the domainname of a client certificate's rfc822Name SAN(s).

(Many don't trust the DNSSEC root any more than others trust WebPKI, but
for most users, anything is better than nothing.)

The varying levels of trust will surely complicate the UI somewhat.  At
least power users will want to be able to see some indication of trust
strength / how an introduction happened.

Nico
--