[Keytrans] More prior art

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

It is always useful to know what already exists, I have been working on
applying BlockChain technology to certificates since before BitCoin
existed. I even tried to buy out the Surety patents at one point.

So, I have this in the public record going back to at least 2013-10-16. If
necessary, can go back further.

https://www.ietf.org/archive/id/draft-hallambaker-mesh-trust-09.html
https://datatracker.ietf.org/doc/draft-hallambaker-prismproof-trust/

I am not sure if it addresses Plausikey directly, but it does describe the
basic notion of churning keys and key assertions into an authenticated
append only log and provides metrics for evaluating the benefit 'social
work factor'.


My plan was to demonstrate this system at SF and then I got COVID and lost
three weeks development time:

https://datatracker.ietf.org/doc/draft-hallambaker-mesh-architecture/

The code all runs in console mode. What I expect to deliver in a very few
weeks is an end-to-end secure iOS/Android app that allows people to

* Connect as many devices as they wish to their personal mesh,

* Connected devices are automatically provisioned with credentials
according to their designated role, e.g. 'IoT', 'admin', 'developer',
'messaging'. My toaster does not need my code signing or email
decryption keys.

* Create contact assertions containing a set of contact addresses and
public keys, 'family', 'work', 'developer', 'vendor'

* Exchange contacts with minimum  2^120 bit work factor authentication via
a range of modalities (QR code in-person, remote).


The Mesh is based on authenticated sequences of encrypted data. I have not
yet implemented signing the sequence but that is merely signing the zone
apex. The dev issue is actually writing the test code rather than the
implementation.

By the time we meet at Prague I hope to at least have a prototype of an app
in which everyone runs their own notary log which is used to periodically
checkpoint all the other catalogs and spools and to notarize important
signatures (e.g. contact assertions).

The user periodically cross notarizes with their Mesh Service Provider
which in turn (typically) cross notarizes with the Mesh callsign registry.

The net is that if Alice is asking the question, 'Did Bob sign this
document at time T', she can come up with an answer 'Bob signed the
document after T1 and before T2' and the ultimate source of trust for that
is Alice's own personal log.

Of course, people may need greater fidelity for certain applications but
the risk of relying on a TTP for notary log signing is really small because
1) it is really only possible to defect once and 2) we can validate against
as many TTPs as we like and they had better all give the same result.


The long term plan is to allow people to reinforce their credentials with
as many checkpoints as they like. So for example, I might bring a laptop to
Prague and just have it running with an app that runs the contact exchange
protocol. Anyone who want to can do a contact exchange against the device
which will create a signed assertion 'Fred was at IETF118'.

Now lets say Fred is wanting to join the GPG developer group and they
(understandably) ask 'WTFAY', Fred can say, 'I am the Fred who went to IETF
118, BlackHat 2024, RSA 2025, etc. etc.'

Not proof perfect that Fred isn't a bad 'un but vastly better control than
we have ever had in the past.


Like I said, I do have running code. The code base is essentially JSON
based but for encoding efficiency, I use a superset of JSON which uses the
unused tag code points in ASCII for binary tagging.

As folk can probably understand I am not going to be very interested in
proposals of the form 'please delay release of the thing you have been
working on for over a decade, the last five at your own expense to switch
to this random encoding we think is prettier / let us start thinking about
the problem'.



On Mon, Jul 31, 2023 at 8:56 AM Kai Engert <[e-mail]> wrote:

> Hello,
>
> shortly, in a separate email, I will send a document that describes a
> potential solution for key authentication and key transparency for
> OpenPGP public keys for email addresses.
>
> At this time I don't have the document published anywhere on the web.
>
> To ensure nobody can claim to have had this idea before, and to
> hopefully prevent anyone from registering any patent claims or similar,
> I'm sending the full document to this list, to create a proof that this
> idea has already been published.
>
> I release this idea into the public domain, I have not submitted any
> patent claims, and don't intend to do so, and hopefully nobody else will
> ever be able to successfully submit such a claim.
>
> This disclaimer is just me being careful.
>
> I haven't yet shared this idea with anyone else, so it might as well
> turn out that the idea is nonsense or impractical or has obvious flaws,
> in which case I apologize for the noise.
>
> Best Regards
> Kai
> --
> Keytrans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/keytrans
>