“A nearly impenetrable thicket of geekitude…”
Man with hat.

Hi. My name is Ian Young, and this is my web site. Look around; make yourself at home. You can find out more about me or about the site, read my blog, look at some of my photography and greetings cards, or some of the software I’ve written; whatever takes your fancy.


SKS Key Servers Gone

Posted on July 5, 2021 at 16:53

SKS key servers gone

As a counterpoint to my previous entry about key signing policies, I thought it would be amusing to juxtapose a note that, yet again, using PGP/GPG in the real world has become more difficult.

This time, it’s because one of the most popular ways of acquiring keys for other people — the sks-keyservers.net pool of key servers — has hung up its boots.

The site itself says that this was the result of “GDPR takedown requests”; this appears to mean requests to remove personal information under Article 17 of the GDPR, commonly known as the “right to be forgotten”. Of course PGP/GPG public keys usually include the owner’s name and e-mail addresses as part of the user IDs that are signed to make the web of trust work.

The way the SKS key server software works doesn’t allow removal of a user’s key: it’s designed to propagate every key known to every node. Manually removing a key from a node, even if that were possible, would be futile as it would simply arrive again from another node (or could be uploaded again by a third party).

If you’re looking for a replacement for the SKS key server pool, one option is to find a key server that is still in operation, such as “old faithful” at pgp.mit.edu which is unlikely to be swayed by requests based on the EU-centric GDPR. Some other servers are based on the more modern Hockeypuck software, although it’s not clear to me that it’s any less prone to the same issue that did away with the SKS pool. For the moment, I’m using pgp.re; we’ll see how it goes.

The other service that’s of interest here is keys.openpgp.org. This has been gaining popularity for a while as these days it’s configured as the default key server in a number of packages. It’s probably not going to run into the GDPR issue by virtue of its requirement that if you upload your key there and do nothing else, the user IDs on your key are not displayed on privacy grounds. To make your user IDs visible, you must explicitly request a management link to be sent to your e-mail address, then follow that and enable visibility for the e-mail address on that key. You can also delete the e-mail address from the key if you want.

Unfortunately, by far the majority (upwards of 90%) of the keys in my public keyring are present in keys.openpgp.org but without any user IDs. This makes them essentially useless unless you’ve previously exchanged a copy of the key directly; gpg for example refuses to even import public keys that lack a user ID:

$ gpg --recv 0xXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
gpg: key XXXXXXXXXXXXXXXX: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg:           w/o user IDs: 1

If you find yourself in this bind, the only option seems to be to somehow figure out who the owner is (which is hard given that the user ID is missing) and then get the full public key from them directly (which makes the use of a key server close to pointless) or get them to go through the management process to expose their user ID. This can be particularly tricky to explain because, of course, everything works fine for them as they have a copy of the full key in their own keyring.

New Key Signing Policy

Posted on July 5, 2021 at 16:23

A few months into the current unpleasantness, it became pretty apparent that I wasn’t going to be doing much travelling any time soon. This made my PGP/GPG Key Signing Policy 2013-11-07 (which requires in-person meetings) almost entirely unusable for new signatures.

I still have a need to cross-sign keys with colleages, however, so I have put together a revised PGP/GPG Key Signing Policy 2021-02-25.

The new policy takes advantage of PGP’s ability to specify different signature certification levels depending on the strength of proofing performed (or on other factors; the specification is not precise with respect to the meaning of each level).

A level 3 certification (the only one I have used prior to writing the new policy) is still defined to require in-person physical meeting. I have however added the possibility of using the lower level 2 certification in the case of people who are already known to me who for one reason or another I can only meet on-line. The details are in the policy.

Site Design Changes

Posted on December 28, 2020 at 12:38

I have a long list of changes to make to this site one day, when I get the time or (more plausibly) when I am looking for a distraction.

This year, I have finally addressed the first of these, and if you’re reading this on the site rather than in a feed reader you may notice that most text now appears in the sans-serif font used by your operating system’s user interface. These fonts are usually highly optimised for screen use, and the result in most cases will be an improvement in readability, particularly on smaller devices.

This change sounds simple (and in the end, it was very straightforward) but required a lot of behind-the-scenes work to get to the point where it was simple to do.

If you’re interested, read on for details.

Nanoced

Posted on February 8, 2018 at 08:29

I have completed the migration work started back in December. As a result, this site is now entirely constructed using the Nanoc static-site generator, and the Drupal content management system has been retired.

If you’re reading this through a feed reader like Feedly, please drop me a line to let me know that the new feeds are working.

Continue reading for some thoughts on the process and on the results.

REEP Key Ceremony

Posted on May 22, 2014 at 15:44

The key ceremony for the REEP service took place on 2014-05-18 after the REFEDS meeting in Dublin, Ireland.

I witnessed this ceremony and was convinced that the key attached to this post as a self-signed X.509 certificate was generated during the ceremony within the hardware security module in Sweden that will be used by the REEP service to sign metadata served by it. To certify this, I have generated a detached signature file for reep.pem using my PGP key.

To the extent that you trust me to have taken care while witnessing the ceremony, you may find that validating my signature on reep.pem gives you some comfort that metadata documents signed by the private key associated with reep.pem are, indeed, legitimate outputs of the REEP service.

As an aside about the ceremony itself, proof that a particular computational event has occurred in a particular way is almost impossible in a world of networking and virtual machines. We’ve known this for a long time: the paranoia goes back at least as far as Ken Thomson’s Reflections on Trusting Trust. We’re not quite living in The Matrix, but the evidence of ones senses doesn’t really go very far towards absolute proof. So what the other witnesses and I did during the ceremony — all we could do, really — was gain confidence by asking questions, taking photographs of the steps and trying to think of ways to validate them. For example, I was later able to verify that the pkcs11-tool command being used was indeed the one which would be installed on a system running 64-bit Ubuntu 12.04. Unless, of course, Leif foresaw that trick and subverted the md5sum command as well. It’s turtles all the way down.

UK federation Metadata Aggregation

Posted on August 12, 2012 at 21:25

One of the systems I work on is the back end of the UK federation’s metadata system. Although I’ve talked about this in several presentations, the bare structural diagram isn’t very informative on its own. Here, I present a snapshot of the architecture, and go into a lot more depth on the what, how and why than you’d get from just the slide on its own (click on the image to get a larger version).

I hope that this article can perform double duty as a case study for the Shibboleth metadata aggregator tool, which acts as the engine behind the metadata system and to which I also contribute as a developer.