On 07/31/2010 01:30 PM, Guus Sliepen wrote:
But, if you query an online database, how do you authenticate its answer? If
you use a key for that or SSL certificate, I see a chicken-and-egg problem.

Part of what is now referred to as "electronic commerce" is a payment gateway that 
sits between the internet and the payment networks. this small client/server startup that 
wanted to do payment transactions and had invented this technology called SSL, wanted to also 
use SSL for internet communication between the merchant servers and the payment gateway (as 
well as between browsers and merchant servers). One of the things that I mandated for the 
merchant servers & payment gateway was mutual authentication (wasn't part of the 
implementation up until then). By the time all required registration and configuration 
operations were done for both the merchant servers and the payment gateway ... it was 
apparent that SSL digital certificates were redundant and superfluous ... and purely an 
artificial side-effect of the software library being used.

The existing SSL digital certificates has a chicken-and-egg problem as to 
public key trusted repository for the authorized Certificate Authorities ... 
aka it requires a trusted repository of Certification Authority public keys in 
order to validate acceptable SSL digital certificates (as mentioned elsewhere, 
the infrastructure is vulnerable since all entries in the trusted repository 
are treated as equivalent; i.e. only as strong as its weakest Certification 
Authority ... aka the weakest link in the security chain scenario).

If the relying party has its own public key trusted repository and/or has 
trusted communication to a public key trusted repository then it can use public 
keys from the trusted repository. In fact, the whole PKI infrastructure 
collapses w/o relying parties having public key trusted repository (for at 
least the public keys of trusted Certification Authorities).

In that sense, PKI is just a restricted, special case of relying party public key trusted 
repository ... where the (special case Certification Authority) trusted public keys, in 
addition to providing "direct" trust, are then used to establish indirect trust 
for public keys belonging to complete strangers in first time (no-value) communication.

For the at least the first decade or so, the major world-wide use of SSL for 
electronic commerce ... was quite skewed ... with top 100 or so merchant 
servers accounting for the majority of all electronic commerce transactions. 
Collecting and distributing those (few) public keys (in manner similar to the 
way that Certification Authority public keys are collected and distributed), 
would satisfy the majority of all trusted electronic commerce. Then volume 
starts to drop off quite quickly ... so there are possibly million or more 
websites that have electronic commerce activity that could possibly justify 
spending $10 for the highest possible integrity SSL digital signature.

The SSL Certification Authority operations started out having a severe catch-22. A major 
objective for SSL was countermeasures to various vulnerabilities in the domain name 
infrastructure and things like ip-address take-over (MITM-attacks, etc; is the webserver 
that I think I'm talking to, really the webserver that I'm talking to). Certificate 
Authorities can typically require a lot of information from an applicant and then they do 
an error-prone, time-consuming, and expensive identification process attempting to match 
the supplied information against the on-file information and the domain name 
infrastructure as to the true owner of the domain. There have been "domain name 
take-over" attacks against the domain name infrastructure ... the attacker then 
could use a front company to apply for an SSL certificate (certificate authority shopping 
... analogous to some of the things in the news associated with the financial mess with 
regulator shopping). Any issued certificate will b
e taken as equivalent to the highest quality and most expensive certificate 
from any other Certification Authority).

So part of some Certification Authority backed integrity improvements to the 
domain name infrastructure ... is to have domain name owners register a public 
key with the domain name infrastructure ... and then all future communication 
is digitally signed (and validated with the certificateless, onfile public key) 
... as countermeasure to various things like domain name hijacking (eliminating 
some of the exploits where wrong people can get valid SSL certificates).

Turns out then the Certification Authority business could require that SSL 
digital certificate applications are also digitally signed. The Certification 
Authority then could do a real-time retrieval of the onfile public key to 
validate the digital signature (replacing the time-consuming, error-prone, and 
expensive identification matching process with an efficient, reliable, 
inexpensive authentication process). The issue for the SSL Certification 
Authority industry is if it starts basing its whole SSL digital certificate 
infrastructure on real-time certificateless public keys ... the rest of the 
world might think it was good enough, and start doing the same thing.

virtualization experience starting Jan1968, online at home since Mar1970

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to