Add the ability to load a PKCS10 into CertificateRequest

[bartonjs]

Fixes #29547.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #29547.

Author:	bartonjs
Assignees:	bartonjs
Labels:	area-System.Security, cryptographic-docs-impact
Milestone:	7.0.0

[vcsjones]

A non-blocking suggestion, otherwise looks fine to me.

[vcsjones]

Suggested change

	int saltSize = digestValueLength.GetValueOrDefault();
	if (!digestValueLength.HasValue)
	{
	saltSize = Helpers.HashOidToByteLength(HashAlgorithm.Algorithm);
	}
	int saltSize = digestValueLength ?? Helpers.HashOidToByteLength(HashAlgorithm.Algorithm);

[vcsjones]

@bartonjs actually, one other question: some of these are "big exponent" tests. Are they going to fail on Android like you observed at #72906 (comment)?

[bartonjs]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[bartonjs]

I was going to say "no", because the PSS tests all just use a new ephemeral RSA key... but it does look like there might be at least one, so let's see.

[bartonjs]

Hmmm.... I can't actually find any big-exponent Verify tests that run. I thought we had big-exponent tests in the base algorithms library, but we don't... TestData.RsaBigExponentParams.Modulus gets used as an input; and we test that we can import and export the key, but we never Verify with it.

In the CRLBuilder tests, the Pkcs1 path didn't bother asking if the signature checked out, because the signature algorithm is deterministic, and if the signature generator can generate the right signature then clearly it can verify it... right?

RSAAndroid uses RsaPaddingProcessor instead of OS routines for sign and verify, but we know those implementations are "correct" because macOS also uses them (at least, for PSS, which we've already seen as not working). This makes it seem like Android's RsaSignPrimitive is working correctly for big exponents, but RsaVerificationPrimitive isn't... which seems... odd.

I was concerned that we broke it with moving off of RsaPaddingProcessor recently, but that was only for OAEP encryption, the current source for RSAAndroid shows it's still using RsaPaddingProcessor for RSA sign and RSA verify (both PSS and PKCS1).

As far as this PR, it's one of:

• Disable all of the failing tests on Android, linking to RSAAndroid fails to verify RSA signatures when the public exponent is bigger than 2^32 #72906.
• Make all of those tests pass SkipSignatureVerification for Android only
• Make all of those tests pass SkipSignatureVerification unconditionally
• Rewrite all of the tests to not use big-exponent RSA (which is, apparently, a fantastically good test case... but not so fantastic when it blocks a feature from being completed).

Hmm.

[vcsjones]

My 2 cents: We should disable the tests for Android and create an issue to investigate post 7 since there seems to be some ambiguity around "RsaSignPrimitive is working correctly for big exponents, but RsaVerificationPrimitive isn't"

That leaves one of two things. Either we figure out that something isn't quite right with verification, we fix it, and then remove the ignores. Or, if everything is working on our side, we can write tests against the primitives to codify that Android throws the correct CryptographicException for big exponent RSA. We can then handle the disabled tests accordingly.

Or some variation on this idea.

[vcsjones]

RSAAndroid shows it's still using RsaPaddingProcessor for RSA sign and RSA verify (both PSS and PKCS1).

Anecdotally, I was investigating getting Android off RSAPaddingProcessor for PKCS1 / PSS like we did with OAEP... but... it seems that Android has no capability to sign pre-hashed data. It always wants the message and does the hash + sign in one step, unless you fall back to raw RSA and do it yourself.

[bartonjs]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).