Thanks for the report. Since this is a functional bug, I'm removing it from the security queue.

rsesek@ - any thoughts?

Wrong CC? It's a known issue right now (and there's a CL in review to fix) - due to some changes in Security.framework APIs to no longer return the full set of client certs (which is strange and not something we've been able to repro, but has reports of working for users of PIV CryptoTokenKit cards + ECDSA keys)

Fixing labels.

Seems it is out of scope from TE end as it is related to smart card certificates, adding TE-NeedsTraige-help label to move this out of our triaging bucket.

Could someone from dev team please take a look into this issue.
Thanks..!

Just tried with google chrome canary (67.0.3371.0)64-bit on 10.13.4, and not getting a certificate selection.

Turned out this issue was due to padding characters in the certificate file.
(Some of our certificates get padding bytes attached to have a predefined file size (in order to reserve some space on the smart card for replacement certificates that might be larger)).

Safari probably uses the ASN.1 info in the certificate file to determine the correct length of the actual certificate, while google chrome might not do this.

In any case we now remove these padding bytes in our ctkToken and the certificates are picked up by google chrome on macOS 10.13, so authenticating with our smart cards is working as intended

Thanks for clarifying.

I'm afraid I need to come back on this.
Turns out the reason we had it working on our test machines was not the padding fix, but the fact that we added the intermediate and rootCA certificates of the inserted token to the apple keychain (using Keychain Access).

So the main cause of this issue appears to be that Google Chrome is not fetching the intermediate and rootCA certificates from the CTK token's keychain contents (it does fetches the leaf certificates from there).

We noticed the same behaviour on Chrome OS, so this behaviour is probably intentional, but would it be possible to use the other certificates in the CTK token's keychain to build a chain up to a root that was requested by the authentication server? 
No need to store or trust these certificates, just use them to check if the auth cert on the CTK Token can be used to authenticate on the server.

Thanks for the update. As you suspected, this is an intentional design choice. Filtering identities on the client side, based on server parameters, can have a host of undesirable side-effects, and we've chosen not to support it.

Thank you for your explanation.
Though I'm not sure that I understand the reason for not including the certs on the smart card (that have been placed in the CTK token's keychain) when building chains (or at least when building chains for the leaf certificates in that CTK token keychain).

As the filtering you mentioned does takes place when the CA and rootCA certificates are present in the apple keystore (Keychain Access). It appears to be just that some of the new CTK token's keychain contents are not taking into account.

Would using these CA's on the token's keychain just for creating chains for the leaf certificates that are also on that same token's keychain be an option you could concider?

OOI, what are those "undesirable side-effects"? That's not clear to me.

Meanwhile, there is another undesirable side-effect: when trying to authenticate a user using a country-wide PKI infrastructure, which necessarily has large swaths of intermediate certificates; in our case, we expect to need somewhere in the vicinity of 600 certificates in a while. At approximately 85 bytes for the distinguished name, this is an overhead of about 50k per authentication request.

I'm not saying that's an unsurmountable problem, but it might be useful to consider all such issues...

Sure, and the server can easily address this by not populating the distinguished_names field in the CertificateRequest. If a server is confident enough that the client will have the intermediates - whether it's making assumptions about the given smart card or making assumptions about the client middleware - it can also be confident enough that, in the absence of the distinguished_names, the user will still be given a certificate to select.