HQSL is an open standard, free for any amateur radio organization or individual to use. Anyone can sign QSL cards and produce cards fitting the standard. The important part is certifying which keys belong to whom, which requires some manner of trusted authority, and the infrastructure required to verify this information. Joining this infrastructure has been deliberately made as easy as possible.
Running your own key server
The HQSL standard specifies the use of OpenPGP public key servers. Mainstream OpenPGP key server networks are moving towards requiring user identifiers to be email addresses, and requiring verification of such email addresses, because they’re meant to be used for encrypting email first and foremost.
Unlike in regular OpenPGP networks, in HQSL, user identifiers are, deliberately, not email addresses, to make the system resilient against legislation requiring services to delete personal data. They do not contain personal data by design. As a result, HQSL needs its own network of key servers. HQSL.net is itself such a key server.
To join the key server network with your own server, you only need readily available open source software:
- Install Hockeypuck.
- Download the dump of HQSL key database to start it off – the process is described in Hockeypuck documentation The database dump is updated daily and is needed mostly to reduce the system load when initially populating your new key server.
- Add hqsl.net as a peer server in Hockeypuck configuration:
[hockeypuck.conflux.recon.partner.peer1]
httpAddr="hqsl.net:11371"
reconAddr="hqsl.net:11370"
Once you have done this, your key server will automatically synchronize with HQSL.net and share public keys with it for as long as it stays up. Even if HQSL.net ever goes down, it will still be possible to verify HQSL cards if you set up a verifier to point to your own server instead.
The procedure for any other key server software compatible with the HKP key lookup protocol and SKS key server exchange protocol is similar. However, be aware, that not all of the currently available HKP key servers can properly handle non-email-based user identifiers – some of them require email verification when uploading public keys, or don’t support SKS key exchange protocol. This is specifically the case with Hagrid and Mailvelope.
Running a card verifier
HQSL card verifier web application is open source, fully configurable, and easy to deploy on any conceivable web hosting. Refer to the published source code for documentation, but all you really need to do is to upload several files into a directory and make sure that you issue HQSL card URLs pointing to it. If you use the same key server network, all card verifiers are completely equivalent, even if each of them uses its own key server.
Becoming a key certifier
In the case of Hamlog.Online, key certification is fully integrated in the QSL database that Hamlog.Online already maintains, and you’re largely on your own when implementing the actual certification procedure. Since Hamlog.Online already used WWPass, we could establish a system to securely store private keys for our users without us taking possession of them at any point, and without making the users store (and potentially misplace) the keys themselves. Signing and key generation are performed entirely in the user’s browser. If you plan to establish your own key certification service, deciding who stores the private keys and how is the first thing you should do, and your solution may well be entirely different.
From there on, here’s what is happening behind the scenes:
- Hamlog.Online uses an isolated key certifier server, only accessible from Hamlog.Online itself, which keeps the certification key on a Nitrokey secure key storage device. A backup of the key is kept offline on paper as a precaution.
- This server responds to commands from Hamlog.Online to fetch the key from HQSL.net, add certification metadata to individual keys, and upload them back into the network. These commands are issued whenever the status of a callsign in the database changes.
It is quite possible to perform these steps manually using nothing but a copy of Kleopatra, and it may even make sense to do so if you’re acting as a QSL manager for a group of DX, who are unwilling to use a big QSL database service. Getting other people to trust your certification of other people’s keys is a matter of reputation in the amateur radio community.
The standard was designed with multiple compatible, independent certification centers in mind, and if you wish for the HQSL.net verifying application to also trust your key, it is possible – contact us at admin@hqsl.net to see if you can convince us to trust your certification.