Archived from groups: comp.security.firewalls (
More info?)
Mailman <mailman@anonymous.org> writes:
> I don't know where you got that idea, but it just doesn't work that
> way.
>
> A certificate is a third party confirmation of your NAME, not your
> address. Thus a server certificate (which is probably what the OP
> was asking about) simply confirms that the server www.serv.com
> really is www.serv.com. What the IP address is has nothing to do
> with this: that is the job of the DNS.
>
> Look up the definition of the certificate fields for X509.
>
> As to "adding certificates to the firewall" - the question is
> meaningless. A firewall has no certificates, nor does it use them. A
> certificate is almost always connected to an application (Web
> server, EMail server, proxy, browser, EMail client, VPN, etc), so
> you need to look for the documentation for those. -- Mailman
domain name server certificates exist because of trust issues with the
domain name system and am I really talking to the server I think that
I'm talking to.
basically 3rd party certificatation authority is asked to certify that
i'm really the owner of the domain name and issue a certificate to
that effect.
the client types or clicks on a URL ... the browser goes off and
contacts the server, the server sends back a certificate ... the
browser checks to see if it is a valid certificate (using a table of
certification authority public keys that have somehow been loaded into
the browser at some time) and then checks to see if the domain name in
the certificate matches the typed or clicked on value. so one of the
exploits is to get the user to click on a field that actually points
to a domain name that matches a certificate that a bad guy might
happen to have.
now, the 3rd party certification authorities ... in order to certify
somebody is really the domain name owner ... have to contact the
authoritative agency for domain name ownership; which turns out to be
the domain name infrastructure ... this is the same entity that people
supposedly have trust issues with and therefor believe they need
certificates.
now, 3rd party certificate authorities have some trust issues and
process issues with domain name infrastructure also ... there happen
to be a number of proposals to improve the integrity of the domain
name infrastructure ... some of them being backed by the 3rd party CAs
(if people can't trust the source of the information for the certified
infomration, how can they trust the certificate).
one of these proposals somewhat from the 3rd party CA industry,
involve a domain name owner registering a public key with the domain
name infrastructure at the same time they register their domain name.
Future interaction between the domain name owner and the domain name
infrastructure can involve digital signatures that can be validated
with the registered public key ... minimizing things like domain name
hijacking and various other exploits. So this improves the reliance
and trust that the 3rd party CA industry places in the domain name
infrastructure.
the other issue is that the 3rd party certification process is fairly
expensive identification process. the current paradigm has the domain
name owner registering a bunch of identity information with the domain
name infrastructure. when the domain name owner applies for their
server certificate, they also provide a lot of identification
information. The 3rd party CA than has an expensive and error prone
process matching the presented identification information with the
identification information on file with the domain name
infrastructure. With a public key on file with the domain name
infrastructure, the domain name owner can just digitally sign a
certificate request. the 3rd party CA then just has to retrieve the
public key on file and verify the digital signature. This changes an
expensive and error prone identification process into a much simpler,
less error prone, and less expensive authentication process.
So there is something of a catch22 for the 3rd party certification
industry.
1) If the integrity of the domain name infrastructure is improved,
then the lack of trust supposedly will be lowered, which likely also
results in lower demand for certificates.
2) if there is a public key on file with the domain name
infrastructure (for the domain name owner) that the 3rd party
certification process can retrieve for authentication ... then
presumably other entities, like end-users and clients might also be
able to retrieve the public key for performing authentication
.... eliminating the requirement for needing digital certificates
issued by a 3rd party certification authorities.
misc. past posts on ssl server certificates
http://www.garlic.com/~lynn/subtopic.html#sslcert
note that general case of using the domain name infrastructure for a
public key server (w/o needing certificates) shows up in some of the
anti-spam proposals for authenticating email senders.
part of the issue is that that the domain name infrastructure is
actually a distributed, near-real-time, information distribution
mechanism. it is currently primarily used to distribute the ip-address
related to a specific domain or host name. however, the domain name
infrastructure has also been used for serving up other kinds of
real-time data. There is nothing that prevents the domain name
infrastructure from also serving up real-time public keys that are
bound to a domain or host name.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Facebook
Twitter
Instagram