W3C home > Mailing lists > Public > public-identity@w3.org > August 2011

Re: WebID and HTTPS Client Certificate Authentication

From: Henry Story <henry.story@bblfish.net>
Date: Sat, 6 Aug 2011 11:44:33 +0200
Cc: "public-identity@w3.org" <public-identity@w3.org>
Message-Id: <35C299D8-ABC8-4074-A42F-3D59C69D012C@bblfish.net>
To: Anders Rundgren <anders.rundgren@telia.com>

On 6 Aug 2011, at 10:39, Anders Rundgren wrote:

> I believe we have entered another phase of web development were alternative
> routes to standardization are becoming more common due to the slowness and
> political difficulties associated with SDO processes.
> 
> That just about everybody is connected to the Internet and can update
> their SW platform in minutes makes the new ecosystem highly dynamic.
> 
> It isn't even necessary getting everything completely right from scratch.
> My experiences @ TrustedComputingGroup indicates that the traditional way
> of developing stuff for the masses is simply put contra-productive.
> 
> IMO "all bets are off" regarding the final solution for secure and
> ubiquitous access to the Internet.  It presumably lies in the hands of
> browser vendors and service providers.

Yes, but if you look at it you will see that the problem they will all face is the problem of  reference, not the problem of cryptography. It is the problem of trust of CAs that will always come back. So unless one works on that - a semantic web task - the issues will always come back. People are always mesmerised by syntax, thinking it is a syntactic problem they are confronting, when in fact it is at a different layer: distributed trust semantics. 


> I [really] like the trust model of WebID but not the enrollment in MSIE.

great. But what do you mean "the enrolment in MSIE" ?

> That HTTPS CCA was designed by the best cryptographers in the world
> doesn't necessarily make it a sure-fire success.  S/MIME anybody?

I am just a practical person trying to use what is available now.

Again with S/MIME - secure Mime, my guess is the problem is finding the key, and centralisation
of CAs, not the crypto technique behind it.

> 
> Anders
> 
> 
> On 2011-08-06 09:57, Henry Story wrote:
>> Hi Anders,
>> 
>>   I agree that there is not excellent support of CCA in browsers. But I am also surprised how much support there is for CCA in browsers given their very low usage. One could try to invent something
>> new, and I have nothing against that. BrowserId is one such idea, and as I argued on StackExchange [1], it would work with WebID too.  But that will also have a large adoption hurdle. Furthermore CCA
>> have a huge advantage for a more semweb world: they are completely robot friendly, and are extremely efficient.
>> 
>> Still we have implementations of WebId using CCA on pretty much every platform. It could easily be shipped with most J2EE services with a bit of work. And most services are moving to TLS. So TLS is
>> gaining a lot of visibility now.
>> 
>>  So I don't have anything against other technologies. TLS works for us now, and we can make the case for its usefulness. It is also easy to create services to authenticate people without TLS. I am
>> working on an improved version right now.
>> 
>> Henry
>> 
>> 
>> [1] http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid
>> 
>> 
>> On 6 Aug 2011, at 09:20, Anders Rundgren wrote:
>> 
>>> Dear List;
>>> 
>>> I would like to express why I feel that WebID (/long-term NB/) is worth a better client solution than HTTPS CCA (Client Certificate Authentication).
>>> 
>>> The innovation going on in the TLS space is hardly of any interest outside a small circle of cryptographers.  From a user's point-of-view /HTTPS CCA pretty much behaves like when it was introduced
>>> some 15 years ago/. 
>>> 
>>> There has been some efforts in the IETF to improve the client-certificate GUI but I doubt that Microsoft (who championed it), have any plans implementing it.  If you look deeper into the subject
>>> you'll soon find that it won't deliver much value unless you begin to muck around in the middleware layer and then it becomes really difficult since this involves third-party SW.
>>> 
>>> From a developer's point-of-view I feel that HTTPS CCA is a quirky technology since/it is clearly at odds with the web session concept/.  If you would like to mix and match passwords and CCA in the
>>> same web application it gets rather messy.  Due to automatic reauthentication performed by browsers, "logout" must be solved using highly dubious methods that haven't gotten any serious
>>> consideration by any standards group I'm aware of.
>>> 
>>> A particular issue with WebID is that you (if you use CCA) must /tweak the web-server to accept any certificate/.  For MOD-SSL hackers this is probably piece of cake but it surely isn't a standard
>>> feature in for example Java Servlet containers such as Tomcat and Glassfish.  /Using application-level CCA authentication you can run HTTPS in a completely plain vanilla (server only authentication)
>>> fashion/.
>>> 
>>> Since CCA on the web probably has less than a 0.1% "market-share", the incentive for improvements seems to be lacking.  Sweden's BankID who have three million users, recently introduced version #3
>>> of their browser PKI client that (for many reasons) use an application-level CCA authentication scheme.
>>> 
>>> The biggest bank used HTTPS CCA for decade but have now adopted BankID's PKI-client since they have given up on the browser vendors' abysmal support of client-side PKI, from enrollment to usage. 
>>> Ref: http://lists.w3.org/Archives/Public/public-html/2009Sep/0663.html
>>> 
>>> Anders
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
> 

Social Web Architect
http://bblfish.net/
Received on Saturday, 6 August 2011 09:45:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 6 August 2011 09:45:20 GMT