Certificate expiration

[rjflp]

Public keys usually have an expiration data to limit the impact of an eventual compromise. In some PKI, there is a way to revoke credentials should the user believe the private key to have been compromised.

We are using a GUID that is derived from a public key. We want the GUID to last a very long time (a lifetime for a person, more for a company?).

Is is safe to assume that a public-private key pair can be used that long? What are the alternatives?

[rjflp]

We must assume that a key may be compromised. As such there has to be a way to revoke a key/entry in the DHT.

One possibility would be for revocations to be stored in the DHT, using the same private/public key that is being revoked, but a different key (also derived from the public key). Revocations could not be removed from the DHT. Accessing the DHT would imply 2 accesses, one for the data and another to verify if the GUID had been revoked.

Another possibility, proposed by Felix, is to look into block chains.

[sgoendoer]

In the proposed solution, the GUID is bound to the key indefinitely. Hence, if we want keys to become outdated at some point, this would also outdate the matching GUID. Revoking keys is a problem, as a new key would result in a changed GUID. Looking into alternative BlockChain mechanisms is of course an option which we will further pursue.

We have a similar DHT system running as of now. Here, we use two key pairs, of which one is for creating the lookup key (GUID) and the other one is for signing/encrypting data. The latter key can easily be revoked, while the first key can only be exchanged when you are "abandoning" your GUID entirely.