Five Theses on Security Protocols

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com