BoringSSL compatibiliy

[kornelski]

On top of #702, this adds ability to use Boring instead of OpenSSL.

BoringSSL has a FIPS-140-certified version. This PR is a step towards making the C2PA SDK usable in programs that must have FIPS compatibility. BoringSSL is a fork of OpenSSL, and it uses the same C symbols as OpenSSL, so it can't co-exist with any libraries using OpenSSL in the same binary, so it's very important to have an option to select the right implementation.

To keep the changes to minimum, instead of using any(feature = "openssl", feature = "boringssl") syntax, which is more verbose and less readable in complex cfg expressions, I've used _anyssl and _anyssl_sign Cargo features in the code for enabling common code when either of the libraries is used. As a convention, docs.rs and https://lib.rs hide _-prefixed features when documenting Cargo features.

The existing file_io Cargo feature always enables openssl_sign as a side effect. I haven't added a Boring version of it, because instead of adding another library, it'd be better to make the file I/O feature not enable any SSL library at all. However, I haven't done that in this PR to keep backwards compatibility. BoringSSL can be used without the file_io feature.

Currently, unit tests that use RSA-PSS keys don't pass. I believe this is because BoringSSL has a strict parser for private keys that rejects the "PSS parameter restrictions" section in PKCS8. This signature scheme is supported in Boring, but the parameters must be set separately via the API rather than being read with the key. I'll follow up with a fix when I have a solution. The problem is limited to just the unit tests, which need to read private key from a PKCS8 file. The actual signature verification from manifests works fine, because it uses different COSE and X509 parsers.

[mauricefisher64]

Thanks, we will take a look.

[mauricefisher64]

Can you bring the branch up to date with main. Thanks

[kornelski]

I've tried updating, but too much has been refactored on the main branch in the meantime, and the work needs to be redone from scratch.

I've also managed to solve the PSS failure. It was due to boring ssl having stricter validation of PKCS data in the private and public keys. Neither library can read the PSS parameters from the DER, but openssl silently discards the data it doesn't understand, while boringssl reports an error. I've solved that by using RustCrypto's crate to parse the key together with the PSS parameters, and reconstructing the RSA key programmatically using the API. The parsers and APIs are a bit different for private and public keys which unfortunately required implementing it twice.

Because of the extensive changes I needed for FIPS compatibility, I'm currently stuck with a fork of the SDK. Unfortunately, I'm also busy with other projects, so I won't be able to redo the integration in the near future.