Götz Babin-Ebell <[EMAIL PROTECTED]> writes:
> And how gets he the connection IP-Address <-> FQDN ?
> ->He uses DNS.
I think you need to reread his message since that's not
what he says.
> If he wants to allow user XYZ presenting certificate C_XYZ to
> do some things, all he has to do is look in an internal
> table to map the cert to the allowed tasks.
> Introducing the FQDN into this is a useless layer of complexity...
This is exactly what he's doing but he wants to use the FQDN
as the lookup key. If he knows that the FQDN is in the certificate,
this is perfectly reasonable.
Consider the case of SMTP-relaying. You wish to ensure that only
certain hosts can relay through you which requires determining which
each client is. In the old days you'd get their IP and do a reverse
lookup.
If you require clients to have certificates then you can just
ignore the IP, get the certificate and make your access decision
off the DN. It's extremely convenient to be able to express these
decisions in the language of hostnames, so it's convenient to have
the FQDN in the DN and use that for your access control decisions.
This has the added advantage that you can express expressions,
e.g. allow connections from "*.example.com". Provided that you can
trust the CA to only issue certificates with correct FQDNs in them
(which people do, since that's required for SSL security) then
this is quite a useful procedure.
-Ekr
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
