For some time now I've wanted to port the "--clearsign" feature of gpg to an automagic firefox plugin (and ideally other browsers, too). Not the encryption part - only the signing, as a way of proving that (for example) forum posts were made by the same person.
It was originally intended as a mildly subversive method of getting people to create pubkeys, in the hope that creating a Web Of Trust out of that later would be easier. Despite those very-long-term goals, the signing feature would have been useful on its own. The benefits of a technique like this is that it's 100% in the hands of the person making the posts, even if it doesn't solve some of the usual problems with GPG and the WoT. I think it could be made transparent enough for most people to use, too.
It was somewhat inspired by the "tripcodes" used on by some 4chan-like forums. Ideally, it would have been literal gpg message signing (for compatibility with existing tools), but would have defined a few ways of representing the signed messages, such that you could "sign" a <textarea> on during form submission, with various ways available to sign the text.
For compatibility with existing forums (that might transform "\n" to "<br>", etc, we can sign the text after stripping whitespace, newlines, and HTML tags (and doing the same when verifying), wrapped with
* straight "gpg --clearsign" headers because why not, even if its ugly with the huge "-----BEGIN PGP SIGNED..."
* some sort of VERY truncated form such as a "{@SignedBy: 0xDEADBEEF}" or even just "{@S:DEADBEEF}" or whatever replacing the usual markers, attempting to not annoy people as much.
Or, with minor server assistance that could be advertised as available in a <meta> tag (or even a special class on the <form>):
* the signature itself could be added to an <input type="hidden">, that the server transforms into something like this, with the tag itself becoming the "-----BEGIN..." headers:
This way, posts can be signed ad-hoc, with a new signing key auto-generated as needed (it's trivial to support multiple signing identities). No attempt whatsoever is made to try and VERIFY keys, at least initially. Signing keys are stored by the browser plugin when first seen, and posts checked as needed. Nothing server-side is needed, though with server support posts can be made to look exactly as they do now.
This lets you know that a post is indeed by the same person you saw previously, which has a lot of utility, even if it cannot be shown WHO that person is. It would even work between websites, with no extra work required by anybody. MitM isn't a huge issue, because it would require the person in the middle to intercept 100% of the posts or a discrepancy will be seen by the clients. Key identity doesn't matter, because it is only connecting posts as having a common author, making no claim about WHO that author is.
Extension of this to all the usual GPG features is obviously possible, but is left out not only for simplicity of implementation, but also to keep the tool simple, hopefully avoiding the "...but GPG is too complicated!" problem.
Unfortunately, actually sketching out a spec and implementing a prototype has been... slow. I'm familiar with GPG and firefox extensions only as a user, and trying to read RFC 4880 has used up far more time than expected. sigh
Really wish I had more time and energy for this, as it could solve a lot of problems, and if it caught on, extending it in the obvious ways combined with stuff like FOAF* could remove much of the need for monolithic, walled-garden "social networks". Instead, we would simply have "the internet", but with as much identify-checking as people want to provide.
It was originally intended as a mildly subversive method of getting people to create pubkeys, in the hope that creating a Web Of Trust out of that later would be easier. Despite those very-long-term goals, the signing feature would have been useful on its own. The benefits of a technique like this is that it's 100% in the hands of the person making the posts, even if it doesn't solve some of the usual problems with GPG and the WoT. I think it could be made transparent enough for most people to use, too.
It was somewhat inspired by the "tripcodes" used on by some 4chan-like forums. Ideally, it would have been literal gpg message signing (for compatibility with existing tools), but would have defined a few ways of representing the signed messages, such that you could "sign" a <textarea> on during form submission, with various ways available to sign the text.
For compatibility with existing forums (that might transform "\n" to "<br>", etc, we can sign the text after stripping whitespace, newlines, and HTML tags (and doing the same when verifying), wrapped with
* straight "gpg --clearsign" headers because why not, even if its ugly with the huge "-----BEGIN PGP SIGNED..."
* some sort of VERY truncated form such as a "{@SignedBy: 0xDEADBEEF}" or even just "{@S:DEADBEEF}" or whatever replacing the usual markers, attempting to not annoy people as much.
Or, with minor server assistance that could be advertised as available in a <meta> tag (or even a special class on the <form>):
* the signature itself could be added to an <input type="hidden">, that the server transforms into something like this, with the tag itself becoming the "-----BEGIN..." headers:
* or perhaps: This way, posts can be signed ad-hoc, with a new signing key auto-generated as needed (it's trivial to support multiple signing identities). No attempt whatsoever is made to try and VERIFY keys, at least initially. Signing keys are stored by the browser plugin when first seen, and posts checked as needed. Nothing server-side is needed, though with server support posts can be made to look exactly as they do now.This lets you know that a post is indeed by the same person you saw previously, which has a lot of utility, even if it cannot be shown WHO that person is. It would even work between websites, with no extra work required by anybody. MitM isn't a huge issue, because it would require the person in the middle to intercept 100% of the posts or a discrepancy will be seen by the clients. Key identity doesn't matter, because it is only connecting posts as having a common author, making no claim about WHO that author is.
Extension of this to all the usual GPG features is obviously possible, but is left out not only for simplicity of implementation, but also to keep the tool simple, hopefully avoiding the "...but GPG is too complicated!" problem.
Unfortunately, actually sketching out a spec and implementing a prototype has been... slow. I'm familiar with GPG and firefox extensions only as a user, and trying to read RFC 4880 has used up far more time than expected. sigh
Really wish I had more time and energy for this, as it could solve a lot of problems, and if it caught on, extending it in the obvious ways combined with stuff like FOAF* could remove much of the need for monolithic, walled-garden "social networks". Instead, we would simply have "the internet", but with as much identify-checking as people want to provide.
* FOAF: http://en.wikipedia.org/wiki/FOAF_%28ontology%29