[saag] Key Management in the Mathematical Mesh

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

I didn't hear about the session until after it occurred. It might have been
useful to advertise the BOF on SAAG, it is one of the things the SAAG list
is supposed to be for.

My view is that it is a feature of a key management infrastructure and not
a standalone protocol. I have running code which I am in the process of
deploying this year so my interest in starting from scratch to implement a
small subset of the problem that isn't useful on its own is nil. Plenty of
people have known I have been working on this, I am rather surprised nobody
invited me to participate. Or rather I am not surprised at all.


The minimum viable feature set is contact exchange. Alice is a developer,
she joins a project using Github that is applying software lifecycle
assurance. This requires her to provide an SSH key to access the
repository, an OpenPGP key to sign her commits and various PKIX
certificates for signing development releases on different platforms. All
these keys are 'Alice' but plonking them all into a hash chain individually
isn't useful because we need to know that they all relate to Alice and that
they have specific purposes. So that leads us to a signed contact assertion
which is of course just another form of certificate. but it is in JSON
format so, thats OK.

Alice can exchange her Mesh contact assertion via QR code in person,
various forms of remote exchange or rely on TAFU. Once she acquires Bob's
contact assertion, she puts it in her contacts catalog which is a Merkle
Tree validated sequence.

Alice attends an IETF, she checkpoints her contact assertion during
registration. This adds the cost of attending an IETF in Yokohama in 2023
to the social work factor of her contact assertion. And that can be used by
Bob in 2027 to determine that if the contact assertion she presents is a
forgery, the impostor spent $4000 four years ago to establish it. It would
not be difficult to achieve a pretty sizable social work factor in a fairly
short time.

This is something I proposed a decade ago, long before the Blockchain
bandits started attempting to patent everything that moves. I have strong
prior art for my system.


The Mesh approach has the feature that every user is their own ultimate
root of trust. If Alice is asking 'was this document signed between dates X
and Y' and she was participating in the Mesh at times X and Y, she can
validate that assertion by consulting her own notary log. No third parties
are required.

The scope of this aspect of the Mesh is not limited to keys, it is designed
to authenticate digital evidence so that if there is a court case in which
the evidence of Alice the forensic expert is being challenged, this can be
demonstrated against the notary log of the court, or the state or NIST if
they are participating in the Mesh.

This is possible because everything in the Mesh is represented in an append
only log format authenticated by means of a digital signature over the apex
value of a Merkle Tree:

https://www.ietf.org/archive/id/draft-hallambaker-mesh-dare-16.html

So Alice isn't doing anything special to run a notary log, she just creates
an entry in her log when she signs her data. She periodically adds the apex
values of her personal catalogs and stores to her personal notary log and
signs them. She also periodically exchanges apex signatures with her Mesh
Service Provider to achieve 'cross notarization'. Mesh Service Providers
periodically cross notarize with the callsign registry which is one way to
connect the graph but doesn't need to be the only way.


The 'gossip' protocol with a public blackboard mentioned in some of the
slides is the same idea but lacks the scaling. It never happened for CT and
I see no reason for it to happen for KT without a strong business model to
support it. One of the main reasons I needed the callsign registry was
precisely to provide a business model to support a central node that could
connect the Mesh notaries together.

Perhaps some of you might actually look at some of the work I have done
over the past five years before you try to repeat it.

I have built an operating system for cryptography: It manages the private
keys you use across all of your devices and all of your applications and it
manages the public keys of the other parties you rely on. And it does all
of that without users ever having to know they are using cryptography.