Implement TLS client auth in the OS X OpenSSL port.

net/ssl/openssl_platform_key.h

Index: net/ssl/openssl_platform_key.h
diff --git a/net/ssl/openssl_platform_key.h b/net/ssl/openssl_platform_key.h
new file mode 100644
index 0000000000000000000000000000000000000000..9c695f6dc479aa4ceb75a1c7a7f7e06210e64609
--- /dev/null
+++ b/net/ssl/openssl_platform_key.h
@@ -0,0 +1,26 @@
+// Copyright 2014 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_OPENSSL_PLATFORM_KEY_H_
+#define NET_SSL_OPENSSL_PLATFORM_KEY_H_
+
+#include "crypto/scoped_openssl_types.h"
+
+namespace net {
+
+class X509Certificate;
+
+// Looks up the private key from the platform key store corresponding
+// to |certificate|'s public key. Then wraps it in an OpenSSL EVP_PKEY
+// structure to be used for SSL client auth.
+//
+// TODO(davidben): This combines looking up a private key with
+// wrapping it in an OpenSSL structure. This will be separated with
+// https://crbug.com/394131
+crypto::ScopedEVP_PKEY FetchClientCertPrivateKey(

[Ryan Sleevi, 2014/07/23 22:38:47]

I've mentioned in the past, I don't think we want to continue this pattern of
globals like this.

In the least, this won't really work for Linux/ChromeOS, which need some set of
context objects (//content/browser/net/nss_context ), which is basically a
handle to "the user's key store".

You've talked repeatedly of pushing the key in, rather than having the socket
grab the key globally. Why not do that now, since that's where we need to go
anyways for CrOS?

+    const X509Certificate* certificate);
+
+}  // namespace net
+
+#endif  // NET_SSL_OPENSSL_PLATFORM_KEY_H_