[API Proposal]: Amend MLKem, MLDsa, and SlhDsa ImportEncryptedPkcs8PrivateKey

[vcsjones]

Background and motivation

In #114453 we approved the following APIs for ImportEncryptedPkcs8PrivateKey:

        public static MLKem ImportEncryptedPkcs8PrivateKey(ReadOnlySpan<byte> passwordBytes, ReadOnlySpan<byte> source);
        public static MLKem ImportEncryptedPkcs8PrivateKey(ReadOnlySpan<char> password, ReadOnlySpan<byte> source);
        public static MLKem ImportEncryptedPkcs8PrivateKey(string password, ReadOnlySpan<byte> source);

After some discussion, we decided that the last of the trio would be better if the source parameter were a byte[], not a ReadOnlySpan<byte>.

We decided that, since the string overloads for password exist purely for ease-of-use for other downlevel platforms, that one should take a byte array instead of a ReadOnlySpan. There is already an overload that accepts ReadOnlySpan, ReadOnlySpan, so modern targets still have access to all the span APIs that they want.

This also offers better symmetry with ImportFromEncryptedPem which uses string, byte[].

API Proposal

namespace System.Security.Cryptography
{
    public class MLDsa, MLKem, SlhDsa, CompositeMLDsa
    {
        public static MLKem ImportEncryptedPkcs8PrivateKey(ReadOnlySpan<byte> passwordBytes, ReadOnlySpan<byte> source);
        public static MLKem ImportEncryptedPkcs8PrivateKey(ReadOnlySpan<char> password, ReadOnlySpan<byte> source);
-       public static MLKem ImportEncryptedPkcs8PrivateKey(string password, ReadOnlySpan<byte> source);
+       public static MLKem ImportEncryptedPkcs8PrivateKey(string password, byte[] source);
    }
}

API Usage

Same usage, but a different type for platforms where span is cumbersome to use.

Alternative Designs

No response

Risks

No response

[dotnet-policy-service]

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