response 1 of 28:

Jan 14 15:33 UTC 2000

        As I read up on SSL, (see OpenSSL, btw), I get the impression -
        which the true techs can verify or not, that:

        1) SSL is inert unless both sides *agree* to use it;
        2) SSL remains inert unless you have a paid-up "certificate"
            for the server;
        3) SSL servers are also obligated to pay a license-fee to the
            folks at RSA;
        4) The above certificate is federally filed, ergo "security" is
            mostly against snoopers of the "haxor" and "hacqueer" flavors.

        I 'spect marcus, ken, jazz, janc and the lot can add more.

response 3 of 28:

Jan 15 05:30 UTC 2000

        oh, wow.. you can issue yer own certs?? fookin'-A..!

        Details as to how to do THAT (or where to find such) would be 
        marvy, man..

        The idea of a "central repository" for certs makes sense when
        surfing or doing "plastic-transactions" on ther web, but..
        Sheesh.. If you are simply concerned about point A-to-B security,
        that's great..!

        What about the payment to RSA?

response 5 of 28:

Jan 15 05:47 UTC 2000

I don't understand the details being discussed here, but I would like
to ask if they could apply to a problem I have been having in upgrading
Netscape 4.6.1 to Netscape 4.7, as described in the Internet cf, Item 88,
Resps 29ff. Another new factor is that when I last logged into my
on-line bank, I got a dialog that said my certificate had expired, and
that it was not their (the bank's) fault, but I should get an upgrade
for my browser. I could still use my online banking, but that dialog
just shows up every time. 

response 7 of 28:

Jan 15 06:11 UTC 2000

SSL does not, in my experience, apply to 'email, telnet, etc'; it 
applies *only* to the web.  SSH (Secure Shell) and Kerberised Telnet
offer the same advantages, but the (I don't think) they use SSL.

Rane, these certificates are set to expire every five years or so, to
encourage us all to keep up with the latest in encryption technology.
(Like a second-best army, old encryption software is a waste of money.)
The encryption works because both the browser and the server have
certificates.  The certificates built into earlier versions of
Netscape Navigator have now expired.  (Coincidentally, they expired on
or about December 31.)

Yes, you need to get a new (and it may as well be the most recent) version 
of your browser.  If you are going to do that, work hard to get the
'domestic' version; it uses longer (and therefore stronger) keys than
the export version.  (I find it works best to get them onto my office
machines and then transfer them to my home machines:  Netscape doesn't
like to admit that my dial-up connections are in the US.)

response 9 of 28:

Jan 15 10:53 UTC 2000

SSL certificates can be used with S/MIME for signed and encrypted e-mail.

response 11 of 28:

Jan 16 01:34 UTC 2000

Except that generating a key pair must take a God-awful amount of time (this
is that prime number pair thingie, isn't it?) it should be possible to
generate key pairs on the fly, a new pair for each session, without either
party ever knowing any key. Just send to each other the public keys, store
the private ones somewhere in memory, and start over again each new connection
- for a brand new key pair. Tiny statistical universes, all different and
random.

response 13 of 28:

Jan 17 10:32 UTC 2000

Certificates aren't necessary - basic public key crptography wasn't designed
with them in mind, and a PKI is basically just a buzzword.  Very difficult
to manage, and often not needed (or used!).

response 15 of 28:

Jan 18 08:51 UTC 2000

Trust is an extremely difficult commodity, with or without certs.

response 17 of 28:

Jan 18 18:29 UTC 2000

Re #5: after decoding a particularly cryptic sign-in/register dialogue
on the Netscape site, I re-registered and got a new password to the
Netscape site. This also made the certificate message from my on-line
bank go away. I'm not sure I like Netscape fooling with my computer
that way...

Along the way, one is offered an option to elect some commercial
security process for $15/year. Called "Veri-True", or something like that?
What is that, and how does it fit into the scheme of things?

response 19 of 28:

Jan 18 21:57 UTC 2000

But I did not sign up with VeriSign. Does that mean I'm not who I am?
(Or, who am I then?)

response 21 of 28:

Jan 19 03:39 UTC 2000

re 19:
        I think you're missing some fundamental logic there.  If a then b does
not mean if b then a.  In other words, "if you have a Verisign key, you are
who you say you are," does not mean, "if you do not have a Verisign key, you
are not who you say you are."

response 23 of 28:

Jan 19 09:32 UTC 2000

The usual importance of verisign etc., is not to determine who you are
(although admittedly this would be useful), but rather to determine if
the *vendor* you're sending your credit card number to is in fact who
*they* say they are.  The reason to update the certificates in your
browser is to get the most recent top level certificates from the CA's;
this is basically the list of "people" you trust to vouch for other
"people" (well, in this case, vendors.) This is actually a more
significant step than it sounds, because it's really the one place where
the trust model breaks down.  (How do you know if you aren't downloading
bogus top level certificates?)

None of the uses of the word "trust" in #20 have much to do with the
formal definition of "trust" used by cryptographers.  In the usual
formal security model favoured by cryptographers, Alice and Bob want to
exchange data; they may be able to trust their friend, Trent, to help
them do this, but they have to somehow dodge the efforts of the evil
Mallet, who can intercept and read all their packets, and can change,
delete, or even introduce new forged packets at will.  The kinds of
questions cryptographers are interested are things like, how can Alice
know she's talking to Bob (or Trent), and not Mallet? Can Mallet fool
Alice or Bob into giving him enough information to read (decode) all the
traffic between Alice & Bob?  &Etc.  It is in fact possible to get
privacy without authentication (diffie-hellman), and authentication
without privacy (digital signatures), and authentication need not be
mutual but only work in one way (Alice may know she's talking to Bob,
but Alice may be just another pretty face to Bob.) Trust, to a
cryptographer, might refer either to a previously exchanged shared
secret, the trust that is placed in Trent, or might refer to some form
of authentication (I know this data came from Bob and not from anyone
else).  None of these notions of trust necessarily has to do anything
with the ordinary english meanings of the word; Bob is not necessarily a
bank, and it might not be safe to trust Bob with a loaded shotgun, or a
glass of vodka and an expensive sports car, or even your wallet.  In
some cases, Bob might even be a computer program and not a real human
being at all, in which case Bob might have about the intelligence of a
smart cockroach and not really understand concepts like "Vodka" or
"Trust" the latter of which, after all, is pretty abstract.