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.
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.
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.
Create class/libraries for different transport protocols
Create sample client programs that uses TrustedQSL library