Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 78 users
Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Sep 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature


Sign in to add a comment
User Interface Improvement for Client Certificate Usage
Reported by henry.st...@gmail.com, Dec 8 2009 Back to list
Client certificates allow a user to identify himself to a web site. In all
current browsers I know of it is very difficult for the user to know what
certificate he used to identify himself as on such web sites. Many browsers
choose to send a certificate automatically after the user selects it the
first time. The user cannot then change the certificate used, or log out. 

A very simple user interface improvement can help out here, and make the
web a much more secure place simultaneously, as it makes the usage of
client certificates much more widely available, and easy to understand.
This could be a very good comptetitive advantage for Chromium (until the
others copy it of course) :-)

So the solution is simple: In the URL bar browsers usually show the server
certificate information when connected using https. In the same location
the browser could show information about the client certificate used for
the web page (a GUI trick would be needed if more than one cert is required
for a web page to make that visibile to the user).

Firefox in their Weave project are showing the way. I wrote this up in
"Identity in the Browser, Firefox style" 
http://blogs.sun.com/bblfish/entry/identity_in_the_browser_firefox

Now they are trying to solve the whole password problem this way. But as I
argue in that blog a simpler solution to solve, and that would be
compatible with their more detailed solution, would be use the same UI
trick to make https client side certs visible. That would be immediately
useful, and does not require inventing any new standards.

 
Labels: -Restrict-View-SecurityTeam -Security -Pri-0 -Type-Bug -Area-Misc Area-BrowserUI Pri-3 Type-Feature
Please do not file feature requests as security bugs: the security bug template is only 
intended to be used for vulnerabilities.
Comment 2 by oritm@chromium.org, Dec 18 2009
Labels: -Area-BrowserUI Area-UI-Features
Area-UI-Features label replaces Area-BrowserUI label
where should I file the bug?

It is a security bug one could argue: to not have a good enough UI to help me know
when and where my certificates are being used. The reason it is not visible is that
few people do use client certs, and those are usually very knowledgeable people. So
there is not much to gain for crackers willing to attack themselves to this area.

Imagine for example that it was not obvious when you went to a web site if you were
connected securely or not. For example imagine that insecure web sites could get the
little padlock icon to appear easily. Then it would be a security bug, though one
that would lead people not to use server certificates at all, since it would be
obviously of little use.

That is the situation with client certificates today. A few user interface
improvements, would make the web a lot more secure. 

But this is an issue that crosses the boundaries of User Interface and security
people I agree. And those people I don't think meet that often :-)
So how can I get those two groups to talk ? Where should I post the bug?
Labels: -Area-UI-Features Area-UI
Comment 5 by snej@chromium.org, Mar 3 2010
>Many browsers
>choose to send a certificate automatically after the user selects it the
>first time. The user cannot then change the certificate used, or log out.

Mac Safari and Mac Chrome use the Keychain's 'identity preference' mechanism to track which client cert to use 
with which domain. It's not obvious, but there is a UI to manage these: in the Keychain Access utility app, they 
show up as items in the list. If you search for the domain in question, you'll see an "identity preference" item, 
which you can then double-click to edit, or delete.

I do agree that we should have in-browser UI to see which identity is being used and change it if desired.
snej said:
> I do agree that we should have in-browser UI to see which identity is being used and change it if desired.

Thanks. Below are just some additional points that should make it clear how important this in fact is.

So for foaf+ssl [1] - which is going to permitting very simple cloud computing sign on, see Tim Berner's Lee's 
recent presentation linked to from the wiki - it is very important that the user be able to choose the 
certificate. Furthermore this is required by the TLS 1.1 specification [2] which says in section 7.4.4 Certificate 
Request "

[[
certificate_authorities
         A list of the distinguished names of acceptable certificate
         authorities.  These distinguished names may specify a desired
         distinguished name for a root CA or for a subordinate CA; thus,
         this message can be used to describe both known roots and a
         desired authorization space.  If the certificate_authorities
         list is empty then the client MAY send any certificate of the
         appropriate ClientCertificateType, unless there is some
         external arrangement to the contrary.
]]

Each of Firefox, Opera and IE do prompt the user to choose a certificate.  (opera having in my opinion the best 
UserInterface - simple but one can dig deeper.)

( Safari has a bad problem  because it cannot deal with what is known as optional certificate requests, which 
makes for a very bad user interaction: if the user does not have the right certificate, the server must break the 
connection, which means the user does not even get an error page ) 

Snej said:
> It's not obvious, but there is a UI to manage these: in the Keychain Access utility app, they 
> show up as items in the list. If you search for the domain in question, you'll see an "identity 
> preference" item,  which you can then double-click to edit, or delete.

In the case of foaf+ssl the same certificate can be used on any web site. So not only is the above UI to 
do this anything but obvious, it furthermore and most importantly creates a restriction on certificate usage for 
which there is not justification: the server can specify what types of CA's he accepts, and the number of sites 
that accept this can grow. So the French state, and other EU countries are for example introducing certificate 
signing to allow people to fill in their taxes, and in order to interact with their citizens, or to help people in 
other transactions. Clearly new sites will be wanting to accept those governmentally issues Certificate 
Authorities all the time, and just as clearly the end user is not going to be wanting to twiddle with the keychain 
all the time :-)

Anyway as I specified on  issue 16831  you can use the following sites to test any fixes for what I would call  the 
bug part of this enhancement request: namely allowing users to choose their certificates, on each initial 
connection at the very least:
  
 - Choose one of the growing number of  foaf+SSL Identity Providers
           http://esw.w3.org/topic/foaf%2Bssl/IDP
  - Then login to one of the Relying Parties
           http://esw.w3.org/topic/foaf%2Bssl/RelyingParties

As the number of sites that accept your certificate will be growing constantly, it is clear that the keychain 
answer of specifying the servers that should accept a certificate is the wrong one.


[1] http://esw.w3.org/topic/foaf+ssl
[2] http://tools.ietf.org/html/rfc4346
Comment 7 by snej@chromium.org, Mar 4 2010
Henry — any comment on  issue 37314  that I recently filed, in which I suggest that Chrome should persistently 
remember which cert you use to authenticate to a particular domain, and use it without prompting from then on? 
I filed this to match Safari's behavior, and because it seems awkward for Chrome to keep bringing up the modal 
choose-identity panel on every launch, but you seem to be arguing against that behavior above.

I still agree with you about having an identity selector widget somewhere like the address bar, but that's a UI 
decision out of my control, so I don't know if/when we'll get that.
Comment 8 Deleted
snej, yes, I don't think that's a nice solution. It makes logging into a site with a different certificate impossible 
without closing down the browser (or do you want to make it even more permanent than that?)  - and I know 
that sometimes I have 50 tabs open.  Also people sometimes choose the wrong  certificate, and then they can't 
change their identity. 

Firefox asks you again when you start a new browser session. 
Opera also I think. Opera is good at least because if for some reason the user mistakenly clicks the ignore 
certificate button and the server later asks again (perhaps because the user refreshes, then he gets asked 
again) In opera also if the certificate is refused by the server the user can choose one again. That is also 
important.

There are other places you could put this button perhaps initially in a first version... The nice thing is that such 
a 
button solves  issue 37314 , because you don't need to pop up the certificate all the time, but you also give the 
user the choice of changing. 
Comment 10 by snej@chromium.org, Mar 17 2010
Status: Started
I've been hacking together a quick prototype of this UI. So far I've got a roundrect in the address bar (right-
justified, to the left of the SSL indicator) that shows the CommonName of the subject of the client cert being 
used. The tooltip has some explanatory text and also shows the name of the issuer. Kind of ugly and limited but 
it's a start.
(There was some negative reaction here to having the indicator left-justified, as in the FIrefox mockup you linked 
to, so I went with the right side for now. Plus, it's easier to implement that way. All of this is just experimental.)
I'll post a screenshot once I'm back at my work machine.
Comment 11 by snej@chromium.org, Mar 17 2010
Here's a screenshot. Again: this is just something I threw together on my own and has had no input from Chrome 
UI designers, etc. etc.
Picture 1.png
120 KB View Download
That's exactly right! This will break serious new ground, and offer so many opportunities to improve security. I 
can't tell you how exited I am. 

I'll need to get my blogging software together, and do my web site properly, for a major blog post when that is 
released :-)
Although the side comment to this textbox states"Each comment triggers notification
emails. So, please do not post '+1 Me too'".Instead, click the star icon. ",

I must state +1 Me too! I do not believe this bug/feature is an option. Any browser
that does not provide a means to mange identity sufficiently is flawed. It is
inevitable that identity management is becoming more client side with the advent of
decentralized social networking. As we become more decentralized, "social networking"
is turning more and more into "internet"
Comment 14 Deleted
Comment 15 by presb...@gmail.com, Mar 20 2010
Looking good. Can't wait to try it pull a build down and try it!

Can you add a mouse-over popup, pane, or other easy way to view more details? I
suggest including:
- Issuer, if not self-signed
- Validity start and end
- Full subject, eg. Subject: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd
- X509v3 extensions: basic constraints, subject alternate name, comment
@presbrey wrote:
> Can you add a mouse-over popup, pane, or other easy way to view more details? I

I think that is a good idea. But one should be very careful about not putting  geeky detail in there. The Firefox User Interface is absolutely 
horrendous. It gets to be really silly when that then ends up in a cell phone. 
See my post on mozilla's Fennec for more on that [0]

> suggest including:
> - Issuer, if not self-signed
> - Validity start and end 
> - Full subject, eg. Subject: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd

I think that could be in a advanced view. Perhaps a 'button' in the pop down that when pressed could gives detailed certificate details. But the 
above could just turn people off. 

> - X509v3 extensions: basic constraints, subject alternate name, comment

Certainly only in an advanced section. 

I think you will find that Opera does a good job of that in the certificate selection popup. It has a button for detailed view. 

The other thing to remember about a lot of these details, as Dan Kaminsky makes clear in his talks [1], is that most of them are ignored by the 
whole CA system. They were meant for an architecture that never came to be! So it is not even clear if they are useful! Showing people cryptic 
information that is not useful is worse than misleading, it is doubly offputting :-)

But I think I should mention where I think this could lead to, and that could be even more interesting, though certainly not something that @snej 
could put into the first release. This would be for the browser to GET the WebId and display things from the foaf [2] such as

 - a picture of the the person using foaf:img or foaf:depiction
 - his name from foaf:name, or his nickname

This would give the user a direct feel to how he is related to the his profile. If he changes his profile icon, his image could change in Chrome too...

Now some things the browser could keep track of for a webid, are:
 - was the certificate downloaded over ssl in a keygen request - If not, it should warn the user to make clear the WebId and other details are 
correct - and this could be done in a color coded fashion
 - is it an http web id ( that would be less safe, due to potential man in the middle attacks between a server and the the profile page)
 - yes, is it about to expire? - something a certificate selection box could warn the user of

I have full confidence that @snej who I believe has worked at Apple would know how to keep the user interface clean. That is one of the great 
values of Steve Jobs user interface discipline - even if with respect to client certificates (in Safari) they seem to have failed by going too far - ie by 
removing the essential feedback with the user that is so important.

Henry

[0]  http://blogs.sun.com/bblfish/entry/foaf_ssl_in_mozilla_s
[1] I think he does in the HAR one that I link to from here http://foaf.markmail.org/thread/6mavqww3d6oii4dt 
[2] http://xmlns.com/foaf/spec/

Comment 17 by presb...@gmail.com, Mar 20 2010
I now reread snej's "Kind of ugly and limited" comment to mean he was already heading
this direction.

More precisely, my opinion is that issuer and expiration are not geeky enough to hide
deep vs. the ambiguity of subject CN alone, and irregular x509v3 extensions such as
subjAltName (while arguably "geeky") should be shown because CAs aren't using them
when they don't matter.

Of course, the ability to break SSL sessions and change certs with a left- or
right-click alone will have me moving my SSL browsing from Firefox!
ambiguous-cert-CNs.png
19.1 KB View Download
Comment 18 by snej@chromium.org, Mar 22 2010
btw, I am rewriting http://foafssl.org/srv/idp - which a few of the foaf+ssl demos are using, such as http://foaf.me/  - as it is 
very clearly an anti pattern for the issue in question here. I think it is the only site doing this. It seemed clever at the time but it 
is a big mistake. 

The problem with foafssl.org is that it does authentication on https but the user never lands on that page. He is immediately 
redirected back to the service he came from. So an improvement to the browser such as the one being worked on here would 
never give the browser the opportunity to show the user which client key he had been using. As the user does not know which 
service he connected to, he cannot logout of it either, nor can he change his persona. I am refactoring the code on 
http://github.com/bblfish/foafssl-java so that the user then lands on the page where he can choose or not to login, etc...

So please in developing this don't try to accomodate the current foafssl.org. I should have a new version out this week hopefully.
@henry.story
> But I think I should mention where I think this could lead to, and that could be 
> even more interesting, though certainly not something that @snej 
> could put into the first release. This would be for the browser to GET the WebId 
> and display things from the foaf [2] such as
>
> - a picture of the the person using foaf:img or foaf:depiction
> - his name from foaf:name, or his nickname
>

Alternatively, one might consider the subject logotype defined in RFC 3709 [1] or the
ongoing work with certimage [2] to be a more generic solution that is not directly
coupled to the implementation details of foaf+ssl. certimage is specifically designed
to provide a human-usable means to selecting a certificate when authenticating with
an IdP.

[1] http://www.ietf.org/rfc/rfc3709.txt
[2] http://tools.ietf.org/html/draft-ietf-pkix-certimage-06

I asked about this issue on the TLS mailing list and got a response by Martin Rex [1], who is acknowledged in RFC  5746 [2] to 
have independently found the TLS renegotiation security hole that shook the TLS world recently and for which I opened issue 
38082 .

Very noteworthy for this thread is his comment:
[[
That browsers show only the servers identity when you check the
security settings for a page, but not the information whether
a client cert was requested, which client cert was used, if any,
should be considered a defect of pretty much all browsers.
A possibility to visualize the list of trusted CAs, which a server
announced when requesting a client certificate, would also be
nice...
]]

Hope this helps.

[1] http://www.ietf.org/mail-archive/web/tls/current/msg05917.html
[2] http://tools.ietf.org/html/rfc5746
Comment 22 by snej@chromium.org, Mar 24 2010
I've got a pop-up working now, that appears when you click on the client-identity bubble. It doesn't actually do 
anything yet, though (for that I'll need to add some downward plumbing to tell the SSL code to reopen the 
connection with a different cert.)
The pop-up obviously shouldn't grow this wide. This is just a prototype, etc. etc.
Picture 1.png
128 KB View Download
very nice ! 
IMO, offering users a means of easily changing their client certificates and verifying those certificates within 
browsers is key for privacy control, security, and facilitating federated identity management across the Web.
Comment 25 by webl...@gmail.com, Apr 1 2010
Very neat ideas here - getting secure identity both more deeply embedded in the browser 
and yet easily manageable via a UX is a difficult problem but i'd love to see this in a 
Chrome release. Often thought OpenID in the browser would make it far easier to use - 
this approach could be huge in leveraging that.
Comment 26 by Deleted ...@, Apr 1 2010
As the number of certificates that a user has grows larger and larger, then he will
need the equivalent functionality of today's un/pw login feature, in which the fields
are automatically populated (from pw manager) with the best choice, and the user can
then either click OK or choose a different combination. So it should be with SSL
client authentication - the user should be shown the certificate chosen by the
browser and the user can either click OK to proceed, or select a different
certificate from a picking list and then proceed.
Over on the Firefox side  Kai Engert just left an interesting note in the longstanding issue 396441 [1] "Improve 
SSL client-authentication UI"

[[
I had announced the following proposal in the mozilla.dev.tech.crypto newsgroup
2 weeks ago:

http://kuix.de/mozilla/sslauth/
]] 

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=396441
Comment 28 by snej@chromium.org, Apr 1 2010
Re.#26: Actually client certs already work that way in the Mac version of Chrome (I implemented it a month or so 
ago, but it hasn't been ported to the other OS's yet.) Chrome pops up a dialog box with a list of your valid client 
certs and lets you choose which one to use. If you've been to this site in the past, the cert you used last is pre-
selected. You only get prompted this way once per browsing session, and afterwards it'll continue to use the 
same cert.
The improvement discussed here is (a) displaying an indicator of which cert you're using, and (b) the ability to 
switch to a different cert without having to quit the browser.
Hi, how is this progressing? I think this is the only serious client cert issue remaining.
I just thought of the final piece that would completely nail the User Interface. I am not 100% sure but I thought it would be worth writing down here.

Let us imagine a future secure web where everything is behind https. (Why not? it's cheap now!) So some friend sends you an https link to content on some site. You arrive at the site and the server is set up for optional client certificate usage. Bang! Up pops your browser asking you to select a certificate. 

Problem: you don't yet know which site you have arrived on! And it is asking you for a certificate. So really what you want to do is click "Cancel" to first check out  the site. But then without this patch that @snej is working on, you won't be able to login to the site later to see the classified content - well not without restarting your browser!

So one could even go one step further and allow you, the browser user, to select an option that would let the browser automatically login without certificate on sites that ask for certificates optionally. The location bar would then show a logo for the anonymous user - An icon of a guy with sunglasses perhaps, with anonymous written next to it - that would be a hint to you that you can log in whenever you wants to by selecting the button.

If done correctly the certificate selection box, could be designed so that the user understands after that box appearing a few times too often, how he can set this behaviour to be automatically so.

This would essentially then have fully integrated identity into the browser at very little cost.
+1 for seeing how its progressing.
Comment 32 by csar...@gmail.com, Sep 3 2010
+1 to Jens' comment re: "The improvement discussed here is (a) displaying an indicator of which cert you're using, and (b) the ability to switch to a different cert without having to quit the browser." at http://code.google.com/p/chromium/issues/detail?id=29784#c28

and

+1 to Henry's comment re: letting the "browser automatically login without certificate on sites that ask for certificates optionally" at http://code.google.com/p/chromium/issues/detail?id=29784#c30
Labels: Feature-Omnibox
adding another feature label, since this seems to affect the omnibox
Labels: UI-Needed
Status: Available
Jens is no longer at Google, and I assume not actively working on this.

Needs UI team input.

Personally I think this is edge-casey.  Having a coherent story on how the user authenticates himself to the browser, and then how the browser authenticates to websites, as a whole picture seems more critical.
>Personally I think this is edge-casey.  Having a coherent story on how the user authenticates himself to the 
> browser, and then how the browser authenticates to websites, as a whole picture seems more critical.

There is a lot of info on that. For the video highlights see my home page http://bblfish.net/
In particular "WebID creation and use in 4 minutes" http://www.youtube.com/watch?v=S4dlMTZhUDc

Creating a certificate is easy using keygen, an element that is now in HTML5. Authenticating to websites with SSL is understood: it is just that this UI issue needs to be solved if you want to smooth adoption.

The main reason why Client Side certificates have not been adopted is because they were expensive to make when CAs were in the loop. But CA's are no longer needed with WebID http://esw.w3.orf/foaf+ssl

Furthermore CA's will no longer be needed with DNSSEC. (See the FAQ)

Does that help you get a coherent story?

No, because I wasn't talking about what certs are or how they're created and used.  I was talking about the overall UX of how a person is represented to their browser and what the browser uses that information for.
> No, because I wasn't talking about what certs are or how they're created and used.  I was talking about 
> the  overall UX of how a person is represented to their browser and what the browser uses that
> information for.

You are packing a lot in that short sentence. 

The way people should authenticate to their browser is by logging into their operating system. All modern OSes now allow each user to have his own account and use the keychain. OSX even allows you to create guest accounts that get purged after logout automatically. All devices do pretty much the same: you log into your device and then you don't have authentication issues anymore from there on. 

One can then make logging in even more secure by using Hardware tokens as shown here
http://esw.w3.org/Foaf%2Bssl/Clients#Hardware_security

And that would be something that would be worth supporting. But my guess is that is less of a priority than allowing people to log out, or choose their identity on a site. 

TEST CASE: Try putting up a site that is all behind HTTPS and give yourself a number of certificates. Then just try using that site: you want to parse it without logging in, you want to log in, change certificate and then log out. You can't do that currently. That is a easy to understand bug.


Unfortunately, using OS user accounts is suboptimal, both because people don't use them, and because people have multiple distinct online identities (part of the issue that this bug covers).

That's why this bug is a small piece of a much bigger picture.
pkasting: To separate a little from what henry.story is describing, I think there are two changes that could be implemented in satisfying this request that do represent real UX issues and are perhaps not as complex as they may seem.

The first is, when authenticating with a client certificate, present this information in the infobubble. Already today, the server's identity is presented in this information, obtained from the underlying SSLClientSocket and bubbled up appropriately. In my mind, this would be a separate section, appearing after the SSL encryption information and before the "Site information" section. 

The second, this section could include a simple textual link to "Change client certificate". As henry.story has described, there is no way today to change your identity certificate, short of restarting the browser. This is because the client certificate+hostname pair is stored in the SSLClientAuthCache, which is always consulted before prompting the user. Until the server sends a specially crafted TLS alert (which is not something exposed for many popular web servers, mod_ssl+apache included), Chrome will not retire that association/remove it from the cache. In terms of the TLS protocol, there is no reason to require the server explicitly send a special alert or force renegotiation - the user should be able to select a new certificate at any time and renegotiate with the server. If the user chooses to "Change client certificate", they're presented with the same dialog they were originally presented when the request for a client certificate was received. They can also choose to use NO certificate, reverting back to an "anonymous" state.

The best parallel I can describe for this second situation is like deleting your cookie for a given hostname, so that you're forced to re-log in. While the semantics of the server providing a "Log out" button and using a Set-Cookie to invalidate a session cookie are well understood, doing so for an SSL/TLS authenticated session from the server side isn't, which is where this feature request could address.

Both of these are reasonable and possible, and from what I understand, were what Jens was working on. I've picked up some parts of this, specifically with the intent to implement support for the above the above two scenarios. I realize that there's a UI component to this, and what I'm proposing might not be the best means to address this particular problem, but hopefully it provides better perspective into the utility of what's being proposed.

I know there are complexities I'm glossing over, such as what happens when you have mixed domains in the main frame, which is already an issue with the info bubble AFAIK, so I'm not trying to oversimplify - just present a picture of the problem and a possible solution.
You should get in touch with finnur and the UI leads about the bubble stuff.
Every issue is always linked to a large number of other issues, I won't deny that :-) If we put aside that people don't yet understand the value of user accounts, which is an educational issue (and so should be solved by educating them) we have this point of yours

> because people have multiple distinct online identities (part of the issue that this bug covers).

Yes, that is what you can use different certificates for. Each certificate can represent one of your online identities. 

Now if the question is how do you make it clearer to the user which online identity he is using, I can start proposing a few very nice ideas, but I think they should wait for the WebID protocol to be standardised at the W3C http://webid.info/spec/

One very nice thing one can do, when people start working with this, is that the browser can then use the information at the WebID to style the user experience. Here are some ideas:
* An icon for displaying in the URL bar, just as amazon has its icon, and google could have its own
* A picture of the user so that when he does use some larger selection mechanism, something like a card chooser perhaps, the browser can fetch that image from the web
* nickname, so he can use that to distinguish his various identities
* Address information (which the browser can make use of for other reasons)
*...

Now the above is a big project, which I'd be happy to help out with. But I think one should move in small steps. Of course if you want to try to be consistent with such future possibilities without implementing them, then allow your imagination as much freedom as you want. Having a WebID in the certificate means that you can get any information you like from the web to make certificate selection or browser experience nice to use.... That is technically easy to do: the problem will be getting relations that get consensus - which is part of the sociology of engineering - and if you show value for this then I think this won't be a big issue.





Blockedon: 65544 65545 65546 65548 65549
Just an extra idea: for certificates in which the WebID if placed in the Subject Alternative Name of the Certificate - which hopefully will be a lot more when the WebID Incubator Group at the W3C gets going (http://bit.ly/b3Dcwb if you want your org on the list please contact Michael) then we can also solve the problem of helping the user find his home page without having to remember a URL! 

  Simply: in the client cert selection mechanism of the URL bar you allow a user gesture (double click, or single click on a part of the UI that highlights on mouseover somehow, or whatever) that will bring the user to the WebID page, which should be his home page. From there he can change his profile picture, add new friends, contacts etc.... So imagine he is looking at someone's blog and wants to post a comment:

  1. He logs in by selecting a certificate of his choice
  2. He can post the comment
  3. He sees the foaf file icon of the user on that page (or whatever in the end the adopted standard is)
  4. clicks on his certificate which opens his home page in a new window 
  5. drags and drops the foaf icon on his friending box. (HTML5 allows drag and drop between apps and web pages)

  I  Just thought it can be useful when thinking of UI designs to imagine some use cases. 
Btw, while I am writing this, you may be interested in the talk "Philosophy and the Social Web" that I gave in Paris last month. It's a bit long but covers pretty much all my work over the past 4-5 years. So when you are on a plane flight download the audio and one of the slide formats 
   http://bblfish.net/tmp/2010/10/26/


A quick note to people following this bug report. The W3C has started a WebID Incubator Group at http://tinyurl.com/webidxg . If you are reading this then you are probably an expert and are invited to join as invited expert by following the procedure described here  http://www.w3.org/2004/08/invexp.html .
In short:

 1. you create an account at the W3C
 2. you ask for invited expert status on WebID XG
Labels: -UI-Needed bulkmove Review-UI
Client certificates allow a user to identify himself to a web site. In all
current browsers I know of it is very difficult for the user to know what
certificate he used to identify himself as on such web sites. Many browsers
choose to send a certificate automatically after the user selects it the
first time. The user cannot then change the certificate used, or log out. 

A very simple user interface improvement can help out here, and make the
web a much more secure place simultaneously, as it makes the usage of
client certificates much more widely available, and easy to understand.
This could be a very good comptetitive advantage for Chromium (until the
others copy it of course) :-)

So the solution is simple: In the URL bar browsers usually show the server
certificate information when connected using https. In the same location
the browser could show information about the client certificate used for
the web page (a GUI trick would be needed if more than one cert is required
for a web page to make that visibile to the user).

Firefox in their Weave project are showing the way. I wrote this up in
"Identity in the Browser, Firefox style" 
http://blogs.sun.com/bblfish/entry/identity_in_the_browser_firefox

Now they are trying to solve the whole password problem this way. But as I
argue in that blog a simpler solution to solve, and that would be
compatible with their more detailed solution, would be use the same UI
trick to make https client side certs visible. That would be immediately
useful, and does not require inventing any new standards.
Cc: rsleevi@chromium.org
Labels: -Review-UI
Owner: nepper@chromium.org
hey Patrick, can you consider / think about this as part of the page info bubble work?
Just as a matter of interest, for those following in this issue, we just submitted a paper that was accepted for the Identity in the Browser Workshop that is taking place this month in Silicon Valley http://bblfish.net/tmp/2011/04/26/  The paper is called "The WebID Protocol & Browsers" . Perhaps that  can help sumarise this thread in a more readable format, for those new to it.
And now a short 10 minute video with demos and explanation http://www.youtube.com/watch?v=rnoRQZCL9I4

(btw, I had to cheat in that video, as there is a bug in Chrome (on OSX at least) I just discovered: if you click on a WebID in the certificate selection box it does not deal correctly with the #tags. It encodes the hash tag and gives you the wrong url) 
I opened up  issue 90676  which is about getting javascript crypt api to work. That could be a good way to get some of the functionality required by this issue working faster.  This issue is the right solution in the end, as it puts the user and browser in control of privacy.
Comment 51 by xerc...@gmail.com, Oct 6 2011
"me too"

Is there at least some hidden way to "logout" from a certificate login?
I want to reconnect using a different certificate.
Comment 52 by Deleted ...@, Oct 10 2011
I want to protect my accounts from Hackers. And also protect my idenity from being stolen. Your Friend from Facebook Adam Matthew Chandler.
There is a hidden way to logout from Firefox and I think Internet Explorer. See the  issue 90676  which was closed because that javascript method is not standardised. One should perhaps go to the HTML 5 Working Group and ask them to add a javascript logout feature. I suppose they may end up coming to the conclusion that something like this issue is the correct fix. 

Hi, about UI improvements, what about considering what is proposed on last comments of http://code.google.com/p/chromium/issues/detail?id=19789 ?
Having an automatic selection of a client certificat based upon user defined authorized urls does not expose users to the "danish" privacy issue described in the issue.

It is actually blocking some users to switch to Chrome because they select again and again the same cert within the same urls, especially intranets with certificat authentification. Having an automatically selected certificate seems really the right behaviour here.
Comment 55 by velo...@gmail.com, Aug 15 2012
This is still a blocking issue when attempting to use Chrome in any secure workplace that uses client certificates.

What is the current status of this bug?  I can see that it's listed as 'Available' but that doesn't give any information regarding it's 'place in line.'
Comment 56 by Deleted ...@, Jan 26 2013
It would be really great if this feature could be implemented.
We use the client certificate to authenticate the user in the intranet and its a little bit annoying if the user has to select the same certificate again and again and again.
Blocking on 65545 should be removed. There is no need to validate the client cert on the client side in order to report which client cert was sent to the server.

It might be useful to no longer offer already expired client certificates, but that is a separate improvement and should not impede the much needed UI changes proposed by this bug.

Users of client certs need 1) to see and indication that the cert was used or not sent 2) the ability to view the full details of that certificate (advanced viewer, bubble, etc.) and 3) a way to change the choice of sending a certificate or not and which certificate to use without requiring the user to exit the browser.
Project Member Comment 58 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-UI -Feature-Omnibox Cr-UI-Browser-Omnibox Cr-UI
Comment 59 by rot...@gmail.com, May 13 2013
Currently, to work around this issue, one can use different browser profiles or incognito mode, which, of course, is not ideal, but works until a proper UI is implemented.
Comment 60 by f...@chromium.org, Jul 23 2013
Cc: f...@chromium.org
I hope this happens.  Client certificates seem like a really nice way to do authentication if you own the computer that knows the private key.

To make this viable for website authors to use, you only really need to add one feature:
 - Ability to "log out" of an ssl session without closing your web browser.  (assuming that 'no client certificate sent' also constitutes a session that can be 'logged out' of)

It could continue to work exactly as it currently does in all other respects.  It'd just be nice to be able to get that certificate selector to show up again on demand somehow, with None as an option.

Btw, have you noticed the similarities between client certificate sessions and cookies?  Both are invisible to the user, but identify them to the server.  Both are sent to only specific sites (though the rules differ here) and both can be deleted when the browser closes.  However, cookies can be deleted at the server's request, while ssl sessions...  I guess they can be terminated by apache tomcat 7 servers only?

Perhaps this should be a feature request of web servers, if they are indeed capable of "logging out" of ssl sessions.
IMHO, there's no problem to fix because it can't be solved just by tweaking the UI:
http://webpki.org/papers/PKI/webauth.pdf
@andersph...

Why can't it be solved with the UI?

If you're using curl, you can switch certs at any time just by passing a different --cert argument.  Is it so different for web browsers?
Hi nickreta...

In the document I provided a link to, there's an extensive list of down-sides with HTTPS CCA (Client Certificate Authentication).  Newer stuff like FIDO doesn't build on transport level authentication and this is where Google and Microsoft are going.

I still believe in client-side PKI but using techniques that are similar to FIDO.
Hi Anders, the counter arguments to client PKI are all ones that can easily be fixed, by exactly this bug report. Let me look at them one by one:

• "HTTPS CCA (Client Certificate Authentication) is incompatible with the traditional web session model since TLS sessions run independently of web sessions". This point is being addresssed by TLSv3 and SPEEDY, and for that there is a way to get TLS client certificates to work correctly with them as written up here
http://martinthomson.github.io/drafts/draft-thomson-httpbis-cant.html
This does require TLSv1.3 to be out, so I think in the mean time one could solve quite a number of bugs mentioned here.

• "TLS lacks a logout mechanism" - it does not really. It just requires the chrome to give the user a button to choose not to continue using an session. That is exactly what this bug report is about. You'd have this whatever technology you use: you have to give the user the ability in the chrome to choose what identity he wishes to use for a session.

• "Currently there is no support for TLS session management in for example Java Servlets." 
Java Servlets are pretty bad technology to make a point about this type of functionality. At present renegotiation of a session to get the browser to ask for a new certificate is tricky on the server, but it is possible. But it is easy to see that with martin-thomson's draft httpbis cant all the server would need to do is to return an HTTP 401 code with a "WWW-Authenticate: ClientCertificate realm="home",  sha-256=NjUwZjA0Mzcy..., sha-256=MzJiMTQ3ODF..." header, which is clearly something even a servlet can do. 


• Confusing behavior if the user wants to select another certificate. It usually requires you to shutdown the browser due to TLS session “stickiness”

that is just because the user has no User Interface method to change his authentication. It is partly solved by Chrome's Persona, but that still fails to give the user the low level capability.

• "Limited and non standardized certificate filtering capabilities leave consumers with difficult selection choices". It is limited true but doable. As you can imagine it will be easy with draft-cant to add a header to be more specific about certificate types to HTTP.


Hi Henry,
We disagree on this and I think we both have reasonable arguments.
Therefore it is really up to Google et al to decide which path they find most usable.

The most likely action is leaving things in the state they are currently in since there are no major customers out there asking for improvements in any way.

One thing that may indeed change the picture is the "outlawing" of browser-plugins which effectively leaves millions of users of client-side PKI without a working client-solution.  If the following activity pans out

http://www.w3.org/2012/webcrypto/webcrypto-next-workshop

I'm sure it will affect login as well.  I was there BTW!
Comment 67 by laforge@google.com, Apr 28 2015
Cc: -wtc@chromium.org
Owner: sabineb@chromium.org
Status: Untriaged
Status: WontFix
Comment 70 by asher...@gmail.com, Sep 17 2015
a 75-star, 6-year-old issue suddenly WontFix'd without comment? This is a shame.
This is an old bug, which has not seen any activity or new information.

There are no plans for this. It is technologically unsound. This was decided in 2011, and we just never closed this out.
Naive question: does the fix for  issue 450167  allow for an extension to workaround this bug?
Comment 73 Deleted
Actually there has been a lot of debate around this on various threads on the internet which need to be related:

• starting with the proposed deprecation of <keygen> 
  https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack%5B101-125%5D
• leading to a change to HTML5 by whatwg 
   https://github.com/whatwg/html/issues/67
• Discussion on the TAG on keygen and on certificate UI
 https://lists.w3.org/Archives/Public/www-tag/2015Sep/
   for the certificate UI discussion see this recent post by Tim Berners Lee today
  https://lists.w3.org/Archives/Public/www-tag/2015Sep/0067.html
   ( And Ryan's response )
• and on Public-webappsec the discussion on SOP, ans user control, which explores issues of user control ( and so UI )
  https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/
Henry: None of this is new information; indeed, much of what is said on those thread is restating the stuff presented here. I appreciate your enthusiasm for this, but I do hope it's clear that your suggested fixes - and the fundamental use cases - are not ones that are possible nor planned to be supported. Please don't make it necessary to restrict this bug.

And no,  Issue 450167  does not have any bearing to this request or issue.
Ryan you wrote "This is an old bug, which has not seen any activity or new information." I was just pointing out that it has seen activity, just not in this thread. Whether new information has been put forward is you have to admit a bit difficult to assess, given the discussion had, the change of circumstances, and the beginning of a discussion in the TAG with Tim today. The discussion there is not finished. How do you know he does not have new information to bring to the table there, or that new avenues may not be available? Why close the issue in the middle of a discussion? 

Cc: -hbridge@google.com
Sign in to add a comment