Query per-key/provider capabilities where possible in ssl_platform_key_*.cc |
|
Issue descriptionThis would have simplified diagnosing issue #924230, but it would *not* have fixed the root problem. ClientCertStore and SSLPrivateKey, at the interface level, support per-key algorithm preferences, but we largely only query platform capabilities (does the key framework itself provide RSA-PSS functions), rather than the key itself. Historically, per-key APIs have been unreliable. Instead, we order our preferences by how likely they are to be implemented. So, for instance, we would only ask a key to sign PSS if the server would not accept PKCS#1. This would not correctly handle a PSS-only key (unlikely given TLS 1.2 requires PKCS1), but it would work fine for a PKCS1-only key (more common). However, it does mean we, in theory, behave incorrectly on some edge cases and we report confusing errors. A PKCS1-only key fundamentally cannot be used with TLS 1.3, but it may be clearer if we reported ERR_SSL_CLIENT_AUTH_NO_COMMON_ALGORITHMS instead of ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED. Revisit this and query capabilities where we can. Note it's okay for the query to be imperfect because we still have our ordering. Specifically, if it says yes when it should say no, it's no worse than currently. If it says no when it should say yes, then we may break things. We should avoid mechanisms that risk the latter.
,
Today
(8 hours ago)
We rely on the OS to do filtering at the key selection time, but we mostly don't filter by keys there anyway. (We don't pass the full signature algorithms list down or anything.) Once we have a key, we still need to make a decision about which signature algorithm to use. That's where we look at SSLPrivateKey preferences and think about which hash algorithm, etc. At that layer, we'd like to know what the Java PrivateKey object can handle. (If we were super awesome, yeah, we could incorporate the server prefs all the way up to the ClientCertStore/KeyChain.choosePrivateKeyAlias bit, but we don't do that anywhere right now, and issuer filtering probably takes care of the bulk of it.) |
|
►
Sign in to add a comment |
|
Comment 1 by rsleevi@chromium.org
, Today (9 hours ago)