<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><p style="margin:0px 0px 6px;font-family:system-ui,-apple-system,system-ui,".SFNSText-Regular",sans-serif;color:rgb(28,30,33);font-size:14px"></p><p style="margin:6px 0px;font-family:system-ui,-apple-system,system-ui,".SFNSText-Regular",sans-serif;color:rgb(28,30,33);font-size:14px">I am now calling the Mesh a 'Threshold Key Infrastructure'. As far as I am aware, this is the first serious attempt to build a Key infrastructure with and for threshold keys. It turned out to be as different from PKI as PKI is from SKI (e.g. Kerberos).</p><p style="margin:6px 0px;font-family:system-ui,-apple-system,system-ui,".SFNSText-Regular",sans-serif;color:rgb(28,30,33);font-size:14px"><br></p><p style="margin:6px 0px;font-family:system-ui,-apple-system,system-ui,".SFNSText-Regular",sans-serif;color:rgb(28,30,33);font-size:14px">I am now starting to think about how users can make use of multiple keys.</p><p style="margin:6px 0px;font-family:system-ui,-apple-system,system-ui,".SFNSText-Regular",sans-serif;color:rgb(28,30,33);font-size:14px">Alice (<a href="mailto:alice@example.com">alice@example.com</a>) and Bob (<a href="mailto:bob@example.com">bob@example.com</a>) both have multiple keys for stored data. They have standardized (case insensitive) names:</p><p style="margin:6px 0px;font-family:system-ui,-apple-system,system-ui,".SFNSText-Regular",sans-serif;color:rgb(28,30,33);font-size:14px">message: For confidential messages, key is escrowed so that it can be recovered after death.</p><div class="gmail-text_exposed_show" style="display:inline;font-family:system-ui,-apple-system,system-ui,".SFNSText-Regular",sans-serif;color:rgb(28,30,33);font-size:14px"><p style="margin:0px 0px 6px;font-family:inherit">data: For confidential data, key is escrowed so that it can be recovered after death.</p><p style="margin:6px 0px;font-family:inherit">burner: For very confidential messages that it is intended for the key holder only. This is not normally escrowed.</p><p style="margin:6px 0px;font-family:inherit">When creating a contact, multiple keys can be specified. Bob doesn't give everyone his burner key but he has given it to Alice.</p><p style="margin:6px 0px;font-family:inherit">Alice can direct her messaging client to send a message to a particular key using the syntax <key>$<account>@<domain>, e.g.:</p><p style="margin:6px 0px;font-family:inherit">burner$<a href="mailto:alice@example.com">alice@example.com</a></p><p style="margin:6px 0px;font-family:inherit">The reason for picking $ is that it is a legal RFC5322 email address but rarely used. So it will be possible to record this type of address in many email client address books but isn't likely to cause issues.</p><p style="margin:6px 0px;font-family:inherit">The reason for not picking ^, & or | is that in a TKI we can perform REGEX like operations on keys, for example to specify that an email message will be encrypted so that multiple keys are required to decrypt:</p><p style="margin:6px 0px;font-family:inherit">burner$<a href="mailto:alice@example.com">alice@example.com</a> & 2020-07-18$<a href="mailto:expire@example.com">expire@example.com</a></p><p style="margin:6px 0px;font-family:inherit">Here <a href="mailto:expire@example.com">expire@example.com</a> is a public service that will perform a decryption operation against the 2020-07-18 but only up to 18th July 2020 when the key will (allegedly) be permanently and irrevocably erased.</p><p style="margin:6px 0px;font-family:inherit">In addition to the and operation, we can have an or.</p><p style="margin:6px 0px;font-family:inherit">Mapping to SCI labels is pretty straightforward:</p><p style="margin:6px 0px;font-family:inherit"><a href="mailto:hayden@nsa.gov">hayden@nsa.gov</a> & <a href="mailto:noforn@sci.gov">noforn@sci.gov</a></p><p style="margin:6px 0px;font-family:inherit">I would imagine we would also have an escrow key service that would only begin providing the decryption service on a specific date. 2020-07-18$<a href="mailto:escrow@example.com">escrow@example.com</a></p><p style="margin:6px 0px;font-family:inherit">It is probably a bad idea to enforce the semantics of the keys in the spec but people will naturally develop conventions in the same way that microformats are used for HTML forms (one of my proposals that people laughed at when I first made it in 1995).</p><p style="margin:6px 0px;font-family:inherit"><br></p><p style="margin:6px 0px;font-family:inherit">I am not sure how far to go with the key operations, is it useful/necessary to try to specify t out of n shares? Obviously, the <a href="mailto:escrow@example.com">escrow@example.com</a> service should be using key splitting under the covers.</p><p style="margin:6px 0px;font-family:inherit">Until now, I have been thinking of Shamir secret sharing in terms of splitting a key after it is created. But I have started to think that is maybe too restrictive.</p><p style="margin:6px 0px;font-family:inherit"><br></p><p style="margin:6px 0px;font-family:inherit">Lets say that we have a set of key share holders that each generate random points in the space {1..P', 0..P'} Where P is the Prime field for our elliptic curve.</p><p style="margin:6px 0px;font-family:inherit">We can now generate t out of t key shares simply by choosing any subset of these  share holders and treating them as a Shamir/Lagrange key set.</p><p style="margin:6px 0px;font-family:inherit">Or maybe we can get the parties to cooperate to generate additional shares for a particular set in a Lagrangy sort of way so we can get to t out of n shares (with appropriate verification proofs).</p><p style="margin:6px 0px;font-family:inherit">Not sure quite what to do with this capability at this point but the earlier stuff looks useful.</p><p style="margin:6px 0px;font-family:inherit"><br></p><p style="margin:6px 0px;font-family:inherit"><br></p></div></div></div></div>