Motivation

To prevent spam, we wish to allow users to demonstrate ownership of their claimed User IDs. This can be done interactively by making a verification request to that User ID (such as sending an email containing a link), however in a distributed network this would involve either all network members sending out their own verification requests, or each member implicitly trusting all other members to perform verification correctly.

It would be preferable for each User ID to have a proof attached to it, the validity of which could be checked without further interaction. This could be done using existing cryptographic proofs for email antispam, in particular DKIM.

Examples of interactions

TBC

Design

A client would send an email containing its public key, and its email service provider would automatically sign it using DKIM. A keyserver could receive that email via SMTP, verify the DKIM signature, and store the received email as an offline proof. Alternatively, a client could send the proof email to itself, and then submit the key plus the DKIM-signed proof over HKP, with the same result.

Since DKIM signing keys are long-lived, other keyservers in the network could independently verify the proof. Keyservers would then store the proof in their database and distribute it to their peers. Keyservers should verify the email proofs of User IDs newly received over HKP or sync (or email, if supported). They are not required to verify the proofs of known User IDs, or of User IDs newly restored from a dump.

When a client requests a User ID search, a keyserver would serve results that had a valid proof first. A client could choose to request only those results with a valid proof.

Out of scope

TBC

Security considerations

The proofs described above are not equivalent to web of trust calculations, and a client SHOULD still perform these wherever possible.

Compatibility

This would need client support, and it may be easiest if we implemented our own client tooling.