On Wed, Oct 01, 2003 at 04:48:33PM +0100, Jill Ramonsky wrote:
> I could do an implementation of SSL. Speaking as a programmer with an 
> interest in crypto, I'm fairly sure I could produce a cleanly 
> implemented and simple-to-use version.

Yep.  It's a bit of work, and more work to ensure that
there are no programming bug type security holes, such as those
recently announced, but it's not rocket science.

> But I would like to ask you to clarify something about SSL which has 
> been bugging me. Allow me to present a scenario. Suppose:
> (1) Alice runs a web server.
> (2) Bob has a web client.
> (3) Alice and Bob know each other personally, and see each other every day.
> (4) Eve is the bad guy. She runs a Certificate Authority, which is 
> trusted by Bob's browser, but not by Bob.
> Is it possible for Bob to instruct his browser to (a) refuse to trust 
> anything signed by Eve, and (b) to trust Alice's certificate (which she 
> handed to him personally)? (And if so, how?)

Yes and yes.  Most SSL/TLS implementations let the application designate a
set of certs as trusted CA certs for purposes of authenticating SSL peers.
If his client is programmed to let him, Bob can delete Eve's cert from
the trusted CA list.  Many browsers let you do this although it's often
hard to find in the config menus.

For (b), Bobs client would need to be able to mark Bob's copy of Alice's
cert as "trusted" even though its not a self-signed CA cert.  This is
also just a matter of programming, but most browsers don't let you do
this-- their programmers decided that in order to simplify operation,
they would not allow browsers to mark non-selfsigned certs as trusted.

The SSL/TLS spec is pretty quiet about what peers use to authenticate
the certs that they receive.  You'd be free to implement a PGP-style
web of trust in your TLS implementation as long as the certs themselves are
X.509 format.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to