"Mark H. Wood" wrote:
> You don't have to, but you may decide that it's much better than the
> alternatives. You could create your own certificate, but you need to
> answer two questions first:
>
> o How will my users acquire copies of my certificate?
Huh? The certificate is presented as part of the SSL handshake.
> o Why should they trust that certificate, or that delivery
> mechanism?
If it's a closed system, you may instruct users to click on a link
that presents the root cert with MIME type "application/x-x509-ca-cert"
and provide instructions on how to answer the ensuing dialog boxes.
> Think about it for a moment. If a total stranger walked up to you and
> said, "I represent a bank. Give me all your money and I'll open an
> account for you," you'd laugh and walk away. If your longtime friend,
> known to be working for a bank, said, "Jenny here is our new accounts
> manager; give her all your money and she'll open an account for you", you
> might well trust him (and her) even though it's not quite what you're used
> to.
You present a web of trust model which is somewhat misleading -- a web
site may present a cert which your browser trusts because it's signed
by VeriSign -- this doesn't mean that www.blah.net is really not in the
business of ripping of credit card presenters. Authentication is not
authorization.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
