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 12:29:05 +0200
Cc: "public-identity@w3.org" <public-identity@w3.org>
Message-Id: <A9ECF86B-B086-42B1-A853-3FC8A035F59C@bblfish.net>
To: Anders Rundgren <anders.rundgren@telia.com>

On 6 Aug 2011, at 12:21, Anders Rundgren wrote:

> On 2011-08-06 11:44, Henry Story wrote:
> 
>>> I [really] like the trust model of WebID but not the enrollment in MSIE.
>> 
>> great. But what do you mean "the enrolment in MSIE" ?
> 
> The s.c. "solution" that is shipped with Internet Explorer which have
> created a virtual industry of people writing workarounds.

Ah yes, we have a workaround for them, and pointed out on the wiki.
It works well. 

> 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.
> 
> IMHO, the #1 problem with S/MIME is the *total lack of use-case analysis*.
> Organizations depend on secure storage for documents and data.  If you
> translate this to e-mail you would see that securing mail should have
> been delegated to the server (organization) level.
> 
> When you encrypt a message on the employee level both the recipients
> and the sender is sent in clear text!  How useful is that????

Very useful if you are a spy agency and you want to know who is trying to talk to whom but does not want you to know ;-)

By the way we came up with a way using WebID to replace S-MIME. Essentially just 
use the Atom Protocol of https, with a WebID. Publish your Blog with a limited
recipient list, notify the user with an HTTP based ping mechanism, and they can do
an HTTP GET on your "e-mail". That gives you end to end security. It would be easy to
crete smtp to Web mail proxies.

> 
> The primary culprit here is really the USG who has been the sole
> sponsor of the S/MIME specification.
> 
> Anders
> 
>> 
>>> 
>>> 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/
>> 
>> 
>> 
> 

Social Web Architect
http://bblfish.net/
Received on Saturday, 6 August 2011 10:29:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 6 August 2011 10:29:43 GMT