My impression was that Klaus wanted to use TLS for authentication (that is badguy.com is really badguy.com if he had certificate signed by trusted CA) and then perform authorization based on some data obtained from TLS. In other words, TLS based authentication is transparent to the application, while for TLS based authorization more code in SER is needed.
Jan.
On 11-10-2005 23:04, Nils Ohlmeier wrote:
On Tuesday 11 October 2005 16:32, Klaus Darilion wrote:
Jan Janak wrote:
Client certificate ? Why ? Make sure that the client certificate is created by a trusted CA (which is known to SER) and once a request arrives over TLS then you know that the certificate was valid (provided that you enable client certificate verification).
Knowing that the certificate is valid is not enough. Badguy can have a certificate for badguy.com which is perfectly valid, but this does not imply that I trust badguy.com. I have to compare the certificate domain with the domains of trusted peers somehow.
Klaus, if you do not trust badguy.com although he has a valid singed certificate from a CA which you trust, then you can throw away TLS completely. The hole model only works because the trust in inherited from the CA when you get a singed certificate. If you do not trust any CA, except your own, then you created your own trust database which is hard to maintain. No matter what is the base of the trustworthyness (IP; certificate signed by you; shared secret or signed certificate for IPSec) maintaining the trust database (or however you call it) is a real pain, that is the reason why you should trust someone else to do this job.
BTW why do you need/want to trust someone and others not? You want to give privileges to the trustworthy. But what happens if they cheat you? You should be able to track them down. And then sue them (if the laws of both countries allows this)?
Sueing them is your only weapon in the end. If you cant sue them you are doomed anyway no matter what is your trust base.
Enough philosophy :-) Nils