[Cryptography] Further thoughts on threshold key infrastructure.

[Phillip Hallam-Baker]

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).


I am now starting to think about how users can make use of multiple keys.

Alice (alice at example.com) and Bob (bob at example.com) both have multiple keys
for stored data. They have standardized (case insensitive) names:

message: For confidential messages, key is escrowed so that it can be
recovered after death.

data: For confidential data, key is escrowed so that it can be recovered
after death.

burner: For very confidential messages that it is intended for the key
holder only. This is not normally escrowed.

When creating a contact, multiple keys can be specified. Bob doesn't give
everyone his burner key but he has given it to Alice.

Alice can direct her messaging client to send a message to a particular key
using the syntax <key>$<account>@<domain>, e.g.:

burner$alice at example.com

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.

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:

burner$alice at example.com & 2020-07-18$expire at example.com

Here expire at example.com 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.

In addition to the and operation, we can have an or.

Mapping to SCI labels is pretty straightforward:

hayden at nsa.gov & noforn at sci.gov

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$
escrow at example.com

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).


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 escrow at example.com
service should be using key splitting under the covers.

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.


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.

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.

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).

Not sure quite what to do with this capability at this point but the
earlier stuff looks useful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200711/7a3de1ee/attachment.htm>