|
| |
| Figure 1: Example QR-Encoded PGP Fingerprint | Figure 2: Example QR-Encoded Vcard | |
Copyright © 2014 jsd
Let’s start by taking about QR codes, with an eye toward putting them on business cards and/or on web pages.
The typical practice is to prepare a vcard (.vcf) file, format it as a QR code, and print it on a business card. See section 2 for details about business cards per se.
Although there is a standard for incorporating PGP keys within a .vcf file, it is a complete loser in the context of QR codes, as far as I can tell, because it only supports two possibilities:
Option (a) fails because it is not secure. It reduces to the problem previously not solved, i.e. guaranteeing that the link to the web site is not being tampered with.
Option (b) is fine in theory if you are exchanging vcards by email or bluetooth or something like that, but it fails for QR codes because of size limitations. QR cannot represent that many bits ... and even if it could, the resulting code would not fit on a business card. On the other hand, in practice, I don’t know of any Linux apps that know what to do with this part of a .vcf file. I suppose you could write something.
It would be nice if .vcf supported PGP fingerprints, as opposed to entire keys or mere URLs, but there is no sign that it does.
All is not lost, however. The trick is to have two QR codes on the card.
openpgp4fpr:1042db2aa89446151a604a36f3bd4858217335ed
The combination of vcard QR code plus fingerprint QR code fits nicely on a business card.
Once you have the fingerprint, you can safely download the entire key from the usual keyservers.
The android app APG knows how to scan a QR code and make sense of the openpgp4fpr keyword. It appears to actually check the fingerprint (rather than putting blind faith in the 32-bit key ID). Conversely APG knows how to export a fingerprint by displaying a QR code on the screen, so that some other device can scan it. This export feature does not appear on the menu near the import feature where you might expect it; instead you have to select a key and then click on the android “share” icon (figure 3) near the upper-right corner.
There are other android apps on the market that I have not checked. I am not endorsing any particular product, just mentioning that such things exist. I have not seen an app that is smart enough to put two QR codes on the screen (fingerprint and vcard, as discussed above).
Even in the absence of an app that understands the details, you can use Linux command-line tools to create the appropriate QR codes and combine them into a single png image, download the image to your phone, and bookmark it. I’m not recommending this, but it serves as an existence proof, demonstrating that you need not be more than a few clicks away from being able to export your contact information.
From the linux command line you can encode to QR using qrencode and decode using zbarimg.
Make sure QR codes are not too near each other, expecially if you are making a 2D grid. Otherwise people will have a hard time aiming at the right one.
Sometimes people have a QR code on the front of the card. Others like to have a conventional non-nerdy look on the front, and have the QR codes on the back.
The problem with having cards printed by a real print shop is that they insist on a really long production run. This is no good if you have information that is likely to change.
Note that some people go to the extreme of handing out business cards all different. Among other things, this gives you a way of figuring out who gave your address to spammers.
One problem with making cards at home is that ink-jet inks are terrible. They fade over time. Also they run like crazy if they get the least bit wet. Also the blank card-stock is surprisingly expensive.
One interesting option is to use a photo-print service such as they offer at some big retail stores. Costco charges 13 cents for a 4 inch by 6 inch photo, even in small quantities. A business card is 2 by 3.5, so you can get three cards out of such a photo, with three whacks of a paper cutter. The image quality is very high, and they dyes are fade-resistant and highly water-resistant. The stock is a little thinner than you might like, but not terrible.
As discussed in reference 1, when putting PGP keys on the web, put them in their own files, with the appropriate mime types. This is preferable to pasting the key into the middle of an HTML document, using <pre>...</pre> or otherwise.
Actually I recommend taking it a step further than reference 1 and put each key on the web site twice, once as a .aexpk file (mime type application/pgp-keys) and once as a .asc file (mime type text/plain). That’s because sometimes you want to treat it as a key, and sometimes you just want to look at it. You don’t need to duplicate the data; a symlink suffices.
Examples of this can be found on my home page.
Also I would go further than reference 1 and give an additional, better reason why it is worth putting the type="..." attribute in each and every HTML hotlink. Relevant examples include type="application/pgp-keys" or type="text/plain". Such a directive does not have much effect when the linked target is fetched using the HTTP: protocol, but it has a significantly useful effect when the target is fetched using the FILE: protocol.
Copyright © 2014 jsd
