[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SSL/TLS client-auth - Not the way forward?



>What exactly is your question?

Michael,
One question was actually in the subject line.

Another question could be if this should in some way be addressed
by future standardization efforts.

I forgot a major reason for why SSL/TLS client-auth is likely to be
of limited use and that is the absence of a "WebSign" standard.
If certificate selection when authenticating and signing are different,
users get confused.  That's why all these Java-things normalize
this part by not using the native support.

That is, w.r.t. PKI practically every aspect of browser usage is
currently non-standard, including:

- certreq/keygen
- websign
- client-auth

This is a bit surprising as client-side PKI in conjunction with browsers
is at least a magnitude bigger than in conjunction with secure e-mail,
and the gap is widening.

rgds
Anders R

----- Original Message ----- 
From: "Michael Ströder" <michael@xxxxxxxxxxxx>
To: "Anders Rundgren" <anders.rundgren@xxxxxxxxx>
Cc: <ietf-pkix@xxxxxxx>
Sent: Saturday, December 18, 2004 15:37
Subject: Re: SSL/TLS client-auth - Not the way forward?


Anders Rundgren wrote:
>
> ==================
> It is not using 2way SSL, if it were, there was really no need for it.
>
> fact is, 2way SSL only works in very simple scenarios, accessing only
> one host with no need to handle "logoff". In more often (larger scale)
> solutions, 2way SSL in reality works bad (because browsers will
> renegotiate SSL connections with host changes - also when changing
> subdomains within a domain). 2way SSL breaks SSO when switching
> between different subdomains within the same domain.
>
> because of the problems with 2way SSL, openlogon is designed to use
> 1way ssl, doing the "client side auth" as part of the applet.
>
> Also, 2way SSL is end-to-end between the browser and the server that
> terminates the SSL session. But in most larger setups, this tends to
> be SSL accelerators which sends on (only) the client public
> certificate to the application server. End-to-end is then only over
> the internet, where OpenLogon really is end-to-end since the SSL
> accelerators only takes care of the resource consuming keyexchange.
> Auth is handled by the logon service in the application server.
> ====================
>
> Comments?

What exactly is your question?

Ciao, Michael.