so lets step back and look at it in smaller baby steps domain name infrastructure has integrity issues that can result in both ip-address take-over as well as domain name take-over.
ssl domain name certificates are targeted at detecting ip-address take-over situations (by detecting that a fraudulent web server doesn't have a certificate matching the expected domain name). ssl domain name certicates don't address the domain name infrastructure integrity issues associated with domain name take-over ... leaving the possibility of undetected fraudulent web servers. so a couple items from the original electronic commerce stuff 1) my wife and I coined the term "certificate manufactoring" to distinquish the deployed ssl domain name certificate quick & dirty patch ... from a PKI 2) my wife and I wrote up some stuff about things that might be certified as to the validatity and/or integrity of merchant sites ... which were never adopted. so lets step back from my assertion about domain name infrastructure server up public keys along with ip-address for domain names. a side observation ... while domain name infrastructure may have no warranties with respect to financial dependent transactions ... the web and any related financial transactions are depedentent on the domain name infrastructure correct operation in order to operate. The ssl domain name certificates don't prevent ip-address take-over ... it just provides a mechanism for detecting it. This possibly removes some number of fraud motives for doing an ip-address take-over. however, other reasons for ip-address take-over ... like denial of service attacks can still occur, and potentially bring all such financial transactions to a stop. So while there is no warranty with regard to guarenteeing correct financial transactions ... there still is significant financial exposure if such financial transactions were prevented. Whether there are warrenties or not ... the financial impact is nearly as bad if the domain name infrastructure doesn't have the integrity to restand denail of service attacks is signficant (even if one doesn't believe the domain name infrastructure will have the warranties to back actual financial transactions). so lets look at a little baby step that results in the domain name infrastructure serving up a public key along with the ip-address for a domain name. lets say instead of registering just the public key in the domain name infrastructure an abbreviated domain name certificate was registered aka domain name, public key, certification authority digital signature and a certification authority identification. Instead of serving up a "bare" public key ... lets suppose that the domain name infrastructure serves up such an enhanced public key. what are the differences from the current environment. 1) current environment is dependent on the correct operation of the domain name infrastructure to function 2) current environment uses ssl domain name certificates to detect ip-address take over (doesn't prevent them, just detects them). 3) real-time serving of an abbreviated certificate will work correctly when the domain name infrastructure is working correctly 4) any failure in the real-time serving of an abbreviated certificate will result in an ip-address take over being detected. I claim that there is no security and/or integrity difference whether such a certified public key comes from the webserver (as in the current implementation) or from the domain name infrastructure. It addresses any suggestions that the fundamental holes in the domain name infrastructure with respect to ip-address take-over may take some time to fix and the quick & dirty fixes are with us for some time to come. It also has the characteristic that the domain name infrastructure can "revoke" a certificate in real time by deleting it from the domain name entry (and no longer serving it up). This allows effectively much of the business characteristics of a full-blown PKI ... while not requiring the client to implement any additional OCSP and/or CRL complexity stuff. The domain name infrastructure isn't at any more risk than it is today with the SSL certificates coming from the webserver. It still is subject to denial of service attacks because of attacks resulting in incorrect operation. However, the availability of a valid abbreviated certificate can detect an ip-address take-over ... and an incorrect certificate and/or a missing certificate won't result in a valid SSL connection by a fraudulent webserver. The domain name infrastructure serves up public key ... just as in my original description ... but allows that integrity issues with respect to ip-address take-over not being fixed for some time to be accounted for. It also has the advantage that when operating correctly the effect of PKI management of manufactored certificates is provided for w/o actually involving any client implementation. It doesn't prevent any attacks on the domain name infrastructure that result in incorrect operation and effectively denial of service (which is exactly the same in either SSL domain name certificate operation). The issue is that as (or if) domain name infrastructure comes to be trusted ... the per transaction verification of the signature on the abbreviated certificate no longer has to be performed .... but the data flows and the implementation operation stay the same. Of course, this by itself does nothing to address the issue of domain name take over integrity issues ... other than in the existing proposal that a public key be registered when the domain name is registered ... and that all future communication between the domain name owner and the domain name infrastructure is digital signed (and can be verified with the public key on file for the domain). The public key on file can be encoded as a bare public key ... or as part of an abbreviated certificate that is digital signed by a certification authority. However, has detailed in the related description for financial transactions with public key on file ... it isn't necessary to revalidate the certification authority's signature once the public key is reliably added to the account record. I assert that this intermediate step retains all the integrity characteristics of the currently deployed ssl domain name certificate infrastructure ... with the added advantage of: 1) the effective equivalent of PKI management of manufactored certificates is achieved by being able to eliminate/remove the certificate from the domain name database entry (and not serve it up ... which would achieve the same thing as daily distribution of CRLs to every possible client in the world &/or an OCSP implementation by every client in the world) 2) the ability to create a highly optimized SSL transaction implementation since the client can have all the necessary information prior to initiating the webserver communication. 3) at some point when the integrity issues with the domain name infrastructure are resolved ... and issues like denial of service attacks are eliminated, then the public key and process data flow stays exactly the same .... except that the bare public key can be distributed w/o the accompanying certificate envelope.
