Refactor client cert private key handling.

net/ssl/client_key_store.h

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef NET_SSL_CLIENT_KEY_STORE_H_
 #define NET_SSL_CLIENT_KEY_STORE_H_
 
 #include <memory>
 #include <vector>
 
 #include "base/callback.h"
 #include "base/lazy_instance.h"
 #include "base/macros.h"
 #include "base/synchronization/lock.h"
 #include "net/base/net_export.h"
 
 namespace net {
 
 class SSLPrivateKey;
 class X509Certificate;
 
+// TODO(mattm): This is now used only by
+// chrome/browser/chromeos/net/client_cert_store_chromeos.cc.  Move it to
+// chrome/browser/chromeos/net, or just have client_cert_store_chromeos.cc
+// directly call whatever.
 // TODO(rsleevi, davidben): Remove this once https://crbug.com/394131 is fixed.
 // A certificate and key store that allows several external certificate
 // providers to expose certificates and keys through this store. All currently
 // provided certificates will be accessible through |FetchClientCertPrivateKey|.
 // Methods of this singleton can be called from any thread.

[davidben, 2017/06/01 23:41:25]

Yeah, these two TODOs are two parts of the same coin. :-) The intent is that
once we have a path from the ClientCertStore implementation to the
SSLPrivateKey, we don't need this "provider" mess and these globals.

[mattm, 2017/06/02 04:04:20]

You probably didn't look at the chromeos extensions parts yet, but I didn't see
a good way to actually fully switch to ClientCertIdentities there. 

https://developer.chrome.com/extensions/platformKeys has
selectClientCertificates which returns just DER certs, and has a separate
getKeyPair that takes a DER cert and returns the public/private keys.  So I
ended up leaving that part still doing private key lookups in the old hacky way
:(

[davidben, 2017/06/07 23:06:16]

Hrm. Well, if we could at least avoid a mess of globals and "provider"
interfaces, that would be something. That the leaf operation is a cert => key
lookup is annoying, but not far from how all the other platforms work.

Disjointed incoherent babbling of ideas: CrOS ClientCertStore implementation
could just query the CertificateProviderService and be done with it. Or if the
interface between CrOS's ClientCertStore and CertificateProviderService is still
valuable, we can at least fold the CertProvider and CertKeyProvider interfaces
into one thing. PErhaps rather than the additional_certs mess,
CertificateProviderService can just vend out a bunch of ClientCertIdentities?

(Not suggesting this be in the same CL, of course.)

[mattm, 2017/06/12 21:28:30]

FYI, I have a followup CL to delete ClientKeyStore and have CertProviderService
return ClientCertIdenties directly:
https://codereview.chromium.org/2937553003/

 class NET_EXPORT ClientKeyStore {
  public:
   class CertKeyProvider {
    public:
     // This can be called from any thread.
     virtual ~CertKeyProvider() {}
 
     // Obtains a handle to the certificate private key for |cert| and stores it
     // in |private_key|.
     // If the CertKeyProvider does not know about the |cert|, returns false. If
@@ skipping 28 matching lines @@
 
   base::Lock lock_;
   std::vector<CertKeyProvider*> providers_;
 
   DISALLOW_COPY_AND_ASSIGN(ClientKeyStore);
 };
 
 }  // namespace net
 
 #endif  // NET_SSL_CLIENT_KEY_STORE_H_