Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Breaking change]: Windows Private Key Lifetime Simplified in .NET 9 #42613

Closed
1 of 3 tasks
bartonjs opened this issue Sep 12, 2024 · 0 comments · Fixed by #42843
Closed
1 of 3 tasks

[Breaking change]: Windows Private Key Lifetime Simplified in .NET 9 #42613

bartonjs opened this issue Sep 12, 2024 · 0 comments · Fixed by #42843
Assignees
Labels
breaking-change Indicates a .NET Core breaking change doc-idea Indicates issues that are suggestions for new topics [org][type][category] in-pr This issue will be closed (fixed) by an active pull request. Pri1 High priority, do before Pri2 and Pri3 📌 seQUESTered Identifies that an issue has been imported into Quest.

Comments

@bartonjs
Copy link
Member

bartonjs commented Sep 12, 2024

Description

When loading a PKCS#12/PFX on Windows without specifying either the PersistKeySet or EphemeralKeySet storage options, .NET determines when a private key is no longer needed and should be erased. In prior versions of .NET (and in .NET Framework) two different sets of logic were utilized. In .NET 9 this has been simplified to one.

Version

.NET 9 Preview 7

Previous behavior

When loading a certificate (and its private key) from a PKCS#12/PFX with new X509Certificate2(pfx, password, flags), the loaded certificate represented the lifetime of the private key. When this certificate object was disposed (or finalized if it was garbage collected without being disposed) the associated private key would be deleted. No shared ownership or transfer of ownership occurred.

When loading a certificate (and its private key) from a PKCS#12/PFX with X509Certificate2Collection.Import(pfx, password, flags) each loaded certificate that had a private key would track the lifetime, as with the single certificate load. But, in addition, a marker was placed on the native copy of the certificate to indicate that any copies should also track the private key lifetime. If a second X509Certificate2 object was created in terms of the same underlying PCERT_CONTEXT value, then whichever copy was disposed (or finalized) first would erase the private key out from under the other.

New behavior

Starting in .NET 9, the lifetime is always associated with the X509Certificate2 instance that was directly produced from the PKCS#12/PFX load.

In previous versions, this code will fail (either with a CryptographicException, or a NullReferenceException) because the private key was deleted. In .NET 9 it will succeed.

X509Certificate2Collection coll = new X509Certificate2Collection(pfx, password, X509KeyStorageFlags.DefaultKeySet);
X509Certificate2Collection coll2 = coll.Find(X509FindType.FindBySubjectName, "", false);

coll2 = null;
GC.Collect();
GC.WaitForPendingFinalizers();

using (RSA key = coll[0].GetRSAPrivateKey())
{
    key.SignData(pfx, HashAlgorithmName.SHA256, RSASignaturePadding.Pss);
}

Type of breaking change

  • Binary incompatible: Existing binaries might encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
  • Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code might require source changes to compile successfully.
  • Behavioral change: Existing binaries might behave differently at run time.

Reason for change

Most workloads loading a PKCS#12/PFX use the single certificate load, and understand the lifetime mechanics associated with that method. The mechanics associated with the collection load were often surprising, and could lead to premature key erasure.

Recommended action

Users who understood the collection-load lifetime management and were depending on calling Dispose on a clone to cause key erasure should ensure that they are also (or instead) calling Dispose on the original loaded object.

Feature area

Cryptography

Affected APIs

  • System.Security.Cryptography.X509Certificate2Collection.Import (all overloads)

Associated WorkItem - 320278

@bartonjs bartonjs added doc-idea Indicates issues that are suggestions for new topics [org][type][category] breaking-change Indicates a .NET Core breaking change Pri1 High priority, do before Pri2 and Pri3 labels Sep 12, 2024
@dotnet-bot dotnet-bot added ⌚ Not Triaged Not triaged labels Sep 12, 2024
@gewarren gewarren removed the ⌚ Not Triaged Not triaged label Sep 13, 2024
@dotnet-bot dotnet-bot added the ⌚ Not Triaged Not triaged label Sep 13, 2024
@gewarren gewarren added 🗺️ reQUEST Triggers an issue to be imported into Quest. and removed ⌚ Not Triaged Not triaged labels Oct 1, 2024
@dotnetrepoman dotnetrepoman bot added 🗺️ mapQUEST Only used as a way to mark an issue as updated for quest. RepoMan should instantly remove it. and removed 🗺️ mapQUEST Only used as a way to mark an issue as updated for quest. RepoMan should instantly remove it. labels Oct 1, 2024
@sequestor sequestor bot added 📌 seQUESTered Identifies that an issue has been imported into Quest. and removed 🗺️ reQUEST Triggers an issue to be imported into Quest. labels Oct 2, 2024
@dotnetrepoman dotnetrepoman bot added ⌚ Not Triaged Not triaged and removed ⌚ Not Triaged Not triaged labels Oct 2, 2024
@dotnet-policy-service dotnet-policy-service bot added the in-pr This issue will be closed (fixed) by an active pull request. label Oct 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change Indicates a .NET Core breaking change doc-idea Indicates issues that are suggestions for new topics [org][type][category] in-pr This issue will be closed (fixed) by an active pull request. Pri1 High priority, do before Pri2 and Pri3 📌 seQUESTered Identifies that an issue has been imported into Quest.
Projects
No open projects
Status: ✅ Done
Development

Successfully merging a pull request may close this issue.

3 participants