Provide a way to initialize the data protection key from a byte array
Flavien opened this issue · 6 comments
Along with PersistKeysToFileSystem and PersistKeysToRegistry, there should be a method that allows you to pass a byte array, encryption algorithm and hashing algorithm, which are then used as the data protection key.
It doesn't really seem to make sense that the only way to pass the data protection key is via an XML structure.
This new method would allow anyone to provide a key coming from any other source (Azure, AWS, configuration, env variable, etc.)
You're addressing two different things: the repository is separate from the encryption/decryption bits. You can replace the default IXmlRepository for the location of the key ring, while you can replace the IXmlEncryptor and IXmlDecryptor with your own implementations that will address the latter.
For some info along these lines, see #92. Also note that the team is going to provide repositories for Azure Blob/Table Storage and a tie-in to Azure Key Vault.
Sure, then disregard my comment about storage on Azure.
I want to take care myself of distribution and persistence of the data protection key, and I need a way to setup the data protection services from my own key, directly as a parameter.
What I need is another implementation of IKeyManager which is not XML based, with the convenience extension method to set it up from the IServiceCollection.
I don't recall anyone discussing that aspect (replacing IKeyManager). I'm using their XML-based key ring (with a custom Azure Table Storage repository); however, I encrypt/decrypt the keys in the key ring with my own encryptor/decryptor whose master key is stored in Azure Key Vault (because I didn't want to maintain certs on servers across a webfarm). All of the code I wrote will be going away when the team delivers the new Azure features for my apps.
The library is designed so people don't override the decisions with their own keys etc., because frankly people get that wrong. It's meant as a black box that does the right thing.
Blob/Table storage is coming (I have a meeting this week about what we need to develop for data protection next - now is a good time to ask grin), but key vault is a more interesting problem, given it's purpose is to never serve you keys. So you'd have to store keys as secrets, and they don't have a way to give us all secrets (instead you page, and page, and page) and creating new secrets in code needs elevated rights (which you never want to grant your app)
[I'm withdrawing that comment as I rubber-duck my understanding on what you said.]
Let me ask this way: Secrets in AKV are still named. Why can't the master key used to encyrpt/decrypt the key ring be kept in AKV. The difference between dev, staging, production is just using a different AKV secret. Does this boil down to you not wanting to have a stable single "master key" kept in AKV?
We are closing this issue because no further action is planned for this issue. If you still have any issues or questions, please log a new issue with any additional details that you have.