Re: [TLS] HTTPS client-certificate-authentication in browsers

Martin Rex <> Wed, 27 July 2011 22:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D31E11E8092 for <>; Wed, 27 Jul 2011 15:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7JAhnAcotkJO for <>; Wed, 27 Jul 2011 15:38:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6C41711E8084 for <>; Wed, 27 Jul 2011 15:38:02 -0700 (PDT)
Received: from by (26) with ESMTP id p6RMbsSs017504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 00:37:59 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (Henry Story)
Date: Thu, 28 Jul 2011 00:37:53 +0200 (MEST)
In-Reply-To: <> from "Henry Story" at Jul 27, 11 11:56:49 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Jul 2011 22:38:03 -0000

Henry Story wrote:
> On 27 Jul 2011, at 23:29, Martin Rex wrote:
> > 
> > "Logoff" is a pure server-side concept with respect to server-side
> > state.  A logoff concept that requires cooperation from the client
> > is technical nonsense.  Any server-side destruction of backend-state
> > associated with particular clients must work completely independent
> > of what the client does.  Early consensual destruction of backend
> > state if the client explicitly asks for it is OK.  But any
> > server-initiated "logoff" concept that involves the client
> > amounts to technical cluelessness.
> why is that? Why can't the client log itself off.

That falls under "Early consensual destruction of backend state if
the client explicitly asks for it is OK" above.

> That would be much better for the user, as he would be
> in control of his identity.

The user is _always_ in control of his identity.
But you can never get virginity back once you give it up.

Once you revealed your identity to a server, you can not
undo it.

> This could be done easily by a browser both with cookies and with TLS:
>  - with cookies: the browser should tie every cookie and state
>     to a user identity. When the user switches identity, the cookies
>     stop getting sent.
>  - with TLS the client breaks the connection,
>    and re-established a completely new one.

If you're wondering whether there should be a standard where
a Web Browser should offer a context-specific, easily accessible button
to the user to make the Browser _prompt_ on the next connect to the server
before providing any of the integrated "single Sign-on" functionality
(be it cookies, WWW-Authenticate: headers, HTTP Negotiate, or TLS CCA
 or automatic user&password fill-in to forms).

Making such a functionality accessible to the server probably would
not hurt.  Preferably _without_ javascript or other active content,
and instead controls similar to (e.g. META) for page refresh and
client-side cache flushing.

>     For the server that ends up being the equivalent of a log-off.

If a user wants to perform a "logoff", he might be interested in
_both_ happening:

  - the server side backend state getting flushed along with client-side
    state (so that no-one with a copy of the server application sessionid
    can resume the session from elsewhere without having to perform
    an authentcation step).

  - the browser suspending _IN_A_CONTEXT/TARGET_SPECIFIC_FASHION_ any
    single Sign-On functionality (Cookies,WWW-Authenticate,HTTP Negotiate,
    TLS CCA, automatic user&password fill-in) until it is interactively
    reconfirmed to continue

It may be more difficult to standardize a client-side "button" and
the signaling of the "logoff" to the server application so that it
can clean up, than to require the application to offer a "logoff"
button and tell the browser to suspend Single Sign-On for this
context/target.  Closing of a browser window does not necessarily
imply a "logoff" for apps that allow for several parallel and
independent workflows.  The server app usually knows more about
the application architecture than the user does (and whether to
warn the user about unsaved date that will get purged by logoff)