W3C home > Mailing lists > Public > public-webid@w3.org > November 2014

Re: Browser usability of Certificates - List of issues

From: <henry.story@bblfish.net>
Date: Fri, 21 Nov 2014 12:58:43 +0100
Cc: "public-webid@w3.org" <public-webid@w3.org>
Message-Id: <2302BBF0-3C27-4B19-8408-2FA1AF028356@bblfish.net>
To: Mo McRoberts <Mo.McRoberts@bbc.co.uk>
Thanks Mo. 

  I'd like us to perhaps put together a Note on Minimal 
Browser Improvements that are needed, based on this. 
( Or browser implementation best practices )

That is most of the issues you list seem to be something browser
vendors could easily fix. They don't seem to require TLS protocol
improvements, which would be much more difficult to get to.

We could put that together with a list of good certificate
management practices, to help solve problems that people
typically face, but for which there is a workaround.

I suggest we can start with a wiki on our Community Space for

> On 21 Nov 2014, at 10:49, Mo McRoberts <Mo.McRoberts@bbc.co.uk> wrote:
> On  2014-Nov-20, at 18:38, henry.story@bblfish.net wrote:
>>> Mo, could you drill down into the pain points, in order of what you see as the biggest, e.g. auth UI, keys across devices, lost keys, particular browsers, etc.
>> +1 that would be very helpful.
>> It looks like a big issue you have is due to Certificate Authorities. But once WebID removes that, what problems remain?
> CAs are a very small part of the puzzle, to be honest. The complication they meaningfully add is a one-time affair, and itís easily managed.

Ok, in your case as you are creating certificates for the BBC (and its partners?), 
which is a large enough community for these to having meaning. Perhaps an explanation
of how you use certificates would be useful. Where do people login with your 
Certificates? Only on the BBC site? Or also partner sites?

In general CA requirements make it impossible to use for any 
company smaller than the BBC. Particularly it makes it useless 
for individuals or small companies, as without a CA nobody would
recognise their certificate. It would only be useable for their
own site, in which case username/passwords would be all that is 

> The main issues, in no particular order, are:ó
> - Key/cert management functions in browsers are hard for people to find, and very inconsistent between browsers and operating systems
> Firefox insisting on using its own cert store really doesnít help matters, especially given that its buried several layers of options deep.

True, but when is it really necessary to use it? If you create a certificate 
the way specified by the WebID-TLS specification using keygen, then a user 
does not need to find that window to insert it.

> Smartphones and tablets are a whole other layer of fun, although there are tools to help.

yes, agree. That space would need to be explored on its own too.

> - Cert selection dialogs behave differently between browsers
> e.g., Safari always lists *all* certs for which you have a private key (including the auto-generated certs for iCloud), whereas Chrome will pay attention to the CCA acceptable CA list, for example.

 ok, so that's a UI bug on Safari. My guess is that if one shows more certificates
then those that are not applicable should at the very best be grayed out.

> - Stickiness is inconsistent
> e.g., Safari will re-prompt for cert selection every couple of pages when youíre browsing a secured site, unless you set an identity preference (which is poorly-documented, and can only be done through a separate utility).

 My experience is the opposite: Safari will never prompt you again once you have 
selected a certificate for a site, which in my view is a privacy bug.

   How do our setups differ here?

> - Where cert selection is sticky, thereís no user feedback
> If you use a browser which does remember your cert selection, thereís then nothing to indicate that youíve actually logged in using CCA, and what cert youíre using, unless the site happens to provide it (which is Ďsometimesí, depending upon whether the site was explicitly designed to work with CCA or pluggable auth or not).

  Absolutely agree. My argument has been that this feature is a key element 
and that it would tie in the logging out issue: because by showing the certificate
selected the user could then also choose to no longer use it. 

Furthemore there is a simple and powerful argument to get browser vendors to
move things along here: it is a privacy violation not to show the user what
identity he is logged in as.

> - No logging out
> Solve the lack of browser chrome to tell me that Iím logged in, and youíve got an easy place to let me log out, of course. This is a bigger deal for WebID than it is for our managed world, but it does bite us from time to time.

Yes. It is important to point out that this is a UI issue, because it could
be felt that it is something that needs to be addressed at the protocol layer.
Firefox does allow logout from JavaScript, but that is not satisfactory as it
should be in the chrome and not up the skills of the web site owner.

> - No feedback on expiry
> This oneís a huge deal. For reference, our certs for staff expire after 12 months, and those for third parties after 3 months (and thatís not going to change, as itís a failsafe against the various situations where revocation might fail to occur).
> Thereís no browser or OS-level indication that a certificate is due to expire soon, or has expired. When you do have an issuer, reminder e-mails have limited effect.
> When the certs have expired, browser-level responses are typically very opaque: either the cert just disappears from the selection list, or TLS negotiation fails with a meaningless (to the user) error.

Interesting. It would indeed be nice if the browser could alert the user 
that a certificate is about to expire. What would happen next? The user could
click on a button that finds the WebID in the SAN and leads the user to the 
WebID profile page to get a new certificate.

Otherwise in my use of WebID this is not a problem. Because the WebID profile
site is not one I use a WebID certificate to authenticate to. There one uses
a password. So presumably the WebID profile site is one I'd be often going
to, so the WebSite could just remind me when the certificate is about to
expire. In fact, any other friendly Web Site could do the same for me here, and
let me know that my cert is about to expire. :-)

So this does not seem to be a roadbocker to deployement of WebID. Ie. it does
not require one to change the browsers.

But perhaps we could create a document on Good Practices
for helping WebID Certificate deployers, and this could be one of them.

> - Multiple devices
> Transferring certs between devices is a huge pain, in part because the management UIs are buried deeply. To make matters worse, key material gets copied around, increasing the risk surface.
> I would much prefer (and this is applicable to WebID ó and Iíve talked about it in the past) a scheme where an end-userís cert is an *issuer* to time-limited, but easily-renewable, subsidiary client certs for each browser/device they use. However, this wonít be possible without fixing the issues with basic certificate user experience, so I donít have much hope in that changing any time soon.

Of course it one tries to transfer certificates to each device all the above points become 
extreemly problematic. But if one uses keygen to create the certificate for each device,
then this problem won't appear.

Why do you need to transfer a certificate between devices? Why not make a new one for each one?

I'd add another point: Browser isses do not affect non browser use of WebID+TLS, which may be
where WebID can be used much more broadly. Browsers have other issues at present such as Cors
which mean that it is not that easy to have a client fetch resources from anywhere on the web, 
and so force CORS proxies to be used. Though research there on how to deal with PUT, POST, 
PATCH using such proxies is ripe to be done.

> M.
>>> Any thoughts on how we could make it better?
>>> M.
>>>> On  2014-Nov-19, at 13:16, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>>> On 11/18/14 9:42 PM, Sandro Hawke wrote:
>>>>> On 11/12/2014 01:01 AM, Anders Rundgren wrote:
>>>>>> On 2014-11-12 05:36, Sandro Hawke wrote:
>>>>>>> On 11/10/2014 06:39 AM, Melvin Carvalho wrote:
>>>>>>>> Just wanted to highlight this interesting work from sandro
>>>>>>> Thanks.   I should say the design came out of discussions with Andrei Sambra,
>>>>>>> trying to avoid the problems with poor browser support of client certificates.
>>>>>> Sandro, that's a very interesting statement since the W3C is just about to launch
>>>>>> a continuation of WebCrypto which indeed may be focused on certificates and browsers!
>>>>> I'm just speaking for myself as a user and software developer; I'm not involved in that W3C work.  My feeling is the UX is terrible. My understanding is the only people who ever use it are people without a choice, like enterprise employees and university students.  What fraction of consumer websites use client certs for user authentication?   I've never seen one.   I think that's because the UX is so bad.
>>>>>     -- Sandro
>>>> Sandro,
>>>> If users are clueless about what they are doing, no amount of UX + UI will solve that. This issue isn't just about browser implementations, its about the combined effects of understanding (on the parts of users and app developers), UX, and UI.
>>>> Focusing on the "UI/UX is bad" narrative will not fix anything. Which is akin to the "RDF tools are bad" narrative.
>>>> Why don't we try a little harder in regards to exploiting the pinhole that TLS CCA offers? We've done that, and had success [1].
>>>> Users don't have a major problem with TLS CCA once they understand what's happening. Like many things (in my experience) its developers that are once again jumping to their own conclusions on behalf of end-users.
>>>> [1] http://youid.openlinksw.com -- Certificate Generator that produces Certs that make TLS CCA interactions easier to understand (New HTML version will soon be released) .
>>>> --
>>>> Regards,
>>>> Kingsley Idehen
>>>> Founder & CEO
>>>> OpenLink Software
>>>> Company Web: http://www.openlinksw.com
>>>> Personal Weblog 1: http://kidehen.blogspot.com
>>>> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
>>>> Twitter Profile: https://twitter.com/kidehen
>>>> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
>>>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>>> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
>>> --
>>> Mo McRoberts - Chief Technical Architect - Archives & Digital Public Space,
>>> Zone 2.12, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA.
>>> Inside the BBC? My movements this week: http://neva.li/where-is-mo
>> Social Web Architect
>> http://bblfish.net/
> -- 
> Mo McRoberts - Chief Technical Architect - Archives & Digital Public Space,
> Zone 2.12, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA.
> Inside the BBC? My movements this week: http://neva.li/where-is-mo

Social Web Architect
Received on Friday, 21 November 2014 11:59:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:50 UTC