Last updated 2002-03-31

Chris R. Burger ZS6EZ
chris@zs6ez.za.org

The author has a vested interest in electronic QSLing, having sent out around a quarter of a million QSL cards between 1980 and the present. Stations whose cards have contributed to this total include 3DA0Z, 3DA6Z, 5H4IR, 5H9IR, V51Z, ZS0Z, ZS3Z, ZS6BCR, ZS6EZ, ZS6TUK, ZS6Z, ZS8D, ZS8IR, ZS8MI, ZS9Z and derivatives of ZS6BCR or ZS6EZ from various portable locations. Many of these callsigns were used by DXpedition teams. He has also worked as a strategist for a team of firewall and digital communications system security developers and spent some time poring over cryptographic issues in a post-graduate university course. He is also holding thumbs for a speedy resolution to the e-QSLing debate; his only unconfirmed country, and the only confirmation keeping him off the top DXCC Honor Roll spot in Africa, is verifiable only via eQSL.cc!

The original document evolved through about a dozen iterations, during which some of the factual content changed. The original version was mainly a discussion of the issues around e-QSL.cc. As I started adding more schemes and details and the proposed format, the flow of the document became awkward. For this reason, I completely re-organised the document on 2001-03-06. Until the new version can be thoroughly proofread, please bear with any apparent discontinuities in the reasoning, and point them out to me so I can fix them. Any other comments will also be greatly appreciated.

I would love to do all my QSLing through the Internet. That way, I would not have to spend evenings at home sticking labels, licking envelopes and tearing stamp perforations. I also wouldn't have to occupy lots of shelf space with cardboard boxes. Instead, I'll have a few CDs on a bookshelf. Electronic QSLing shows great promise, and I expect that by 2003 you will be able to get DXCC credit within minutes of your QSO. The ARRL is apparently already working actively in this direction.

Several people have made early starts with electronic QSLing systems. However, none of these systems that I have encountered meet the basic requirements for a legitimate system. Many of them focus on replacing the picture postcard rather than on confirming the QSO. I'm sure we all agree that picture postcards are nice, but I'm sure we also all agree that the primary purpose of a QSL card is confirm a contact. All the systems I've seen fail dismally in this respect. However, at present (2001-03), several of these systems are moving in the right direction. Some examples are discussed in a later section.

Requirements for an electronic QSLing system

Any award sponsor with a serious intent to maintain the integrity of its awards programme must insist that electronic QSLs are in line with modern practice when it comes to providing protection against forgery. Reliance on access control systems or on graphics-based schemes does not make the grade, as graphics-based cards can be edited. It will be only weeks before doctored generic versions (the high-tech equivalent of blank QSL cards!) for all rare DX stations proliferate on the Internet.

A real electronic QSL must include a digital signature. Such a digital signature proves both the origin of the e-QSL and the fact that it has not been tampered with. The technology of public key systems is mature, and the most popular algorithm, RSA, is now in the public domain. There are even more potent technologies, such as Elliptic Curve Cryptography (ECC) that allow the use of much smaller signatures for the same effect. A digital signature is practically impossible to forge, and signed messages are now accepted as legal contracts in most countries.

Many good introductory texts on public key cryptography can be found on the Web. Perhaps a good place to start is the RSA Cryptosystems Web site. In a previous job I also wrote an introductory text, which was published by the company and can now be downloaded from my Site. You will need a PDF reader to read it. Once one has a clear understanding of the state of the art in public key systems, one cannot but agree that digital signatures are an indispensable part of any realistic e-QSLing system.

A real electronic QSL must also be in a form that is easily machine-verified, and must be small enough to allow economical storage and transmission of a large number of electronic QSLs. A purely text-based format is probably most suitable from this point of view. An electronic QSL with full QSO details and a signature can be constructed in less than 500 bytes, allowing almost 3000 QSLs to be stored on a single diskette. Multiple-QSO confirmations need little extra space; perhaps 80 bytes per QSO would be required, and a single signature could serve to authenticate any number of QSOs. In fact, to facilitate electronic QSLing, a manager might even decide to provide a single signed message containing all QSOs made by a station. This identical message can then be made available publically, allowing any of the stations listed in the "QSL" to use the same message as a QSL. The only disadvantage would be that each station would have to store all the irrelevant QSOs too, but for moderately-sized logs the penalty is not too severe. If I, for example, were to issue a common QSL card for all ZS stations I've ever worked (around 1000 QSOs), the message size would only be around 80 kB. While this file size is unnecessarily large, it is not beyond the realm of reason. I could leave such a message on my Web site, allowing any of the listed operators to download the file and prove that they really worked me, both now and for posterity. Provided that my public key is widely published in a variety of databases (rest assured that the likes of QRZ.com and Buckmaster would quickly join the party!), anyone can verify any of the QSOs within seconds.

A QSL must also be verifiable years later, and even if the original issuer has disappeared, taking his logs with him (or, of course, her logs with her). As long as the original public key certificate for the manager and the CA (see the cryptography reading material) are retained, an electronic QSL with a digital signature can be verified forever.

Technically, electronic QSLing is not rocket science. Any self-respecting e-commerce vendor can probably assemble a QSLing server in a day or two. However, for such a system to become sustainable in the long run, it must take over some of the other functions of its paper-based predecessors too.

Perhaps the single most important function of paper QSLing not replicated by on-line servers at present, is the mechanism for funding DXpeditions that QSLing now provides. Most people, when working a new country and ordering a direct card, include some form of return postage. Although some use mint stamps of the manager's country, most people include several IRCs or some US currency. In most cases, some change is left over once the manager has paid the direct return expenses. These small contributions become invaluable in funding the average DXpedition. Although there are a few DXpeditions funded by seemingly bottomless supplies of private or business money, the majority of outings are funded at least partially by QSL contributions. If these outings are to continue, there must be a mechanism for small contributions from the DXing community at large.

If paper QSLs are replaced, there would have to be a comparable electronic mechanism for contributions. Most DXers would probably not mind making a modest contribution for an electronic QSL; after all, they all want to see such activities continue, and will have saved the expense of postage, an envelope and of printing the card in the first place. They may also value the timely confirmation of contacts that would suddenly be possible. However, at present no mechanism exists to make small contributions on the Internet. The predicament is shared by many activities on the Web; they want to charge money for their services, but there is no mechanism to make it happen. In the Internet world, such payments are known as "micro-payments". Examples might include search engine results; search engine companies would love to be able to charge you a few cents for a list of muffin recipes, and you'd probably be prepared to pay, but there is no way to do it at present. Credit card transactions are way too expensive for such small amounts.

Fortunately, it's only a matter of time before such mechanisms are established. The major credit card houses (Visa, Mastercard, Amex, Europay etc.) have been working on cash cards for a decade or so, and workable systems are in place in several European countries. Many of these systems are suitable for Internet use. Some of the technologies include provisions for cross-currency transactions. Another player that might get involved is Microsoft; they are in an ideal position to supply large numbers of users with a common platform. Given their poor track record in security architecture design, though, it is a matter of some conjecture whether they can establish such a system on a reasonable time scale. Within the amateur radio context, a major organisation such as the ARRL would be in an ideal position to establish a repository of cash from subscribers that can be transferred to DXpeditioners in small amounts, allowing DXers to make modest contributions without much exertion. Such a mechanism would certainly solve one of the major shortcomings of electronic QSLing systems.

Although no single payment mechanism has yet reached ubiquity, there are some systems that probably fit the bill, and that would be suitable for a relatively closed community such as amateur radio. Examples include PayPal and eBucks. However, transaction fees are still too high to facilitate really small transactions (say less than $ 2). There is still some way to go.

Once a voluntary contribution mechanism and cryptographic QSLing protocol are in place, a QSL manager would only have to establish a QSLing server and wait. The server would issue QSLs and/or picture postcards on request, and accept donations. The donations might be in predetermined increments from which the requester can select, or the requester might type in an amount. One should hope that the requester should also have the option of making no contribution at all. Once the process is complete, the central payment authority would reimburse the QSL manager with the contributions on a regular basis. No further manual intervention would be required in an ideal world.

I'm not sure about you, but unfortunately I don't live in an ideal world. There is one issue that may (or will!) require major manual intervention. Operators make mistakes, and it is rumoured that a few rogues even try to be deceptive when it comes to claiming QSL cards from rare stations... For this reason, a small but non-zero percentage of requests cannot be honoured, and have to be returned marked "Not in Log". Clearly, the percentage varies, but good contesters maintain error rates in the order of half a percent. Bad operators can do really badly, necessitating manual intervention in maybe half of all contacts. Intervention might take the form of looking for near-matches, fixing obvious mistakes or investigating subtle differences between the logged callsign and the claimant's. A manager might notice that the claimant's callsign differs from the one in the log by only one Dit for a CW contact, and conclude that there has been a legitimate mistake. However, to automate this process without introducing substantial loopholes would not be easy. A "Not in Log" mechanism is imperative.

Finally, one would have to resolve the issue of log ownership. Some QSL managers might be reluctant to allow logs to go out of their hands. Reasons may vary; some may have to do with financial motives, where a DXpeditioner is dependent to some extent on QSLing contributions. This concern can be addressed if a suitable voluntary (or even forced, a la F6FNU!) contribution mechanism is included in the QSLing server. Another motive might revolve around accuracy concerns. In my case, I'm perfectly happy to publish the majority of my logs and have done so in the past. However, I have several logs where the operators are known to have allowed a very high level of errors into the logs. I would be extremely reluctant to allow these logs into the public eye. In such logs, every QSL request must be manually compared with the log to identify possible logging errors, and in one particularly bad log, approximately one in four requests requires some additional digging. If such a dubious log is allowed into the public eye, there is no doubt that a handful of chancers will capitalise on their knowledge of the contents and submit QSL requests that will dupe the manager into issuing a QSL, even though no QSO took place. I'm sure I'm not alone in this feeling; there must be many other operators and QSL managers who might find the concept of public logs unacceptable for various reasons. As long as such people exist, an alternative mechanism must be provided. I believe that centralised log repositories with on-line verification are at a serious disadvantage in the stakes for universal acceptance, for this reason.

Systems currently in operation

Perhaps the most widely used system right now is eQSL.cc, established by Dave Morris N5UP. This site offers a forum for exchanging electronic picture QSL cards, and is already being used by hams in around 150 countries. Dave has written a white paper on eQSLing, available from his Site. The white paper states that the security of the system vests in the fact that there is rudimentary access control to the electronic QSLs on the system, and that it is therefore impossible to forge a card. Anyone who has had even basic exposure to digital picture editing will realise that any graphics file is easily modified, and that one can forge such QSLs to heart's content. If these "confirmations" were to be accepted for DXCC, one could easily get a 10 GHz DXCC by just working 100 countries on HF, legitimately getting the eQSLs from the Site, and then spending a few evenings with a picture editor (like the one that came for free with your camera) to turn those cards into 10 GHz ATV confirmations. I guess you'd also have to alter a picture of your TVRO dish to convince people that you actually have a decent EME array, but that's simply a matter of scale...

Dave Morris N5UP, the creator of eQSL.cc, has indicated to me in personal correspondence that he had thought through the implementation of cryptographic safeguards initially, but had initially decided that such safeguards are unnecessary. Instead, he implemented a verification engine to allow awards sponsors to query the database and determine whether a specific QSL is really in the database.

While this system offers much higher security than the original, it still suffers from several shortcomings. Perhaps the most serious of these is the possible lack of continuity, as the system will only work for as long as the eQSL.cc server is active. Anyone wishing to submit an e-QSL a decade after the fact, may well find himself high and dry. Dave is in the process or appointing an advisory board to address some of these concerns.

On-line verification is also subject to bandwidth and processing delay constraints that may well be a problem to major award sponsors such as the ARRL. Public key cryptography, on the other hand, provides mechanisms to allow off-line authentication almost in real time, and makes use of key databases that are compact enough to allow widespread replication. The demise of a single server or even organisation will not dent the system's ability to verify a specific QSO several years down the line.

There are also other problems, related to the lack of authentication between communicating parties in the eQSL.cc query engine. An enterprising hacker with a strong yearning to be on the DXCC Honor Roll could easily intercept ARRL's HTTP queries to the database and modify the responses to convince ARRL that his claim is legitimate. He could also tamper with the eQSL.cc database; this approach has the advantage that it only needs to be done once, and he can affect enough logs to claim whatever DXCC credits he desires for several years to come. Such attacks would obviously be a lot harder to accomplish on a system where logs are distributed over many different servers. In a distributed system, jeopardised logs can also be quarantined a lot more easily by just revoking the public keys of the offending managers. However, these Internet security issues are probably not as important in practice as the continuity and timing constraints mentioned in the previous paragraph.

Morris has recently (2001-03) indicated that he is now planning to incorporate text-based e-QSLing formats. He has already started implementing support for N7DR's proposed format, minus the signature. He is also already developing a PGP signing capability on his servers. This signing capability is crucial to both the full implementation of N7DR's format and to the modified Cabrillo format described below. As he already has an impressive infrastructure up and running at eQSL.cc, Morris is likely to gain a significant head-start in the race to implement the first working system.

Another electronic QSLing system that is already in operation is QSObank. Unfortunately, as this system runs in Japan, you can only see this site if you have Kanji and Kana fonts installed in your browser. Although there is a comprehensive article on the subject in CQ Ham Radio 2001-02, I'm afraid my command of Japanese is not up to the task of providing a full description. However, from what I can see the system is text-based (including some Kanji and Kana), without a digital signature. If these assumptions are correct, QSObank is also not the definitive answer.

Rest assured: If a viable electronic QSLing system becomes available, I will be on board in a flash!

Existing and proposed electronic QSLing formats

N7DR's proposed format meets all the requirements for a good electronic QSL. My only criticism is that it includes a lot of overhead, is relatively difficult for a human to read and does not appear to include provisions for multiple QSOs. There is a batching mechanism, but this mechanism simply bundles together a number of signed QSLs and adds a further signature. In other words, there is no benefit in terms of overhead; each QSO still requires its own header, footer and signature, and the batch verification adds further overhead.

In short, N7DR's format does not appear to offer any major advantages over the existing Cabrillo format. As Cabrillo is already supported by the majority of software vendors and contest sponsors (whose ranks include most major award sponsors too), its use appears to be a more natural choice.

There are very real advantages to be gained in processing and extensibility by using XML or one of the related markup languages. However, such changes would serve to increase the size of an electronic QSL, and would impact negatively on the human readability of such QSLs. Until electronic QSLs and their automated handling become completely ubiquitous, a manually readable format such as Cabrillo is probably to be preferred. For this reason, I have proposed a modified Cabrillo format below.

A proposed electronic QSL format

Enough has been said about the operational and financial aspects of electronic QSLs. Let me add some meat to the technical discussion by making a first-order suggestion about a possible format.

Instead of re-inventing the wheel, I have shamelessly plagiarised the basic ideas from the Cabrillo format. Good brains (including that of N5KO) have already spent time working on a universally-acceptable format, and I don't see anything there that I find objectionable.

Nothing in the QSL is case-sensitive. Normal usage (i.e. mixed case) is recommended for plain text within the QSL. Upper case is recommended for labels and callsigns.

A suitable universal QSO template might look like this:

START-OF-QSL: version-number
Must be the first line of the electronic QSL. The current version-number is 0.0.

END-OF-BODY:
Must follow the last line of QSO data. The signature is calculated up to this point. Tampering with any character within this block (including spacing) will invalidate the QSL.

END-OF-QSL:
Must be the last line of the electronic QSL. Only the signature is found between the END-OF-BODY and END-OF-QSL.

MANAGER: callsign
The callsign of the manager issuing the confirmation.

MANAGER-KEY: keyname>
The name of the key used by the manager to sign the QSL. When expired keys are replaced, the manager can choose a new key identifier.

CREATED-BY: text
Name and version of the logging program used to create the electronic QSL file.

DATE-ISSUED: date
The date on which the QSL message was assembled, in ccyy-mm-dd format.

NAME: text
ADDRESS: text
EMAIL: text
Name, address and email address of issuing manager.

Optional fields
Optional fields, required only for specific information that might not be evident from the callsign, or ambiguous. These fields may be included or omitted for all QSLs. For multiple-station QSLs, list each parameter, associated with the relevant callsign by "/". Example: LOCATOR: ZS6EZ/KG44EE ZS3Z/JN86.

TO: text
For use when the card is addressed to an SWL or a QSL manager.
FROM-CALL: text
TO-CALL: text
For rare instances of callsigns (such as 3DA0/ZS6BCR/P/QRP) that do not fit into the specified fields. The callsign should be truncated in the relevant QSO record, and listed fully in this section of the header.
DXCC: text
ZONE: text
Specifically important for cases where the zone and DXCC entity cannot be unambiguously determined from the callsign. These fields are recommended, as callsign allocations may change. The Zone field may contain either CQ or ITU zones, or both, prefixed by the relevant type. Example: ZONE: ZS6EZ/CQ38 ZS6EZ/ITU57.
STATE: text
Two-letter ZIP code abbreviation for US states, e.g. STATE: UT. Can also be used for province or state names in other countries, if DXCC: is defined and not equal to "USA".
COUNTY: text
Primarily intended for US counties, but also useable in other countries. The name of the county must be fully written out.
LOCATOR: text
Four or six character Maidenhead locator (e.g. KG44 or KG44EE).
IOTA: text
A continent code and three digits, like IOTA: AF047.
COMMENTS: text
General comments pertaining to all QSOs in the confirmation. Examples might include personal messages to the recipient or a description of equipment and antennas used. Comments can span multiple lines, and are terminated by the first "QSO:" marker.

QSO field (one or more compulsory):

QSO: qso-data
QSO data as specified by the Cabrillo QSO data format, described below.

QSO: freq  mo date       time call       call       rst Remark
QSO: ***** ** yyyy-mm-dd nnnn ********** ********** rst ********************
QSO: 21042 CW 1997-11-29 2102 HC8N       ZS6EZ      599 CQWW DX Contest
0000000001111111111222222222233333333334444444444555555555566666666667777777
1234567890123456789012345678901234567890123456789012345678901234567890123456

The fields within QSO-data are defined as follows:

START-OF-QSL:    0.0
MANAGER:         ZS6EZ
MANAGER-KEY:     0001
CREATED-BY:      EZLog v0.0
DATE-ISSUED:     2001-01-08 
NAME:            Chris R. Burger
ADDRESS:         Box 4485, Pretoria, 0001 South Africa
EMAIL:           chris.burger@mindless.com
LOCATOR:         ZS6EZ/KG44
ZONE:            ZS6EZ/CQ38 ZS6EZ/ITU57
COMMENTS:        ZS6EZ confirming all Galapagos QSOs to date

QSO: 14000 SB 1999-03-26 0516 ZS6EZ      HC8A       59  WPX Contest
QSO: 28000 CW 2000-11-20 1234 ZS6EZ      HC8N       599 
QSO: 28000 RY 2000-09-23 0701 ZS6EZ      HC8N       599 CQ/DJ Contest
QSO: 28000 SB 2000-02-25 1652 ZS6EZ      HC8N       59
QSO: 24900 CW 2000-02-25 1652 ZS6EZ      HC8N       599 
QSO: 21000 CW 1994-11-26 1454 ZS6EZ      HC8N       599 CQWW DX Contest
QSO: 21000 RY 2000-09-24 0616 ZS6EZ      HC8N       599 CQ/DJ Contest
QSO: 18100 CW 2000-02-25 1758 ZS6EZ      HC8N       599 
QSO: 14000 CW 1995-11-25 2044 ZS6EZ      HC8N       599 CQWW DX Contest
QSO: 14000 SB 1997-10-25 0455 ZS6EZ      HC8N       59  CQWW DX Contest
QSO: 10100 CW 2000-02-28 0413 ZS6EZ      HC8N       599 
QSO:  7000 CW 1994-11-26 0337 ZS6EZ      HC8N       599 CQWW DX Contest
QSO:  7000 SB 1996-10-26 0437 ZS6EZ      HC8N       59  CQWW DX Contest
QSO:  3500 CW 1994-11-26 0339 ZS6EZ      HC8N       599 CQWW DX Contest
QSO: 24900 CW 1997-10-22 1700 ZS6EZ      VE3EJ/HC8  599 
QSO: 24900 SB 1997-10-22 1634 ZS6EZ      VE3EJ/HC8  59

END-OF-BODY:

iQCVAwUBOlmg16gRRwARJuAtAQGp2AP8DOPAk1T8wUxAxLx9f6mBBhExA2rqu09q
H6kXpk01/eVVGhVYj4yKmx9i17PbCA2l97upwa+Fjs2gBIbSJyNDsGiMhWvXr+1k
exLT51CQAESov0W5IavY8xXdo+be7Peg7+wz0LvhyzciW8SSwWsKUWNtwqzBRFsF
iQCVAwUBOlrg06gRRwARJuAtAQGhawQAhkK7u8K+Mf5hgQnzbmfq4YAVzIIxVTmP
heNS14dWbc97CPEPgZ+kucFjOIyJWrnzBYzJHo+3RF3p8FEHiZm7EGMWIwVq46Mk
kmpzTvF8fljI9IfA2NYgDttivJsXZBlcqeb8euYpFBSgfxhoKqaWj26Vjjj04Sks
vcvEraOy+lIT4MKVxiF1Fc=
=qrb07MG6

END-OF-QSL: