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