Follow

OpenPGP Proofs
«This document describes a method of adding social proofs to OpenPGP keys in a way that can be independently verified by clients. This is similar to Keybase but decentralized.»
github.com/wiktor-k/openpgp-pr

This is AWESOME!!
Here's how to join @wiktor's decentralized keybase replacement effort, using myself as an example.
alexschroeder.ch/wiki/2020-05-

Thank you so much, Wiktor! That’s all I ever wanted Keybase to do for me. And now there’s a way to do this, but decentralized. This is awesome.

Show thread
@kensanata yeah but can we just not use PGP/GPG though? Pretty please?

@feld @kensanata Every time I have to learn how to use GPG, I spend a few hours learning all the details and I realise just how clever it is. Then I do what I need to do and instantly forget how it works.

@kensanata I will definitely be looking this over. I have been revoking my proofs for many accounts. Continuing a slow retraction from keybase...

@PresGas heh. I deleted my account and left all the proofs. I need to look into this stuff.

@kensanata I believe if you deleted the account the proofs are kinda already deleted. Here is what I see when I look you up. ...I can't look at you except from our shared conversations where I "@"-ed you:

@PresGas Oh, right. What I meant is that I didn't go and delete the DNS TXT entries, or the "it is proven" messages all over the net.

@kensanata Yeah. I am not worried about the social parts so much, but want to clean up the DNS/HTTP entries for sure. That is why I didn't kill them off yet.

@kensanata I... I can't follow that, at all. As in: Not one word of that makes sense.

@dgold my hope is that this is a simple local web app that does what keybase did: it verifies that a key I received belongs to an account I know from GitHub, Reddit, Mastodon, DNS, etc.

@kensanata I don't understand the role of "proof@metacode.biz" in this in terms of decentralisation...

@dgold From the FAQ: "RFC 4880 specifies this kind of format as a way to namespace custom notations. You need to create notations under the domain that you own to avoid conflicts. I used my own domain for this protocol. Ideally the notation key would be just proof. Using this kind of keys (without @ namespacing) is only allowed for IETF-approved extensions though (I did not approach them)."

Thus, it's just a key.

@kensanata so instead of proof@metacode.biz i can use proof@example.com?

None of this is clear in that document...

This needs to be rewritten as a HOWTO

@kensanata @wiktor i mean, as long as we don't try to use PGP for anything serious like encryption or signing i guess i'm okay with this

@hirojin @kensanata @wiktor *sends burn ointment* 😂

I have to admit that a more compelling option would include a mechanism for other people who can verify your identity to sign your key. That's the main thing that was always missing from the keybase equation.

@trechnex Well, I never went to a key signing party and I never signed a key so as far as I'm concerned, that mechanism doesn't work. If you do believe in the web of trust, then you don't need keybase or an alternative because who cares about social media accounts when you have signed proof of identity checking, right?
@hirojin @wiktor

@kensanata @hirojin @wiktor I was thinking in terms of other user accounts on other servers saying "yes, that's the real deal" and using that as an extra form of authority in addition to proofs.

It'd be kind of like the page-rank algorithm for PGP keys, but would need some thought so you didn't have the equivalent of "SEO" types gaming the system.

@trechnex @kensanata @wiktor would this imply you can't ax an old key, and have to keep it safe and secure forever, or are you imagining some other vector? such as, someone verifying two or more of your social selfs as being connected? more or less independent of your PGP key, which is only the carrier of the information

@hirojin @kensanata @wiktor as a person who's not a security researcher, I don't pretend to know the answer to that 😅

If the system is going to last longer than five minutes, it probably needs a mechanism for lost keys to be revoked and replaced. So my best guess is trusting the creator of the keys and where you're verifying them rather than the keys themselves.

@kensanata @trechnex @wiktor (i have been to multiple key signing parties (in my youth), which is why i don't believe in the Web of Trust)

@clacke @kensanata @trechnex there are 2½ types of key signing (party)

1: i sign your key because I'm drunk and it's fun
2: i sign your key because i verified your passport and trust that
½: i sign your key because i believe in the Web of Trust

and why i gave up on it:

1: i stopped having fun AND drinking
2: i'm not a cop
½: 1 & 2 made me stop believing in this

@trechnex @hirojin @kensanata @wiktor Wouldn't strengthening the trust be covered under traditional key servers or am I missing a piece of this?

Cool! I will share your article with people that want to see how to add social proofs step by step. Thanks for writing it!

Maybe at the bottom you can add a note to publish the key because it may trip some people (proofs are not visible on the web page if they’re not on the key server).

I see on the screenshot that you have this User ID on your key: Alex Schroeder <alex@alexschroeder.ch> if you want to you can also put your key on your own domain via Web Key Directory: https://metacode.biz/openpgp/web-key-directory so you wouldn’t have to use keyservers (keys.openpgp.org is fine with me btw :)).

See you! 👋

@kensanata Oh also! Could we figure out a way to verify your Discord user using a special server and the widget/embed API, and you post your proof in that channel?

@mathew I fear I'm too simple minded for it. I see a lot of jargon, something about a local keysd daemon and I'm thinking: this is not what I want. In the "Why?" section it says "Key management is hard. We need tools, libraries, apps and documentation to help us." I'm… still confused.

@kensanata It's designed to be like Keybase and not involve PGP grot.

@kensanata Really cool idea! Would be great to have this standardized.

@bn4t I agree! But how to go about it? Perhaps we should start with spreading the word before @wiktor can reach out to some org.

Great idea indeed!

I’m actually ironing out the specification details and if all goes well I'd want to standardize it through the OpenPGP working group. That wouldn’t change anything for end-users except for the notation name.

If it’s standardized it can be just “proof” instead of “proof@metacode.biz” that’s currently required to namespace the notation. (I'd still support the old notation for backwards compatibility so there is nothing to worry).

@wiktor one question (noob here) about "proof@metacode.biz", is it just a name (an index) you give to your proof attached at your key or it points to some file or object in metacode.biz? BTW thank you for your work.

I'm trying to understand the whole logic of the proccess, I was not on keybase :blobcatpeek:

@kensanata @bn4t

This is just a key in the hash-table. It could be anything and it would work but RFC 4880 says that notation keys should be either without @ when they are standardized (there are currently no such notations) or in local@domain format where domain is a domain you control. So let’s say you control toot.site domain and think of your own proof system you'd use proof@toot.site or anything@toot.site because it’s the owner of toot.site that selects the local part.

And nope it doesn’t mean anything it doesn’t need to have a file or even e-mail address like that (but it’s a good practice).

I explained that in the FAQ too: https://github.com/wiktor-k/openpgp-proofs#faq

@xosem @wiktor @bn4t it’s just a name. «This e-mail-like string is actually the notation key. RFC 4880 specifies this kind of format as a way to namespace custom notations. You need to create notations under the domain that you own to avoid conflicts. I used my own domain for this protocol. Ideally the notation key would be just “proof”.»
Slightly edited, from github.com/wiktor-k/openpgp-pr

Sign in to participate in the conversation
Octodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!