[Cryptography] Is it time for a revolution to replace TLS?

Anne & Lynn Wheeler lynn at garlic.com
Sun May 18 09:29:53 EDT 2014


On 05/17/14 23:03, James A. Donald wrote:
> What we need is a protocol for provably public assertions, where you
> can be sure you are seeing the same document as everyone else sees,
> and that the past cannot be rewritten.

in prior life, we had worked with the guys responsible for commerce
server at a small client/server startup and we were brought in as
consultants because they wanted to do payment transactions on their
server; the startup had also invented this technology called "SSL"
they wanted to use; the result is now periodically called "e-commerce".

Part of work was mapping "SSL" technology to payment business process
and working out recommendations on how it was deployed. Part of this
was that 1) it was necessary that the user needed to know the association
between the webserver they thought they were talking to and the URL
they typed into the browser and 2) "SSL" would provide the association
between the typed in URL and the webserver that they were talking to.
Both "1" and "2" were required to establish that the webserver the
user thought they were talking to was the webserver they were
actually talking to.

Almost immediately this was violated. Webservers found that "SSL"
cut their throughput by 90+% and so they dropped back to use "SSL"
just for check-out/paying. As a result, users were contacting a
non-validated webservers and then they would click on a button
and the non-validated webserver would provide a (SSL) URL ... which
the browser would validate. Now the best that could be said is that
the webserver that the user was talking to was the webserver that
they claimed it was (not necessarily the webserver the user thought
they were talking). This was when I coined the term "merchant comfort
digital certificates" ... referring to it provided a sense of comfort
(in contrast to "security").

Note another part of ecommerce was a "payment gateway" which handled
transactions between commerce servers on the internet and the payment
networks. They wanted to use "SSL" for this ... but I had complete
authority for this (I only could recommend about the browser/server
operation). First I required that it have mutual "SSL" authentication
... code which didn't exist at the time we started ... and then a
process that exchanged "public keys" out of band (the payment
gateway public key was shipped with the ecommerce server software,
somewhat like CA keys are included as part of browser software,
and ecommerce server public keys were part of registering ecommerce
servers with payment gateway). By the time things were done,
"SSL" digital certificates were purely an artificial aspect of
the software library being used ... aka the "digital certificates"
were redundant and superfluous.

I've then done several scenarios for browsers ... having caches
of public keys for online authoritative agencies ... where
real-time public keys can be obtained (similar to real-time
mapping of domain name to "ip-addresses") ... like domain
name servers serving public keys and payment gateways serving
public keys ... which  browsers can cache (so it doesn't have
to be done everytime).

-- 
virtualization experience starting Jan1968, online at home since Mar1970



More information about the cryptography mailing list