Time and again there appear suggestions for using that LOTW certificate for other things then LOTW. I don't know if you are aware, but not everyone is an ARRL member or uses LOTW. So, as long as things like APRS have absolutely nothing to do with ARRL, please keep them apart.
Marius, YO2LOJ
On Thu, Apr 17, 2014 at 9:22 AM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ Time and again there appear suggestions for using that LOTW certificate for other things then LOTW. I don't know if you are aware, but not everyone is an ARRL member or uses LOTW. So, as long as things like APRS have absolutely nothing to do with ARRL, please keep them apart.
Marius, YO2LOJ
If you are volunteering to verify callsigns, free, just as the ARRL does, then I will have no problem adding your Certificate Authority to my configuration. This scheme is very much capable of using multiple authorities for authentication. The ARRL just happens to be the one who already has a large, trusted install base and has agreed to let us use their service in this manner.
I assume that since all you mentioned in your reply was disdain for ARRL, that is the only piece of this scheme you don't like?
Tom KD7LXL
On Thu, Apr 17, 2014 at 9:30 AM, Tom Hayward esarfl@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Thu, Apr 17, 2014 at 9:22 AM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ Time and again there appear suggestions for using that LOTW certificate
for other things then LOTW.
I don't know if you are aware, but not everyone is an ARRL member or
uses LOTW.
So, as long as things like APRS have absolutely nothing to do with ARRL,
please keep them apart.
I assume that since all you mentioned in your reply was disdain for ARRL, that is the only piece of this scheme you don't like?
One problem that comes to mind is SSL wouldn't be allowed on 44net unless everyone has the private key and I doubt ARRL will release that.
In his application, I don't see a problem with source address authentication or pseudo passwords. Honestly, I wouldn't even bother with authentication. If someone is going to use it for nefarious purposes then they're already committed to impersonating me and my callsign. After all, there's nothing physically stopping me from impersonating you on the air...
On Apr 17, 2014, at 12:38 PM, Don Fanning don@00100100.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Thu, Apr 17, 2014 at 9:30 AM, Tom Hayward esarfl@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Thu, Apr 17, 2014 at 9:22 AM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ Time and again there appear suggestions for using that LOTW certificate
for other things then LOTW.
I don't know if you are aware, but not everyone is an ARRL member or
uses LOTW.
So, as long as things like APRS have absolutely nothing to do with ARRL,
please keep them apart.
I assume that since all you mentioned in your reply was disdain for ARRL, that is the only piece of this scheme you don't like?
One problem that comes to mind is SSL wouldn't be allowed on 44net unless everyone has the private key and I doubt ARRL will release that.
Why would you need the private key to the ARRL CA root certs?
73, -jav k4jh
On Thu, Apr 17, 2014 at 10:06 AM, Javier Henderson (javier) < javier@cisco.com> wrote:
One problem that comes to mind is SSL wouldn't be allowed on 44net unless everyone has the private key and I doubt ARRL will release that.
Why would you need the private key to the ARRL CA root certs?
How do I know the packet you are sending me is really a LOTW public certificate? You could be sending secrets against J. Edgar Hoover!
No, I do know the signature packet itself is just data or a hash of public data. Problem is that it is - in essence - encrypted data in which you only share part of it. The just because it could be argued that it skirts the legality of the law does it mean that it is clear of the meaning of the law.
On 2014-04-17 10:50, Don Fanning wrote:
How do I know the packet you are sending me is really a LOTW public certificate? You could be sending secrets against J. Edgar Hoover!
I assume this works the same as SSL certificates for web sites:
1. You generate your own public/private key pair. 2. You send the *public* key to a certification authority (in my case StartSSL.com for web certificates).. 3. The certification authority signs it with their *private* key and sends it back to you as a *public* certificate, which you then provide to anyone who requests it for your authentication. 4. Another user who wishes to verify your authentication, obtains from you (eg, via the browser) your *public*, signed certificate. 5. The browser has pre-installed the *public* certificate of several certification authorities, and of course, you can also install the public certificate of any other certification authority that you choose to trust. Eg, CAcert.org signs keys of requestors, but since it is not approved by the major browsers, users who wish to authenticate those who have a CAcert-signed certificate, have to install the CAcert.org public certificate (if they trust it to properly validate their users). 6. The browser uses the public certificate of the certification authority to verify that the certificate your web site provided as part of the handshake, is "valid". In particular, the browser verifies the host/domain name of the web site with the host/domain name installed in your public certificate. Your private key is also used as part of the handshake, to verify that your public certificate is not being used by another site masquerading as you.
So, with regard to the LOTW certificates: All that is needed to verify a user is his/her LOTW public certificate, plus the ARRL public certificate (while you can obtain on your own). A little bit of handshaking is needed like the browser does, but that's it.
If this does not work, I think we need to tell Bruce Schneier ASAP ...
On Apr 17, 2014, at 1:50 PM, Don Fanning don@00100100.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Thu, Apr 17, 2014 at 10:06 AM, Javier Henderson (javier) < javier@cisco.com> wrote:
One problem that comes to mind is SSL wouldn't be allowed on 44net unless everyone has the private key and I doubt ARRL will release that.
Why would you need the private key to the ARRL CA root certs?
How do I know the packet you are sending me is really a LOTW public certificate? You could be sending secrets against J. Edgar Hoover!
You’d validate it the same way you’d validate the amazon.com SSL certificate.
No, I do know the signature packet itself is just data or a hash of public data. Problem is that it is - in essence - encrypted data in which you only share part of it. The just because it could be argued that it skirts the legality of the law does it mean that it is clear of the meaning of the law.
I’m not sure I’m following you here...
73, -jav k4jh
On Thu, 17 Apr 2014, Don Fanning wrote:
One problem that comes to mind is SSL wouldn't be allowed on 44net unless everyone has the private key and I doubt ARRL will release that.
Humm, why?
The private keys of the ARRL CA are only needed by ARRL to sign the certificates they give to the users. And they don't need to give those away (actually, they must not give those away) - that would allow others to impersonate ARRL and sign certificates on their behalf.
What everyone needs is their CA's certificate, which is public by definition. That can then be used to verify certificates of individual users - to confirm that those individual users have a good amateur radio certificate given by a CA such as ARRL, and that CA has looked at the license papers of that individual before giving him a certificate.
By the way, have to mention this again: SSL/TLS can run in a mode where data is not encrypted (NULL cipher), it's just authenticated. You'll know it came from me and nobody modified it on the way, but it's not encrypted.
- Hessu
On Thu, Apr 17, 2014 at 10:47 AM, Heikki Hannikainen hessu@hes.iki.fiwrote:
(Please trim inclusions from previous messages) _______________________________________________ On Thu, 17 Apr 2014, Don Fanning wrote:
One problem that comes to mind is SSL wouldn't be allowed on 44net unless
everyone has the private key and I doubt ARRL will release that.
Humm, why?
The private keys of the ARRL CA are only needed by ARRL to sign the certificates they give to the users. And they don't need to give those away (actually, they must not give those away) - that would allow others to impersonate ARRL and sign certificates on their behalf.
What everyone needs is their CA's certificate, which is public by definition. That can then be used to verify certificates of individual users - to confirm that those individual users have a good amateur radio certificate given by a CA such as ARRL, and that CA has looked at the license papers of that individual before giving him a certificate.
By the way, have to mention this again: SSL/TLS can run in a mode where data is not encrypted (NULL cipher), it's just authenticated. You'll know it came from me and nobody modified it on the way, but it's not encrypted.
- Hessu
So again, explain to me why this should be used on an authentication system that can be defeated with a pen and paper? If APRS-IS was meant to be authenticated, then they should have went public-key/certificate based long ago.
If you are volunteering to verify callsigns, free, just as the ARRL does, then I will have no problem adding your Certificate Authority to my configuration. This scheme is very much capable of using multiple authorities for authentication. The ARRL just happens to be the one who already has a large, trusted install base and has agreed to let us use their service in this manner.
Anybody who can install this:
https://packages.debian.org/search?searchon=contents&keywords=aprspass&a...
or something similar.
can generate passcodes for any valid or invalid callsign...
There is no security in the APRS passcode, the passcode is derivated from the callsign itself by a static algorithm.
The algorithm itself was kept somewhat in the dark, but it is no secret.
APRS passcodes must be considered public knowledge.
73 de Marc
What I dislike is the fact that you try to bind an international network like APRS to a national authority. No matter if it is called ARRL or FRR (that's the YO counterpart) or whatever.
If the APRS netwok needs to have strong authentication, then let the core network solve this. Or let every tier2 do it as they whish.
But don't mix apples with oranges.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Tom Hayward Sent: Thursday, April 17, 2014 19:31 To: AMPRNet working group Subject: Re: [44net] Test New Tool - APRS Code Recovery
...
I assume that since all you mentioned in your reply was disdain for ARRL, that is the only piece of this scheme you don't like?
Tom KD7LXL _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Apr 17, 2014, at 12:22 PM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ Time and again there appear suggestions for using that LOTW certificate for other things then LOTW. I don't know if you are aware, but not everyone is an ARRL member or uses LOTW. So, as long as things like APRS have absolutely nothing to do with ARRL, please keep them apart.
Marius,
You don’t have to be a member of ARRL to use LOTW. Also, ARRL is just one possible CA, which already does due diligence before issuing a certificate.
We could use other CAs in addition to ARRL.
73, -jav k4jh
That's right, I do have LoTW certificate NOT being member of ARRL.
Best regards. Tom - sp2lob
-
Dean Gibson AE7Q -
Don Fanning -
Heikki Hannikainen -
Javier Henderson (javier) -
Marc, LX1DUC -
Marius Petrescu -
sp2lob＠tlen -
Tom Hayward