Look up keys by profile name (reverse lookup)

caesar

Would you consider adding to keyoxide (web and cli) the ability to look up claims by mechanisms other than hkp and wkd?

I am thinking of a kind of "reverse-lookup": for certain profiles, it could be possible to enter the profile URL and keyoxide could look up that profile and check whether it has an identity claim, and then proceed to obtain the relevant key and verify the claim as usual.

For example, given a URL, keyoxide could load that URL and look for a link with rel="pgpkey", and then proceed to verify any claims made on that key.
Pattern matching could also be performed on certain URLs, such as Github, where the location of the PGP key (if present) can be reliably linked to the profile.
Entering an email address would proceed to do a WKD lookup, falling back to an HKP lookup if that fails.
Etc.

This would make it possible to check someone's identity and find linked identities without having to manually enter the PGP fingerprint. The experience would be a bit more like Keybase, and a bit easier for somewhat less techie people I think.

What does anyone think about this suggestion?

yarmo

I'll invite a friend to this topic with whom I've extensively discussed this point before.

At the time, our conclusion was:

technically feasible,
maybe not desirable as it could facilitate harassment

If ill-intentioned people know one of their prey's accounts, they could then easily find others. This is a weak argument since they can do this with their fingerprint anyway. But adding this function would still facilitate.

There is something we can (and should) do: allowing proofs to be (securely) hashed. This would make it possible to verify identities but not reveal the identities! With hashed proofs, I'd feel a lot better implementing reverse lookup because then, people could opt out of reverse lookup by hashing proofs.

What are your thoughts on hashing proofs, @caesar ?

caesar

Thank you both @wiktor and @yarmo for your thoughts on this.

yarmo maybe not desirable as it could facilitate harassment

This was a point I hadn't considered, and is obviously very important. We definitely don't want to be linking users' profiles together without them wanting that.
That said, I think that explicitly (a) adding your profile links to your published PGP key and (b) adding your PGP key link or fingerprint to your other profiles is quite a clear opt-in to linking those profiles together.
But definitely, this would be something on which a lot of community input should be sought to consider any potential harm and whether this would be expected behaviour on the part of people publishing their profile claims.

yarmo There is something we can (and should) do: allowing proofs to be (securely) hashed.

This sounds very interesting. From a technical point of view, how do you imagine this working? Presumably it's just the proof, and the claim is still plaintext?

yarmo With hashed proofs, I'd feel a lot better implementing reverse lookup because then, people could opt out of reverse lookup by hashing proofs.

Agreed.
Signature claims seems like another way to use Keyoxide while "opting out" of exactly this issue of your profiles being publicly linked.

wiktor I see that this couldn't be implemented for all proofs (e.g. it's not easily possible to identify proof document given user's github handle as we'd have to browse through all gists).

Definitely true. This would never be feasible for all proofs. With the example of Github, hopefully when https://codeberg.org/keyoxide/doipjs/issues/19 is implemented this would be much easier. And as you say, for other providers like Mastodon and Facebook, and for people's homepages if they link their PGP keys, it would be technically easy.

wiktor Keybase had its own database of all proofs [...] Currently Keyoxide operates in a "stateless" mode

Absolutely. Keyoxide should definitely remain stateless. So if this happens, it should only be for those sites where PGP keys or fingerprints are publicly published.

yarmo You mean like https://keyoxide.org/hkp/yarmo@yarmo.eu? 'Cause we already have that 🙂

Kind of. I actually wanted to bring this up separately, but: though it's useful to be able to specify WKD or HKP if you understand what those mean, I'll wager >90% of people with PGP keys (already a vanishingly small population) have no clue what those terms mean. I'd like it if the default was an "auto" mode, rather like what most clients do when looking up an unknown key: try WKD first, then if it fails, try HKP.
So for example, https://keyoxide.org/yarmo@yarmo.eu would use that "auto" strategy, rather than only trying WKD like it does now.

wiktor

Hmm... I see that this couldn't be implemented for all proofs (e.g. it's not easily possible to identify proof document given user's github handle as we'd have to browse through all gists).

But a limited version that you also outlined: WKD/HKP lookup by e-mail? Why not! keys.openpgp.org has e-mail based lookup too.

For some providers like Mastodon it's also possible as the proof document is in the profile.

For the record Keybase had its own database of all proofs so they could easily query for "give me all proofs for someone that's X on GitHub". Currently Keyoxide operates in a "stateless" mode and this makes it quite a lot easier (and there are no GDPR questions and the like).

yarmo

wiktor I see that this couldn't be implemented for all proofs

Very true. Same for Twitter (you need to know the tweet ID) and others.

wiktor WKD/HKP lookup by e-mail? Why not!

You mean like https://keyoxide.org/hkp/yarmo@yarmo.eu? 'Cause we already have that 🙂

yarmo

caesar That said, I think that explicitly (a) adding your profile links to your published PGP key and (b) adding your PGP key link or fingerprint to your other profiles is quite a clear opt-in to linking those profiles together.

Very true. Maybe you wouldn't want to link accounts if you're susceptible to harassment. Linking things together is inherently opt-in. Still, I would like to implement hashing first.

caesar This sounds very interesting. From a technical point of view, how do you imagine this working? Presumably it's just the proof, and the claim is still plaintext?

Indeed. The claim is what it always is. But the proof is a bcrypt-hashed fingerprint. Knowing the fingerprint/key, you can verify the claims. Knowing/finding a proof, you can't backtrack it to the fingerprint/key.

caesar So for example, https://keyoxide.org/yarmo@yarmo.eu would use that "auto" strategy, rather than only trying WKD like it does now.

You're making me doubt now but I think auto mode does exactly this! https://keyoxide.org/yarmo@yarmo.eu first checks WKD and if it couldn't find it there, it would check keys.openpgp.org. (this is how I remember implementing it... Is it reality though? 🤔)

Keyoxide links with only a fingerprint go straight to keys.openpgp.org

caesar

yarmo The claim is what it always is. But the proof is a bcrypt-hashed fingerprint. Knowing the fingerprint/key, you can verify the claims.

Makes sense, and should be relatively easy to implement I guess. Sounds good.

yarmo You're making me doubt now but I think auto mode does exactly this! https://keyoxide.org/yarmo@yarmo.eu first checks WKD and if it couldn't find it there, it would check keys.openpgp.org. (this is how I remember implementing it... Is it reality though? 🤔)

Seemingly not. For an address which doesn't support WKD, an error is displayed: https://keyoxide.org/support@gpgtools.org fails, whereas https://keyoxide.org/hkp/support@gpgtools.org works.

Also, it would be nice I think if "auto" mode was explicit (and the default) in the UI, not just when manually building the URL. At present HKP seems to be the default in the UI, whereas (barring an advanced user wanting something different) from a trust standpoint WKD should always take priority if available.