[144721] in cryptography@c2.net mail archive
Re: Client Certificate UI for Chrome?
daemon@ATHENA.MIT.EDU (Peter Gutmann)
Tue Aug 11 11:53:48 2009
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: jamesd@echeque.com
Cc: cryptography@metzdowd.com
In-Reply-To: <4A809930.1060001@echeque.com>
Date: Wed, 12 Aug 2009 01:21:23 +1200
"James A. Donald" <jamesd@echeque.com> writes:
>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.
Ah, that is a good point, you now need the credential information present at
the TLS level rather than the tunneled-protocol level (and a variation of
this, although I think one that way overcomplicates things because it starts
diverting into protocol redesign, is the channel binding problem (see RFC 5056
and, specific to TLS, draft-altman-tls-channel-bindings-05.txt)). On the
other hand is this really such an insurmountable obstable? For client-cert
usage you already need to perform a lookup based on a given cert (well, unless
you blindly trust anyone displaying a cert coming from a particular CA or set
of CAs, which I know some sites do), so now all you'd be doing is looking up a
shared-secret value instead of a cert based on a client ID. I don't really
see why you'd need complex scripting interfaces though, just "return the
shared-secret value associated with this ID" in response to a request from the
TLS layer. The only problem I can see is if you have an auth system built
around "is this authenticator valid" rather than "return the authenticator for
this ID".
Peter.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
