Introduction

The goal of the TrustedQSL project is to provide an open source API and frame work to support the exchange of signed digital QSL called TrustedQSLs or tQSLs for short.  This includes the tools for implement a PKI (Public Key Infrastructure) based upon the OpenSSL crypto library.  Soon after the project started ARRL contact us about using TrustedQSL as the client/PKI library for the Logbook Of The World project.   We worked out our minor difference in the design concept and agreed to work together.  The rest is history as they say.  Now the question is where do we go from here?  I have carved up the project in what I believe is a good grouping of subprojects. 

The rest of the document will talk about the different subproject TrustedQSL project.

Trusted Gabbi (Global Amateur Interchange)  Formats

Discussion:


There are currently many different interchange formats that are being used by amateur radio today. By far the most popular is ADIF (Amateur Data Interchange Format) for good reason. It is a very elegant, robust, and easy to read as raw data. It has many of the features found in XML without the need for special libraries and their associated learning curve. Having said that ADIF does have a short coming. It doesn't have any concept of record type. Today discussions with the ADIF development group hasn't been fruitful. Therefore to meet the requires of this project the standard must be forked. The new standard will be called XADIF. It is hoped that the two standards will be merged at some point in the future. Therefore a design goal is for Gabbi (Global Amateur Interchange) format to be backward compatible with ADIF. This turns out to be fairly easy to do by declaring the QSO/Logbook record as the default record type.

Requirements:

Task:

  1. Define specification for tQSL Records
  2. Define specification for a trusted QTH/station record
  3. Define specification Trusted Delegation record (deferred)
  4. Create functions and/or class to parse, format, read and write Gabbi records.
  5. Create API usage document for #4

Public Key Infrastructure (PKI) Functions

Discussion:

The PKI functions is the heart of TrustedQSL.  It allows LoTW and others to authenticate tQSL using public key digital signature PKDS technology PKI are by there very nature complex and many of the policy issues are address by the LoTW design document.  The scope of this document is to provide the API functions required to support a PKI such as LoTW will require.  It is beyond the scope of this project to define any of the procedures or policies for the operation of a CA.

Currently most PKDS uses the RSA encryption Algorithm, however in many countries the use of strong encryption software is illegal to use, own, import and/or export.  Because of this the initial release will use the DSS (Digital Signature Standard) for created and authentication of digital signatures.  The low level design will be able to support RSA in the event that laws change such as would permit the free use of RSA. DSA (Digital Signature Algorithms) claims to be able to be used for digital signatures, therefore there is no known restrictions placed on it by any government.

PKDS are relative simple in nature requiring only basic math to compute.  What makes PKDS complex and hard to deal with is the uses of big numbers.  Most computers today are 32 bits, some are 64 bits and a few special purpose computers are 128 bits.  The smallest number used by DSA is 160 bits and goes up to 1024 bits.  Therefore it takes special routines to deal with these big numbers.  Fortunately another open source project OpenSSL has taken care of all the low level work.  There is two important things that makes the OpenSSL project appealing.  1) The licenses does plan any restrictions on product that uses any of the OpenSSL libraries, unlike the GPL license that requires the release of all source.  2) It is native C code and has been ported to every major platform/OS including Win32, Mac, Linux and Unix.  It doesn't not however support 16 bit OS such as MS-DOS.  Also there is no direct support for Java.  It is believed that Java support can be done with some of the encryption class that are available for Java.

Task: 

  1. Crypto support libraries and ports.
    The OpenSSL library is in itself a large library. Most of the functions provide by the OpenSSL crypto library will not be used by TrustedQSL. To make it as simple as possible for software vendors, the library should be reduce to a subset of functions that will be used directly or indirectly by TrustedQSL API. This is most important for Win32 platform because of the large base of users, but should also be done for Mac as well. Linux isn't a issue because OpenSSL comes fairly standard on Linux or can be compiled and installed without any trouble.
  2. Key Management
  3. Cert, CertReq and CRL Management
  4. TrustedQSL API library
  5. Programmers Guide to TrustedQSL/LoTW
  6. Cert and digital signature format

Create class/libraries for different transport protocols

  1. HTTP Upload
  2. SNAIL Mail support
  3. Create a method to send a tQSL message as an attachment
  4. Create a http client that will format and send tQSL messages

Create sample client programs that uses TrustedQSL library

  1. Format translator ADIF->Gabbi
  2. Cabrillo->Gabbi
  3. Stand alone tQSL