TL;DR: LotW is perfect for many of our use cases and I explain why/how it works. If done right, it's even possible to use it on our RF links without violating the rules. I also clear up some other misunderstandings from this thread.
The entire point of the certificate system as we know it is to establish the trust of someone's identity through a third party that you already trust, all without being online. If you already have a copy of and trust the well known ARRL root CA certificate, then that's all you need to automatically trust any other certificate that is signed by it. Because there's a chance that certificate can become invalid at some point in the future (call sign change, private key exposure, etc), ARRL mitigates the risk by limiting its validity with an expiration date of at most two years. Some other certificate authorities will also offer a service that allows clients to check the status of a certificate's revocation status in real-time, but it's optional and not supported by ARRL's CA.
The LotW certificate system was created so that contesters can have a way to sign their logbooks in a way that anyone who trusts the ARRL can verify, which prevents cheating. The ARRL has a system setup that allows any global ham to get their license verified and get a certificate for no cost. Because of this, it makes perfect sense that other internet based systems can be setup to trust ARRL to vouch for the identity of other hams when granting access to those systems.
This type of setup is not difficult to do on the internet and there are plenty of use-cases where it makes sense to do so today. However, when providing services over our RF links, we need to be careful not to "obscure the meaning of messages" as written in our rules. This rule is a good thing, as without it our valuable spectrum may have been taken over long ago by commercial interests who secretly use it for other purposes. Many people mistake this for a ban on "encryption" which is actually just a math based tool that *can* be used to obscure messages. Using encryption algorithms to sign otherwise unobscured messages does not fall under this category. A good analogy would be recognizing someone you know on the air by the sound of their voice. Their words are the content, but their voice is the signature used to trust who is sending you that content (and not a form obfuscation).
SSL is only one method of achieving this and it is possible (although difficult) to make it RF compatible. SSL typically gives us three things: Privacy (so our messages can't be heard by others), Authentication (so we know who we're talking to is legitimate) and Integrity (so we know the message hasn't been tampered with while in transit). Most people only think of privacy when thinking about SSL. However, it's easy to turn that part off on the server side so we only have the two other benefits, while leaving all the messages themselves in the clear. The difficult part is that all known web browsers have disabled this capability by default in order to protect their users from servers who may have "accidentally" enabled SSL without privacy (also known as "null cipher encryption"). It's hard for many on the internet who aren't hams to understand why this would be a valid use-case, so we need to show them whenever possible. You may want to help by "starring" this feature requesthttps://code.google.com/p/chromium/issues/detail?id=58831#c22for Google Chrome so they eventually pick it back up.
Of the browsers that claim to allow re-enabling this functionality, we've only been able to get it to work on the older Opera 12.x branch. Tom has started a good documenthttps://www.hamwan.org/t/tiki-index.php?page=SSL+without+Encryption&structure=HamWANon how to set it up so you can connect to HamWAN's self-service admin portal without encryption while logging in with your LotW certificate (passwords are bad on a link that is not private).
Sorry for the length, but hopefully this clears up some of the confusion on this topic. Let me know if you have any questions.
-Cory NQ1E Radio Hacker
On Thu, Apr 17, 2014 at 1:51 PM, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hessu,
My apologies, you are correct; though I was in fact making a reference to verifying the real-time status of the cert.
-KB3VWG _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net