New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support PGP verification? #122

Open
abliss opened this Issue Jan 16, 2017 · 11 comments

Comments

Projects
None yet
5 participants
@abliss

abliss commented Jan 16, 2017

It would be great if a user could register a PGP public key in addition to a URL. Then she could post PGP-signed messages to an HTTP endpoint and still enjoy security. The client could verify the twtxts before displaying them. Also, indexing mentions by PGP fingerprint instead of URL would allow a user to move from one backend storage to another without loss of continuity.

What do you think?

@abliss

This comment has been minimized.

abliss commented Jan 17, 2017

Here's one concrete proposal.

  1. Next to twtxt.txt, users may include a twtxt.txt.sig , containing a binary detached pgp signature (produced by gpg --detach-sig twtxt.txt)
  2. In a following url, users may include a # followed by the 40-char hexadecimal sha1 fingerprint of the public key. (Actually obtaining the public key may be left to a keyserver).
  3. After fetching such a url, the twtxt client should attempt to fetch and verify the signature: gpg --verify twtxt.txt.sig twtxt.txt
  4. If the verification matches and the key matches the fingerprint in the url, the twtxt client should display some kind of icon next to the tweet indicating that it was verified.
  5. If the verification fails or the key doesn't match the fingerprint, the twtxt client should raise a warning and not display the twt.

Example: @<abliss https://abliss.keybase.pub/twtxt.txt#7a778276dd852edc65217e759cba637a28b4426b>

This should be backwards-compatible with existing twtxt users. The registry should also gain an extra API to query users by fingerprint and coalesce their varying urls.

@adiabatic

This comment has been minimized.

adiabatic commented Jan 17, 2017

I'm not convinced of the merits of GPG-signed microblog posts, but how should a client discover the associated .sig if the URL that clients are supposed to fetch is https://www.example.com/blather/?

@buckket buckket added the enhancement label Jan 17, 2017

@abliss

This comment has been minimized.

abliss commented Jan 17, 2017

Good point, I was assuming twtxt.txt was a mandatory part of the URL. After reading the comments in #48 , I think a better proposal is to simply use an attached signature within twtxt.txt and teach clients to ignore the standard header and footer.

(Regarding merits, do you have other solutions to the two problems I mentioned, (a) secure microblogging without paying a central registrar for an SSL cert, and (b) securely moving from one hosting provider to another, especially when the old one breaks unexpectedly?)

@buckket

This comment has been minimized.

Owner

buckket commented Jan 17, 2017

I really like the idea of signing ones twtxt feed. This would indeed allow for further identification besides the URL of the file itself, so that the URL becomes exchangeable while the identity is maintained and verified.

But using the fragment identifier is not really an option. As the name suggest it should be used to point to specific twts when needed. Instead we could make use of the proposed metadata format (see #48) and include directives like GPG-KEY and GPG-SIG. The former stating the GPG fingerprint, the later pointing to a separate file with the detached signature.

@abliss

This comment has been minimized.

abliss commented Jan 17, 2017

How do you link to a specific twt with a fragment? Do you use the timestamp? That's neat.

If breaking backwards compatibility is on the table, I'd advocate making the fingerprint, or maybe just the last 8 bytes, a first-class element of the mention syntax: @<abliss https://abliss.keybase.pub/twtxt.txt cba637a28b4426b>

@Xe

This comment has been minimized.

Xe commented Jan 18, 2017

This is significantly overloading the mention syntax in a way that makes it harder to parse.

@mdom

This comment has been minimized.

Contributor

mdom commented Jan 18, 2017

I like the idea of clearsigning the file. I uploaded a signed twtxt at https://domgoergen.com/twtxt/mdom.txt.asc, so everybody can test their clients. txtnix does ignore everything unknown so it works finde with the gpg blocks.

@mdom

This comment has been minimized.

Contributor

mdom commented Jan 18, 2017

Comment by @freemor on irc:

I like the idea of GPG signing the twtxt.txt file.. as far as keymanagement goes I'd suggest leaving that to the user. could have an option (as with e-mail to auto retrieve unfamiliar keys) and just list the Sig as good but untrusted until user verifies/trusts the key.

@abliss

This comment has been minimized.

abliss commented Jan 21, 2017

Here's another reason to sign the file: I'd like to make an 'unhosted' in-browser twtxt client. Many hosting providers don't provide CORS headers, so in order to load others' twts I'll need to use a service like corsmirror.com. But then, even if a following url is https, I'm totally at the mercy of the mirror who could rewrite twts. With client-side pgp verification in js, I can keep content security even without the transport-layer security.

@mdom

This comment has been minimized.

Contributor

mdom commented Jan 22, 2017

Okay, i tried to implement that tonight for txtnix tonight but it's harder than i thought. Either i have to rework all plugins to handle a temporary twtxt file for clearsigned signatures or the publish plugins have to be able to upload multiple files for detached signatures. I don't know if it's easier to implement in twtxt, so i wait and see what happens here... :)

@mdom

This comment has been minimized.

Contributor

mdom commented Feb 20, 2017

The latest version of txtnish now supports clearsigning your twtfile and verifies the retrieved files. The user interface is probably not optimal, but i'm very interested in any ideas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment