First off, why would one want to do this? Well, cryptographic security is useful in communications medium other than email, and sometimes one may not have an email address for the person one is contacting. Also, a public key got from someone’s profile page is more likely to be their current key than the one got off a keyserver. Finally, if the discovery is done over TLS (or upcoming XRD signing techinques) then one can use the PKI to verify that the public key is, at very least, the one the owner of the URL claims. Which, for pseudonymous communications, may often be enough.

I will here propose three different ways to make this discovery work. Consumers must try all three. Publishers may publish more than one.

Content Negotiation

A public key represents a person. If a URL represents a person (such as on a profile page), then were that page’s data to be represented in the OpenPGP key format, one would get the user’s OpenPGP public key.

Send the header Accept: application/pgp-keys along with an HTTP GET request. If the Content-Type on the response is application/pgp-keys then the body is the user’s OpenPGP public key.

Links

If a GET or HEAD request is performed on the URL and in the headers is a Link header with rel=me and type=application/pgp-keys, then the URL of that link is the user’s OpenPGP public key.

If the Content-Type header of the GET request is text/html or application/xhtml+xml, then look in the page for <a> and <link> tags with rel=me and type=application/pgp-keys. If there is such a tag, then its href attribute is the URL to the user’s OpenPGP key.

LRDD+XRD

If LRDD discovery is performed on an endpoint, leading to the discovery of an XRD document containing a section like the following:

<Link>
<Rel>http://www.iana.org/assignments/relation/me;
<MediaType>application/pgp-keys</MediaType>
<URI>...</URI>
</Link>


Then the URI is the URI of the user’s OpenPGP key.

Security Considerations

The URLs used in all methods above should be either HTTPS URIs secured using TLS and a certificate issued by a CA known to the client, or data URIs.

Application to Other Crytography Schemes

Everything in this document applies equally well to public keys for any cryptography scheme, as long as the MIME types are changed appropriately.

So, one of the things I decided to do with the transition to my new PGP key was add a small JPEG photo (my common avatar, which is indeed a photo of me) as a UID. This is something OpenPGP keys have supported for some time, it doesn’t add too much to the keysize (as long as you keep the photo small, which I did), it helps people to identify me, and ties the key more firmly to my IRL identity.

I then discovered a problem: some old keyservers, like pgp.mit.edu, *will not* accept keys with photo UIDs. It’s not that they ignore the photo, it’s that they simply refuse the key!

So, with the help of Daniel Kahn Gillmor, I have discovered the strategy for uploading these keys to the old keyservers using the CLI interface to GnuPG (which is what I normally use for my OpenPGP stuff).

cd /tmp/
mkdir -m 0700 testring
gpg --export KEYID | GNUPGHOME=/tmp/testring gpg --import
GNUPGHOME=/tmp/testring gpg --edit-key KEYID

# Select the photo UID by typing it’s number

deluid
save
GNUPGHOME=/tmp/testring gpg --keyserver pgp.mit.edu --send KEYID
rm -rf /tmp/testring

The Luddite Rebellion is coming. It may not come literally, and we may yet stop it, but we will not stop it by sitting idly by.

What is the Luddite Rebellion? Well, a Luddite is someone who stands opposed to technology and freedom, not because they are against them per se, but because they are afraid. They may have good reason to be afraid: malware, spam, privacy invasions, stalking, and all manner of danger can come from allowing technology to be used freely.

Hackers are on the other side of this struggle. Hackers stand for tinkering that leads to innovation. This tinkering and innovation cannot happen without free access to technology. Not all hackers agree on what "free" means, but the restrictions the Luddites would like to see are certainly the opposite of freedom. Hackers tend to form communities, and staying connected to one or more hacker communities may just be key to surviving the Luddite Rebellion.

What will an unfulfilled Luddite Rebellion look like? It will look like the end of net neutrality. It will look like the limitation of general purpose computing platforms. It will look like widespread computing with no hackability. It will look like education that teaches security through ignorance and through a lack of access to powerful tools.

What would a fulfilled Luddite Rebellion look like? Well, first it would look like an unfulfilled one. Then it would move to a purposeful oppression of hackers and technologists in general. A general anti-technology sentiment ultimately culminating in a forceful out-putting of technologists and technology of all kinds, possibly violent.

I don’t know if the Luddite Rebellion will ever be completely fulfilled, but the roots are starting now. The balance of this article will talk about ways hackers, sympathizers, and our society can survive.

Keep an Active Passport

This may seem to be the most obvious. I do this anyway, just as a general good practise. Never let your passport expire, or you may find yourself stuck where you’re at.

Libre Software

Sometimes also called "free software", this body of work by the BSD projects, GNU projects, and others is dedicated to hackable software. Software that is published in hackable form. No matter what happens regarding lock-downs in the Luddite Rebellion, this hackable form (usually the "source code") will be taken by hackers and preserved, it will not be locked down. Even non-hackers will be able to get access to the freedom-supporting versions of this software. If you run libre software now, you are contributing to this body of work and preparing yourself for a future where it may be the only software that respects your rights.

Archive

Backup your data! Not just your offline data, but your online data as well. You never know when access to it may be taken away. Store it in simple, hackable formats. No matter how "open" a format may be, it’s ability to survive the Luddite Rebellion really relies on it being simple and hackable. Open Office documents may be very "open", but they are much less hackable than (X)HTML, plain text or WikiText, (La)TeX, or RTF.

Backup your communications especially! Email, IM logs, Microblogging content, bookmarks, and other forms of online communication can all be backed up to simple, text-based formats.

Backup other people’s data as well. Data that you may find useful in the future, especially to survive the Luddite Rebellion. All that educational and reference material you can "just link to and find later"? Download it to your personal archive.

Keep your archive in more than one place. If you only have it on your laptop, and you lose that laptop, what good is it to you?

Personal Brand

Keep a strong personal brand. This brand may be anonymous (hard to tie to the "meatspace" you) or real. Being easy to get in touch with is crucial in surviving the communication crackdowns that the Luddite Rebellion may bring.

Thing may enter your person brand on purpose, or by accident. The trick is recognising them and keeping them there.

My brand:

• Stephen Paul Weber (all three names)
• singpolyma (my very unique handle, keeps me easy to find across communication platforms)
• The colour orange (my website, my shoes, my coat, several of my shirts)
• My avatar: http://www.gravatar.com/avatar/3ab4d3a66e470ce10eb7ec812fab3c46
• My PGP key /public.asc (more on below)

PGP

PGP is a technology that allows people to communicate securely, and to be sure of who they are communicating with.

• Have a PGP key (if you need help getting set up, give me a shout).
• Make sure your PGP key is well published (I have mine on key servers, a link from the mail page of my site, and a link in the headers of every email I send).
• Sign all emails (so people know it’s you, and get used to verifying).
• Memorize and publicize your key id and/or fingerprint as well. There are different mnemonic programs out there to help. My key id is: nerve perfume pogo (or 913D04EB).
• Understand the PGP Web of Trust and build yourself a trust network.

Wrap-up

These are just a few key ways that hackers, technologists, sympathizers and others can prepare themselves to survive, and maybe prevent the complete fulfilment of, the Luddite Rebellion.

Registered Commons page for this article.

Lets face it: currently, PGP is hard.  Most geeks even consider it “geeks only”.  While few average users can benefit from encryption (few people say things that secret) – everyone can benefit from signed authenticity (at very least to cut down on spoofing).  The biggest obstacles to end users are (a) they don’t see the point (b) they freak out when they see “weird” inline content or attachments (c) verifying long hexadecimal signatures is hard.  I will make suggestions about these is order.

The fact that users don’t see the point really is the biggest problem.  If more users cared about authenticity, more would be willing to endure the pain of doing things “right”.  My hope here is that if seamless enough solutions become common enough, some people will use it because it is “right there” and as more people they know are sending signed messages perhaps some network effect can be leveraged.

Weird content is on it’s way to being fixed.  If everyone installs FireGPG and uses a mail client (/webmail supported by FireGPG) that supports PGP (a growing number) then at the very least, the noise gets hidden behind a “this message is signed” notice.

Few people want to read off long hex number to each other in person.  Here’s where it gets touchy, because anything we change here changes the security of the transaction.  I’m ok with that.  I’d rather my non-geek friends have a somewhat-trusted key than an untrusted key or no key at all.  My geek friends and I will still verify each others’ fingerprints.

Alice receives an email from Bob, with whom she has never previously shared cryptographic information.  Neither Alice nor Bob is a geek, tech savvy, or familiar with cryptography.  Alice knows her email program has a new feature that lets people verify each others’ messages and decides to try it out.

Alice has never shared her key with anyone before (she doesn’t have one).  She is told this and asked to wait while “some setup occurs”.  The key is generated and UI moves to the next step.  Somewhere in here there should be a notice to backup the key, “since if you lose it you can no longer send verified messages”. Public keys should be sent to a public key server automatically.

Alice now picks a secure question and answer to prove to Bob (within a reasonable, but not cryptographically rigorous) measure of certainty.  An email is sent to Bob’s address with the output of `gpg -a –openpgp –export KEYID | gpg -ac –openpgp -` attached.  Also attached, it sends an unencrypted export of the public key, for use (moot in this case, on a new key) if this key has been signed by others Bob knows.  That is, Alice’s public key is symmetrically encrypted with an algoritm allowed by the OpenPGP standard (currently 3DES) with the passphrase as the answer to the secure question.  I’ve marked it case sensitive, but all UIs COULD downcase passphrases to simplify this.  The secure question becomes the body of the email and the subject can be something like “Alice is sharing her verification key with you!”

Bob recieves the email, an his client flags it (with an icon or similar) as containing verification information.  Some clients may find it makes more sense to process the message immidiately upon receipt, instead of just flagging it.

Bob opens (or his client auto-opens) the message.  Instead of being presented with an email full of gook, he is presented with a window by his client.

Bob enters the answer and is presented with a window describing the key.  This window should say “Alice is claiming…” or similar and display the image in the key (if there is one) and all UIDs/comments.  There should then be a list of how well Bob knows this key:

It claims to be alice@example.com and was sent from there: very low

It was found to be the same as one available on public key servers: very low

It was verified using a secret question: medium

It has not been verified by anyone you know [aka, key signatures, high]

[Button: Advanced Verification, showing the key fingerprint – for advanced users]

[Button: trust this key]

[Button: I have talked to Alice and know this is her key (ultimate trust, signs key)]

If three or more signatures from people Bob trusts are on the key (remember, the unencrypted one) the client may skip to this step and provide a “verify using secret question” button.

Opening this message in the future should sync with keyservers, and then show the last dialog again, showing any new signatures from people Bob trusts, and allowing him to verify/sign it.