Client Certificate UI for Chrome?

[James A. Donald]

     --
 > "James A. Donald" <jamesd at echeque.com> writes:
 >> For password-authenticated key agreement such as
 >> TLS-SRP or TLS-PSK to work, login has to be in the
 >> chrome.

Peter Gutmann wrote:
 > Sure, but that's a relatively tractable UI problem

Indeed.  You know how to solve it, and I know how to
solve it, yet the solution is not out there.

As you say, shared secrets should be entered a form that
implements password-authenticated key agreement such as
TLS-SRP or TLS-PSK, that cannot easily be spoofed, that
is clearly associated with the browser and with a
particular url and web page (you suggest that the form
should roll out of the browser bar with an eye catching
motion and land on top of the web page) and an encrypted
connection should be established by that shared
knowledge, which cannot be established without that
shared knowledge.

This, however, requires both client UI software, and an
api to server side scripts such as PHP, Perl, or Python
(the P in LAMP).  On the server side, we need a request
object in the script language that tells the script that
this request comes from an entity that established a
secure connection using shared secrets associated with
such and such a database record entered in response to
such and such a web page, an object to which the script
generating a page can associate data that persists for
the duration of the session - an object that has session
scope rather than page scope, scope longer and broader
than that of the thread of execution that generates the
page, but shorter and narrower than that of the database
record containing the shared secrets, a script
accessible object that can only be associated with one
server, one server side process and one server side
thread at a time.  This is non trivial to implement in
an environment where servers are massively
multithreaded, and often massively multiprocess.

 > Certificates on the other hand are an apparently
 > intractable business, commercial, user education,
 > programming, social, and technical problem.  I'd much
 > rather try and solve the former than the latter.

What makes certificates such a problem is that there is
someone in the middle issuing the certificate - usually
someone who does not know or trust either of the
entities trying to establish a trust relationship.

While certificates frequently makes cryptography
unnecessarily painful and complicated, certificate issue
offers the opportunity to make money out of providing
encryption by being that someone in the middle, hence
the remarkable enthusiasm for this technology, and
stubborn efforts to apply it to cases where its value is
limited, and it is far from being the most convenient,
practical, and straightforward solution.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com