We were working on high-availability and no-single-point-of-failure and also doing cluster scaleup (for both commercial and numerical intensive) ... originally it was called HA/6000, but I coined "HA/CMP" as marketing term to capture both concepts. Part of the effort was with major RDBMS vendors ... including Oracle. This is old reference to Jan92 meeting in Ellison's conference room
http://www.garlic.com/~lynn/95.html#13

Two of the people in the meeting later leave and join a small client/server startup responsible for something called the "commerce server". Approx. a month after the Jan92 meeting, the cluster scaleup part is transferred (and announced as a supercomputer for numerical intensive only) and we were told we couldn't work on anything with more than four processors. This motivates us to leave.

Sometime later, we are brought in as consultants to the small client/server startup because they want to do payment transactions on their server; the startup up had also invented this technology they called "SSL" they wanted to use; the result is now frequently called "electronic commerce". As part of the deployment we do audits and walk throughs of these new businesses selling SSL domain name certificates. misc. past posts
http://www.garlic.com/~lynn/subpubkey.html#sslcert

The browser Certificate Authority operational model wasn't a "no single-point-of-failure" ... it was an "any point of failure" ... the probability of a failure increases as the number of CAs increase (a systemic risk scenario). Also there were some security assumptions about the browser/server deployments ... which were almost immediately violated ... voiding some amount of the security model. It wasn't long before I coined the term "comfort certificates" in attempt to differentiate the feeling of security from real security.

The SSL domain name Certification Authority model has somebody applying for a digital certificate and providing identification information. The CA then must contact the authoritative agency responsible for domain names to cross-check the application supplied identification information with whats on file with the domain name authoritative agency (time-consuming, error-prone, and expensive).

The CA industry has somewhat backed pieces of DNSSEC as eliminating some number of authoritative agency vulnerabilities (i.e. the CA industry trust root is the authoritative agency responsible for the domain name information) ... like domain name take-over. Part of that is a domain name registrant, at the same time also registers a public key. Then all future communication between the domain name owner and the domain name infrastructure is digitally signed, which can be verified with the on-file public key. It turns out that the CA industry could also require SSL digital certificate application to also be digitally signed ... and then they could eliminate the time-consuming, error-prone and expensive identification process with a much simpler, more reliable, and less expensive authentication process by doing real-time retrieval of the on-file public key at the domain name infrastructure.

However, this creates something of a "catch-22" for the SSL domain name CA industry, since if they can do real-time retrieval of on-file public key (for authentication), then others might also start doing something similar ... eliminating the need for SSL domain name digital certificates. misc. past posts mentioning catch-22 for the SSL domain name CA industry
http://www.garlic.com/~lynn/subpubkey.html#catch22

I had worked on HSP in the late 80s ... that included being able to do a reliable transactions in minimum of three exchanges ... compared to minimum of seven exchanges for TCP. In the mid-90s, as HTTP servers were starting to scale-up they were starting to find that 99% of the processor was starting to be used dedicated to running the TCP FINWAIT list (most TCP implementations had been designed assuming long-lasting reliable connections, and had never anticipated it to be used for something like HTTP). I proposed being able to piggy-back returning public key in the domain name to ip-address response. Then a light-weight SSL connection could be done in an HSP 3-packet exchange ... but client generating symmetric packet key, encrypting the packet, encrypting the packet key with the server public key. In effect, light-weight SSL could be done in the same number of packets as a non-encrypted, non-SSL operation. misc. past posts mentioning HSP
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

Disclaimer: Somewhat in the wake of having done "electronic commerce", in the mid-90s, we were invited to participate in the X9A10 financial standard working group which have been given the requirement to preserve the integrity of the financial infrastructure for *ALL* retail payments.

The result was the x9.59 financial transaction standard which allowed for digitally signed transactions but didn't require digital certificates to be appended to the transactions. Some references
http://www.garlic.com/~lynn/x959.html#x959

Part of the issue was that even an abbreviated (relying-party-only) digital certificate (i.e. the information was registered with the relying-party, the relying-party would issue a digital certificate for use only by the relying-party) was 100 times larger than the typical payment transaction payload size. misc. past posts mentioning the enormous payload size bloat that would come from appending digital certificates to payment transactions
http://www.garlic.com/~lynn/subpubkey.html#bloat

the issue was that since the relying-party already had the information (contained in the digital certificate), it was redundant and superfluous to append the same information (in the form of digital certificate) to every payment transaction (besides representing enormous payload bloat).

The largest use of SSL in the world is this thing called "electronic commerce" for hiding transaction details. One of the characteristics of X9.59 transactions was that it was no longer necessary to hide the transactions ... which eliminated the major use of SSL in the world. Not needing to hide the information also eliminates threats from skimming, evesdropping, and data breaches. It doesn't eliminate such activity, but the major motivation is crooks using the harvested information for fraudulent transactions. X9.59 eliminated the ability of crooks to use such harvested information for fraudulent transactions ... and therefor eliminated the attractiveness to crooks for performing such operations.

I guess everyone has forgotten the grand plan of RSA(circa 1994) (Jim Bidzous's) to monetize the entire internet via CA's(one of their more retarded ideas!). (Tollbooths on the internet).

I thought this to be SO significant and threatening that ONE of my personal buyoffs to work on SKIP and the CA structure for SunLabs as an external consultant was to insist that the source code for the CA function be released in opensource form(which eventually happened).

SSL was truly a joke in the early days as far as security went(still is) and Ian Goldberg set about proving that in short order.

And dont even get me started on the so called SSL infrastructure whose demise has amazingly taken so many years.

As a LOT of us know the entire structure has been a house of cards and a confidence game rigged against companies and consumers alike.

I for one am VERY happy that DigiNotar took place and that all the CA compromises are happening and subsequently a collapse of the whole SSL/CA industry(hmm time for a short?(way too late))

Maybe now we can get onto actual financial crypto instead of SSL/CA craptastic window dressing.

Sheesh
gwen

Security "best practices" are The Maginot Line mentality. The Maginot Line was easily flanked by Germany's maneuver units.

The best defense is good offense. So how does that translate to cyber security?