Key verifications

(If a key is not listed below, the policy did not apply at this time. Such signatures have probably already expired, but they should be handled with care - although there was no time at which I just signed keys without checks)


I have verified some PGP keys, all of which have their verification method documented. My verification is usually done with my PC being behind a VPN to prevent anyone from messing with my home internet. This should prevent someone messing with the DNS servers and thereby DKIM. The server provider messing with DKIM is possible but I trust it more than a consumer ISP.

My policy

For a verification level of 3 (very careful): Server owner could impersonate E-Mail alone, but the passport check prevents this. The SE message can also be sent over a non-email channel to prove ownership of that channel and add an extra hurdle for the server owner.
DKIM is generally not a thing people attack, but even this is accounted for due to the passport check (assumption: a MITM would not own the passport corresponding to the person they are impersonating the E-Mail address of).
For a verification level of 2 (casual):

Same as 3, but no name check.
This assumes trust in the owner of the E-Mail server (in case of a non-self-hosted one) and a correct name to be set in the key.

"Casual" checking is therefore enough in almost all cases

My casual checking means ownership of the internet identity, my very careful checking means ownership of the real-life AND internet identity.

Verified keys

la@laker.gay: DB1FD88767ABB9CD
cait@piplabs.dev: 7803B6193E092BAB
pdp8@tudbut.de: 99C3525403C30B99

Afterword about vulnerabilities

TL;DR: Only tell me about a vulnerability in my policy if it's not entirely ridiculous.


PGP is never going to be 100% secure. In fact, nothing is ever going to be 100% secure. Vulnerabilities are everywhere and people are human and will make some mistake somewhere. There is no way to verify a key with 100% certainty without being an allknowing being, and I doubt the average being reading this (or me) is one (and if so, hi!! go talk to me).

A possible vulnerability in my policy would, for example, be me just randomly hallucinating. The same applies to any other policy. Someone could even exfiltrate my keys from my computer using some super good antenna to read my SSD's output datastreams. At some point, these worries are ridiculous, and it's more likely you're just hallucinating this web page than those things happening.
A government could probably read the messages we send if they really tried. There is always a flaw. But no government has time to inject a wrong DNS entry, hijack a CA in order to hijack my https connection to archlinux.org, then modify the install medium I download to contain a specific backdoor, and then monitor my every move. And if they do, we're all fucked anyway. The web of trust has an end, and we are never going to be able to fix that. The real world is sadly insecure. Even passports can be forged, especially by governments.

This is not to say stop trusting anyone, but rather to stop pretending you can verify trust with a 100% accuracy. This is why it's called "very careful checking", not "fully accurate checking".

Your key signing parties are just as insecure as any other decently thought out verification method. If you find a vulnerability in mine, YES PLEASE TELL ME, but only if it's not entirely ridiculous. Once again, do tell me if its not though.

Afterword about names

If you use a different name to that of your passport, I will still sign your key with level 3, as long as you have some kind of explanation for that and I trust you enough. I will note in the verification doc that your chosen name is not your government name though. If your method of verifying people excludes trans people who cannot change their government name, that makes me really not want to talk to you, so please fuck off if this bothers you. I will only do this if I feel like it's safe, and I will still usually want to see your passport to background check if you coincidentally work at the company providing the E-Mail server the key uses.