+Ryan, as we will be discussing this soon.
+Sushmit, +John for some perspective from the GMail - S/MIME side.

I'm... mixed about this.

We previously had such filtering, and it broke a number of use cases. I totally understand the arguments, but in the real world, client certs' are outside of our control and ability to influence. It's a choice between showing too many or too few, and right now, better to allow the user to sort it out than not allow them to continue. For this reason, it's explicitly NOT something we can do in general for Chrome, and because of that, I'm NOT terribly fond of doing it just for ChromeOS.

It's extremely user unfriendly as it is now since it's only used for TLS and for DOD/USG users there are more certificates than are permitted to be used for TLS by X.509v3's specification of the relevant extensions so most TLS server implementations don't just reject the certificate but tear down the TLS session with a more specific and confusing error related to improper usage.

This filtering is already done on ChromeOS for certificates the user imports since NSS does this filtering (IIRC -- definitely the user is only presented with certs that can be used for TLS Client Certificates) so it's inconsistent if the filtering is not done for chrome.certificateProvider.

If chrome doesn't do the filtering my certificate provider will have to because otherwise users will be given the choice that can never legitimately work AND that they are not presented with on any other platform (Internet Explorer on Microsoft Windows presents a logon cert as a client cert when it may be incorrect to do so, but that's the only variation I'm aware of).

I don't have the history that Ryan mentions so I am not opinionated either way. We will need to solve this for sure because the user experience is just super confusing, the question is where should the fix be?


Option A
Filter the list in Chrome. Chrome gets a list of certificates and will know what to show when. In this case, middleware vendors have to query the card for all certificates on it. This is more future proof as Chrome adds support for other certificate based functionality (S/MIME?) and makes it much easier to write middleware code.


Option B
Filter it in the middleware app. Chrome shows whatever it gets (current behavior). I am not sure what the implications are for middleware vendors when it comes to new functionality? For example, if we now want to support e-mail signatures, how would the chrome.certificateProvider need to be adapted so that it now exposes a different set of certificates for the system? Would we add a new method to chrome.certificateProvider.onEmailCertificatesRequested?



It would be great if we can make a call on this. Option A is very tempting but I lack any of the history of how this broke in the past. The last thing we want to do is put it again and realize it breaks things and then rip it back out..

Option A does not reliably work cross-platform, nor does it reliably work across smartcard deployments. It relies on assumptions of both that in the real world are not borne out.

Option B is the far more sensible solution, and yes, will require changes to the chrome.certificateProvider API. This is far more sensible and scalable, even if it does not immediately seem as such, because it puts the onus of dealing with these various smartcard configurations onto the smartcard middleware, and entirely avoids the cross-platform issues.

Option A works reliably, but it may do the right thing (not provide certificates that the X.509v3 RFC says shouldn't be provided) when you want the wrong thing done (provide certificates that the X.509v3 RFC says shouldn't be provided).

The only time I've seen this happen in the real world is Microsoft Internet Explorer and Microsoft IIS.   MSIE will provide certificates that lack the X.509v3 extendedKeyUsage id-kp-clientAuth if they have a different extension (which I would have to look up).  And Microsoft IIS will accept that certificate.

This causes problems for everyone else since they are unaware of this behavior on BOTH sides -- it causes problems for MSIE because it will present certificates that non-MS-IIS servers will reject as not-applicable and it causes problems for non-MSIE since they will not present the non-compliant X.509v3 certificates that IIS would accept...

However, there's no way for the middleware to know any better that Chrome what is appropriate.

Is there any reason not to go with Option C and implement the filtering in the chrome.certificateProvider code?  It would seem to me that this neatly keeps the 'aberrant' behavior isolated to ChromeOS, while retaining paired functionality with how most of the Chrome platforms behave [i.e. my OSX and Windows systems do this; as Roy notes, soft certs in ChromeOS do this].

Supporting the 'weird' use case of wanting to allow the user to see inappropriate certificates would simply be a matter then of adding a checkbox to the extensions screen to remove filtration.

Of course, if there's long-term thinking of opening the API up on other platforms, this becomes less practical.