Support PGP verification?

[abliss]

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]

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]

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/?

[abliss]

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]

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]

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 is significantly overloading the mention syntax in a way that makes it harder to parse.

[mdom]

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]

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]

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]

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]

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.