having worked on some of the early e-commerce/certificate stuff ... recent ref: http://www.garlic.com/~lynn/aadsm13.htm#25 Certificate Policies (addenda)
the assertion is that basic ssl domain name certificate is so that the browser can check the domain name from the url typed in against the domain name from the presented (trusted) certificate ... and have some confidence that the browser is really talking to the server that it thinks it is talking to (based on some trust in the issuing certification authority). in that context ... self-certification is somewhat superfluous ... if you trust the site to be who they claim to be ... then you shouldn't even have to bother to check. that eliminates having to have a certificate at all ... just transmit a public key
so slight step up from MITM-attacks with self-signed certificates would be to register your public key at the same time you register the domain. browsers get the server's public key from dns at the same time it gets the ip-address (dns already supports binding of generalized information to domain ... more than simple ip-address). this is my long, repetitive argument about ssl domain name certification ....
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
i believe a lot of the non-commercial sites have forgone SSL certificates .... because of the cost and bother.
some number of the commercial sites that utilize SSL certificates .... only do it as part of financial transaction (and lots of them .... when it is time to "check-out" .... actually transfer to a 3rd party service site that specializes in SSL encruyption and payments). The claim by many for some time .... is that given the same exact hardware .... they can do 5-6 times as many non-SSL (non-encrypted) HTTP transactions as they can do SSL (encrypted) HTTPS transactions .... aka they claim 80 to 90 percent hit to the number of transactions that can be done switching from HTTP to HTTPS.
a short version of the SSL server domain name certificate is worry about attacks on the domain name infrastructure that can route somebody to a different server. so SSL certificate is checked against to see if the browser is likely talking to the server they think they are talking to. the problem is that if somebody applies for a SSL server domain name certificate .... the CA (certification authority) has to check with the authoritative agency for domain names .... to validate the applicants domain name ownership. The authoritative agency for domain names is the domain name infrastructure that has all the integrity concerns giving rise for the need for SSL domain name certificates. So there is a proposal for improving the integrity of the domain name infrastructure (in part backed by the CA industry ... since the CA industry is dependent on the integrity of the domain name infrastructure for the integrity of the certificate of the certificates) which includes somebody registering a public key at the same time at a domain name. So we are in catch-22 ....
1) improving the overall integrity of the domain name infrastructure mitigates a lot of the justification for having SSL domain name certificates (sort of a catch-22 for the CA industry).
2) registering a public key at the same time as domain name infrastructure ... implies that the public key can be served up from the domain name infrastructure (at the same time as the ip-address .... eliminating all need for certificates).
There is a description of doing an SSL transaction in single round trip. The browser contacts the domain name system and gets back in single transmission the 1) public key, 2) preferred server SSL parameters, 3) ip-address. The browser selects the SSL parameters, generates a random secret key, encrypts the HTTP request with the random secret key, encrypts the random secret key with the public key ... and sends off the whole thing in a single transmission .... eliminating all of the SSL protocol back&forth setup chatter. The browser had to contact the domain name system in any case to get the ip-address .... the change allows the browser to get back the rest of the information in the same transmission.
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
