James Whitmoor wrote:
(snip)
I disagree, I control my local server and DNS, Redleg controls his local server and DNS. We could happily exchange messages in clear but for privacy would like the option to choose to validate each others certs by external methods.
Yes, I know you control your DNS, and Redleg controls his/her. So... I leave your DNS (and Redleg's) alone, and go poison a DNS upstream. All I need is to have the remote user contact MY server first. Easy, unfortunately. And, what is worse, already done, many times over. End result: you will still believe you are all set & secure...
Of course, this is still rather different from broadcasting -- I would be the only one able to follow your conversations.
And, again of course, I might decide it's a good enough conversation to post out to the public.
If you have external methods to guarantee the key, then you do not need rootless certificates. In fact (except if you are using self-signed certificates), you do not need TLS/SSL at all.
(snip)
For private use, personal private verification works fine. Browsers happily let you import a non-CA cert and allow a user an option to do their own choice of verification first.
Yes... but you can set yours to at least warn you something (potentially) fishy is going on. Unfortunately, not many of the users do that. Also, I do not like the amount of root certificates given to us, by default, on Windows. But I certainly am *very* careful whenever I get to a site where I receive a certificate that does not match common name, or for which I have no root.
However this arguement assumes that I have not met my brother or friend and do not have another method of validation such as voice p2p. Also another thought, I may want to exchange mails with someone I do not trust - however I'd prefer the option to reduce the chance of someone else listening in at least for most of the journey.
This is valid only when all parties involved do have other means of certifying each other (like, as you point out, private comm, in loco meetings, etc). This does not apply to open-ended systems, like a HTTP server. And, if you want to exchange secure e-mail with somebody else, all you both need is to generate & exchange self-signed public certificates, and make sure both sides encrypt (or, of course, use PGP/GNUPG). An added bonus is signature and non-repudiation. But... you do not need, anymore, channel encryption. It can still be used, but you are not relying on it as the *sole* privacy measure.
Please remember that most people (and web sites) use server-only authentication -- you rely on the server for all encryption, authentication, validation, and certification. This is a major part in my worries. If I have to rely on a third party (which I do not personally know), then I want a bit more of safety. Accepting a rootless certificate voids all inherent safety.
Also, there are other means of securing a channel on a closed loop (i.e., where the parties know each other). You can use self-signed certificates here without any problems; you can use STS (Station-To-Station) encryption, which is pretty much like TLS/SSL, but without identification information; you can use PGP/GNUPG; etc, etc. TLS/SSL is built to allow you to secure a channel when the parties have *NOT* met, or do not physically know each other. It takes care of the key distribution problem for you.
(snip)
Cheers,
..hggdh..
________________________________________________________ Current beta is 3.0.2.1 Beta/1 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
