Email validation support

[DemiMarie]

This is necessary to comply with e.g. GDPR and other such regulations.

[andrewgdotcom]

The price for implementing email validation is that keyservers can no longer sync. One of the following scenarios would apply:

a. Keys that did not email validate on submission would find their way onto every keyserver anyway via sync from other keyservers
b. Keyservers would email validate both on submission and sync, which would flood the end user with noise
c. Validating keyservers would hard fork from the rest of the network (this is what hagrid chose)

[DemiMarie]

The price for implementing email validation is that keyservers can no longer sync. One of the following scenarios would apply:

a. Keys that did not email validate on submission would find their way onto every keyserver anyway via sync from other keyservers b. Keyservers would email validate both on submission and sync, which would flood the end user with noise c. Validating keyservers would hard fork from the rest of the network (this is what hagrid chose)

Another option would be for some keyservers to trust other keyservers to perform validation. It is also possible to sync signatures of existing user IDs even without this, provided that attestation signature support is implemented.

[andrewgdotcom]

@DemiMarie the first suggestion is effectively the same as c), but with an added governance problem. How will keyservers decide which other keyservers to trust? I suspect we may end up having to go there, but doing so without imposing a central authority is a very tricky problem that nobody has yet solved (suggestions welcome!)

On your last point, there does appear to be general agreement that attestation sigs are the long term way forward, but they're not widely supported in clients yet. I think we would be premature in requiring them for keyservers, although that shouldn't stop us adding the necessary code in advance. :-)

[alexandre1985]

I am in favour of validating a key through an email, in order to be on the keyserver.

One option is to:

Have a flag as "unverified key" (default value) in the database and only sync with other keyservers the "verified key" keys. Then, only when the email link for key verification is visited, then the key is marked as "verified key". Then create a command, that can be put in cron by sysadmins, for deleting all unverified keys that have been uploaded more than X minutes ago. Also, create a command for cron that delete all revoked keys, that have been revoked more than X minutes or X hours ago.

This solves the problem.

Also, there should be a warning in the keyserver webpage that says that a user must create a revocation certificate when generating a key pair, and to save this revocation certificate in a safe place. So that the user may, in the future, delete the key data from the server, even if the private key is lost.

All of this, should make it GDPR compiiant, for a reasonable interpreter of the GDPR law. And no security issue is made by this approach (the hockeypuck-way has a security issue regarding key deletion, by DNS MX record cache poison or middleman email server nasty admin spying).

This should calm down, logical users that want GDPR enforced on sks servers. Every other GDPR user not satisfied by this approach, is irrational people.

Thank you @DemiMarie for opening this thread. This is a very important issue.

[andrewgdotcom]

If we only sync verified keys, what happens to the historical database of keys? And who does the verifying? Do keyservers need to cryptographically sign the verification status of all their keys? Also, blanket deletion of revoked keys after a time has other issues. Do all keyserver operators need to agree on the waiting period? Can an attacker wait for every copy of a key to be deleted and then re-upload a copy with the revocation stripped off? What if I, the key owner, WANT my revoked key to be permanently available?

I'm not aware of any attack against key deletion on hockeypuck that involves DNS or MITM. There is a potential replay attack using the signed deletion request but that doesn't affect RTBF - it merely allows an attacker to re-delete a key that was re-uploaded after a previous deletion, which is a concern for poisoned keys, but not RTBF. And if you're worried about DNS MX record poisoning, key verification is the weak spot, not deletion.