Don't use RSAPrivateKey in NSS integration code.

components/ownership/owner_key_util_impl.cc

Index: components/ownership/owner_key_util_impl.cc
diff --git a/components/ownership/owner_key_util_impl.cc b/components/ownership/owner_key_util_impl.cc
index bc7208e4642d21603513324d40236fddf4a4207c..cab5ffad2c759dc35ddc00cf211b37dc7b6438f8 100644
--- a/components/ownership/owner_key_util_impl.cc
+++ b/components/ownership/owner_key_util_impl.cc
@@ -8,7 +8,12 @@
 
 #include "base/files/file_util.h"
 #include "base/logging.h"
+
+#if defined(USE_NSS_CERTS)
+#include <keythi.h>
+#include "crypto/nss_key_util.h"
 #include "crypto/rsa_private_key.h"
+#endif
 
 namespace ownership {
 
@@ -54,7 +59,18 @@ bool OwnerKeyUtilImpl::ImportPublicKey(std::vector<uint8>* output) {
 crypto::RSAPrivateKey* OwnerKeyUtilImpl::FindPrivateKeyInSlot(
     const std::vector<uint8>& key,
     PK11SlotInfo* slot) {
-  return crypto::RSAPrivateKey::FindFromPublicKeyInfoInSlot(key, slot);
+  crypto::ScopedSECKEYPrivateKey private_key(
+      crypto::FindNSSKeyFromPublicKeyInfoInSlot(key, slot));
+  if (!private_key || SECKEY_GetPrivateKeyType(private_key.get()) != rsaKey)
+    return nullptr;
+#if defined(USE_OPENSSL)
+  // TODO(davidben): This assumes that crypto::RSAPrivateKey also uses NSS.
+  // https://crbug.com/478777
+  NOTIMPLEMENTED();
+  return nullptr;

[davidben, 2015/04/27 18:07:22]

Leaving this for a follow-up since I'm not sure yet what components/ownership's
NSS dependency is intended to be. Given that this function is USE_NSS_CERTS and
depends on PK11SlotInfo, naively I would think we should replace
crypto::RSAPrivateKey with crypto::ScopedSECKEYPrivateKey. But, unlike the other
places, this key is used with SignatureCreator rather than raw NSS APIs. And the
tests pull a key out of corp policy. (Perhaps that should just transit through a
PrivateKeyInfo and we replace the SignatureCreator call with NSS APIs directly?)

[Ryan Sleevi, 2015/04/27 19:11:27]

That seems less-desirable; I mean, the team is using SignatureCreator to avoid
needing to reimplement NSS-based signing, whether you're dealing with software
keys (e.g. Extensions) or hardware keys (such as here).

In a BoringSSL world, this would need to coordinate with chapsd and friends,
which further suggests we should try to figure a decent abstraction here so that
//components/ownership isn't reimplementing crypto primitives.

[davidben, 2015/04/27 19:17:09]

Yeah, that's also an option, which is why I set this aside for now. One
possibility is reusing SECKEYPrivateKey -> EVP_PKEY bridge that client auth will
need (async vs sync aside) and route through there.

Though note that this API is already not suitable for a NSS/CHAPS abstraction.
It depends on PK11SlotInfo.

+#else
+  return crypto::RSAPrivateKey::CreateFromKey(private_key.get());
+#endif
 }
 #endif  // defined(USE_NSS_CERTS)