Caller ID "spoofing" 2976

ref:

and of course, whole collection of past posts mentioning ssl certificates and exploring numerous aspects of the whole paradigm.

basically the current certification is to prove that the applicant for a SSL domain name certificate is, in fact, the owner of that domain name. this is countermeasure to some internet (especially domain name infrastructure) integrity issues where a website might be impersonate another website.

a problem in some of the current internet bank website exploits is that the process only validates that the website that the end-user is talking to is actually the website that corresponds to the URL supplied to the browser. However, it is dependent on the end-user for providing trust continuity between who the end-user believes they are talking to and the supplied URL. With convention of end-users simply clicking on things purported to be correct URLs ... that trust continuity is broken.

another problem is that the certification authorities that supply SSL domain name certificates require an application to provide a lot of information ... which the certification authorities then do an expensive, error-prone, and time-consumer identification process, attempting to match the supplied information with the information on file with the domain name infrastructure as to the owner of the domain name.

however, this is the same domain name infrastructure that has some integrity issues which, in turn, give rise to some of the requirements for SSL domain name certificates. so the certification authority industry is somewhat backing various activities to improve the integrity and trustfullness of the domain name infrastructure (since they are dependent on the integrity of the domain name infrastructure as to whether a ssl domain name certificate applicant is the actual owner of that domain name). one of the proposals is to have domain name owner's register a public key when they apply for a domain name. all future communication with the domain name owner and the domain name infrastructure is then digitally signed (helping reduce various kinds of exploits like domain name hijacking).

having public keys on file with the domain name infrastructure also provides an opportunity for certificate authority industry to require that ssl domain name certificate applications are digitally signed. Then the certificate authority can replace a time-consuming, error-prone, and expensive identification process with a much simpler, less-expensive and more reliable authentication process (simply by retrieving the onfile public key from the domain name infrastructure and validating the digital signature on the SSL domain name certificate application).

A catch22 for the certification authority industry is that improving the integrity of the domain name infrastructure eliminates some of the original motivation for having SSL domain name certificates.

Another catch22 for the certification authority industry is that the whole SSL domain name certificate paradigm is based on having trusted public keys come from the SSL domain name certificate (as part of proving that the end-user is actually talking to the webserver they think they are talking to). However, the domain name infrastructure is such that if the certification authority industry can directly retrieve on-file, trusted public keys directly from the domain name infrastructure, then so can the rest of the world ... eliminating the need for SSL domain name certificate as a mechanism for providing trusted public keys.

lots of past posts mentioning the catch22 dilemma for the certificate authority industry

--