New cert loader should load into CNG by default

[bartonjs]

When no provider attribute is present on a key, Windows loads the key into the CAPI Base provider unless PKCS12_PREFER_CNG_KSP is set. So, set that flag.

On .NET Framework (or .NET Standard running on .NET Framework) we don't have the power to set that flag (without completely redefining how the PFX load loads), so inject a synthetic attribute to force keys into the CNG KSP when PreserveStorageProvider isn't set.

Technically these two approaches differ when the incoming PFX has no name and PreserveStorageProvider is set (CoreFX: CNG, NetFX: CAPI Base), but that's unlikely, and consistent with .NET Framework imports.

Fixes the problem identified in #104487.

[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.

[teo-tsirpanis]

BTW I've heard that the NCrypt APIs perform an RPC call to a system process and I was wondering if the same happens with a key obtained from PFXImportCertStore and if yes, whether passing PKCS12_NO_PERSIST_KEY and/or using the earlier Crypto API to get the certificate's private key would change anything.

[vcsjones]

Looks fine to me. Some non-blocking feedback for clarity in a test, but functionally looks good.

[vcsjones]

I've heard that the NCrypt APIs perform an RPC call to a system process and I was wondering if the same happens with a key obtained from PFXImportCertStore

Yes it does.

whether passing PKCS12_NO_PERSIST_KEY and/or using the earlier Crypto API to get the certificate's private key would change anything.

It does. If that is the behavior people want, they can specify X509KeyStorageFlags.EphemeralKeySet when loading the PKCS12. That gets mapped to PKCS12_NO_PERSIST_KEY (among other things).

Hedging against likely follow up question..

Why is that not the default?

I think the idea was entertained when X509CertificateLoader` was being spiked out, but it can't work for two reasons.

1. macOS does not support ephemeral key loads. X509KeyStorageFlags.EphemeralKeySet throws on that platform, and it doesn't make sense for the API to do ephemeral on one OS, and persisted on another, as a default behavior.

2. It changes the behavior of certain Windows APIs. For example, an X509Certificate2 that is used by SslStream must have a persisted key. That's a Win32 thing.

So, if you know your scenarios work with ephemeral keys, you can opt-in to it.

[bartonjs]

/ba-g The tests appear to have run successfully on all legs (infrastructure issue preventing them from uploading results?)

[bartonjs]

/backport to release/9.0

[github-actions]

Started backporting to release/9.0: https://github.com/dotnet/runtime/actions/runs/10586588721