Don't use RSAPrivateKey in NSS integration code.

Currently some NSS platform integration logic transits private keys through
RSAPrivateKey on CrOS. This prevents incrementally switching RSAPrivateKey to
BoringSSL while keeping platform integrations on NSS.

The intent of this change is to clarify RSAPrivateKey as a BoringSSL vs NSS
internal crypto library (use_openssl=0 vs use_openssl=1) abstraction. It's
primarily to be used with SignatureCreator. Code which uses NSS based on
use_nss_certs rather than use_openssl because the underlying platform is NSS
should call NSS routines directly, or introduce different abstractions.

Remove the problematic RSAPrivateKey methods and instead add
crypto/nss_key_util.h which contains some helper functions for manipulating NSS
keys. This is sufficient to allow consumers of the removed methods to use NSS
directly with about as much code. (This should not set back migrating that
logic to NSS as that code was already very NSS-specific; those APIs assumed
PK11SlotInfo.)

nss_key_util.h, like nss_util.h, is built whenever NSS is used either
internally or for platform integrations. This is so rsa_private_key_nss.cc can
continue to use the helper functions to implement the NSS-agnostic interface.

With this, the chimera CrOS configuration should build. The RSAPrivateKey logic
is functional with the exception of some logic in components/ownership. That
will be resolved in a future CL.

BUG=478777

Review URL: https://codereview.chromium.org/1106103003

Cr-Commit-Position: refs/heads/master@{#327909}

0 files changed, 0 insertions, 0 deletions