search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.17k stars 4.72k forks source link

Expose data protection keychains through X509Store #77986

Open filipnavara opened 1 year ago

filipnavara commented 1 year ago

As pointed out by @vcsjones, Apple started to silently deprecate file-based keychains on macOS. The preferred replacement are the iOS-style data protection keychains. The iOS crypto bringup in .NET 6 introduced code to support the data protection keychains but it's used only on iOS now. We should expose it on macOS and decide on the mapping between the different keychains and name / standard StoreName. I suggest to initially keep support for both types of the keychains on macOS which would likely influence how the names are mapped.

ghost commented 1 year ago

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

Issue Details
As pointed out by @vcsjones Apple started to [silently deprecate file-based keychains](https://developer.apple.com/forums/thread/696431) on macOS. The preferred replacement are the iOS-style data protection keychains. The iOS crypto bringup in .NET 6 introduced code to support the data protection keychains but it's used only on iOS now. We should expose it on macOS and decide on the mapping between the different keychains and `name` / standard `StoreName`. I suggest to initially keep support for both types of the keychains on macOS which would likely influence how the names are mapped.
Author: filipnavara
Assignees: -
Labels: `area-System.Security`, `os-mac-os-x`
Milestone: -
bartonjs commented 1 year ago

For X509Store, temporary PFX, or both?

If we're using it for X509Store, the 99% naming is from enums; so there's no real way to have any sort of naming policy for choosing... it seems like it'd be just one or the other.

If we can stop the temporary PFX keychains from needing to use the filesystem, that seems great. If we think it needs to be done in stages, we can make the data keychains trigger off of X509KeyStorageFlags.EphemeralKeySet

filipnavara commented 1 year ago

For X509Store, temporary PFX, or both?

I don't have a straight answer for that yet. I suppose both.

Currently we don't mix the two keychain types on the same platform so we never had to deal with scenarios like moving a key from one to the other, or trying to store a temporary data protection key into file based keychain. The pitfalls are unknown and have to be explored first.

For string-based names on X509Store we should continue to map to file based keychains. That should allow people to access login keychain, or anything else they used in previous .NET versions.

For temporary key(chain)s the data protection keychain APIs have more advantages.

filipnavara commented 1 year ago

For X509Store, temporary PFX, or both?

I don't have a straight answer to that yet. I suppose both.

Currently we don't mix the two keychain types on the same platform so we never had to deal with scenarios like moving a key from one to the other, or trying to store a temporary data protection key into file based keychain. The pitfalls are unknown and have to be explored first.

For string-based names on X509Store we should continue to map to file based keychains. That should allow people to access login keychain, or anything else they used in previous .NET versions.

For temporary key(chain)s the data protection keychain APIs have more advantages, like avoiding the temporary keychains altogether when dealing with ephemeral keys.

For the rest it's a choice between aligning the behavior with iOS, or keeping it closer to the older .NET versions. Eventually Apple may decide to make the choice for us.

filipnavara commented 1 year ago

(Sorry for accidentally closing the ticket; fat fingers)