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
request<https://code.google.com/p/chromium/issues/detail?id=58831#c22>…
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
document<https://www.hamwan.org/t/tiki-index.php?page=SSL+without+Encryp…
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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net