Open filipnavara opened 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.
Author: | filipnavara |
---|---|
Assignees: | - |
Labels: | `area-System.Security`, `os-mac-os-x` |
Milestone: | - |
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
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.
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.
(Sorry for accidentally closing the ticket; fat fingers)
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
/ standardStoreName
. I suggest to initially keep support for both types of the keychains on macOS which would likely influence how the names are mapped.