At 12:23 AM 3/7/00 +0100, you wrote:
> > Yet, in today's world, you cannot have one without the other, which means
> > that to get EITHER you must pay someone.
>
>The pay part is untrue. If you really don't care about authenticity but
>only are interested in confidentiality of your datastream (if you cannot
>verify the authenticity of the entities on either side of your datastream I
>think you're quite vulnerable for loosing your confidentiality, but that's
>your choice) you can just generate your own certificate.
And this is what we've done - we don't need to verify that the person on
the far end of the connection really is Bob. As long as the stream is
strongly encrypted, we are safe from casual sniffing of packets. You still
need to access the protected portion of the site via a valid
username/password, and that is where the authentication may enter into play
(to strengthen the logon portion). In that case, we'd need to generate
individual certificates for each user, and truck them around wherever we
go. To much hassle for what we need, which is just basic protection from
kiddies with sniffers.
If you're running an Ecommerce site, then issuing individual certificates
is wholly impractical. In that case, all we really want is encryption. It
would be nice to have a cert signed by Verisign, but we (our corporate
entity) trust ourselves, and that is good enough for us. I'm sure
customers are more concerned with having their data encrypted moreso than
worrying whether the session is being hijacked, which I believe is quite
difficult to accomplish if the session (which is typically short) uses
strong encryption. Our customers trust us as a corporate entity, so I fail
to see why us issuing our own certificate is any more or less "secure" than
us paying $$ to another company to do the same thing.
> > Contrast this with PGP for email, in which I can publish a public key and
> > once you obtain it you're able to receive an encrypted communication from
> > me and decode the traffic. My generation of that key pair does not require
> > that it be "certified" by any third party.
>
>I hope you made some typo here. You do not use the thing conceptually
>referred to as "public key" to decode encrypted traffic/messages. That's
>what the private thingie is for. The public part is for signature
>verification (ie verifying the private part has been used to encrypt a piece
>of data).
>
>Problem with your PGP schema is that I can publish my public key on the
>keyserver (lets say the keys.pgpi.net which I trust a lot ;), you can get it
>there and use it to crypt data for me. Essential problem here: how do you
>know that the key you're using is mine and not from someone claiming to be
>me (by entering *my* emailaddress and name during key generation)? Using
>signatures --> signature=certificate.
In this case - who cares? You'll receive a message composed and encrypted
using the fake public key, but will be unable to decrypt it. If you
compose a message, a recipient using the fake key will not be able to
decrypt it. The worst that happens, as I see it, is an annoyance caused to
both parties.
> What is true is
>that those stupid browser applications refuse to see key generation and the
>*possible* certification as different steps. With openssl of course this is
>possible.
<snip>
>I agree the key generation and the certification process *should* be
>seperated, also in browsers. It is *not* possible for me to make a copy of
>my oh so valuable private browser key *before* I receive my certificate
>(which can be up to five days according to our certification practise
>statement) which bothers me very much. I can not revoke the certificate and
>just use the same key again.
I'm not understanding what you are discussing here. Can you explain this
concept a bit further please?
Cheers!
Jon
-----------------------------------------------------------------
Jon Earle (613) 612-0946 (Cell)
HUB Computer Consulting Inc. (613) 830-1499 (Office)
http://www.hubcc.ca 1-888-353-7272 (Within Canada/US)
"God does not subtract from one's alloted time on Earth,
those hours spent flying." --Unknown
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
