Define a pattern for a component that ensures a data protection keyring has an active key

[amcasey]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Same as #52915. We want to separate keyring reads from keyring writes to avoid races when there are multiple consumers. If we make consumers read-only, we need a dedicated writer to ensure there's an active key in a newly-created keyring and an unexpired key in an existing one.

Describe the solution you'd like

We could make a simple command-line executable that can be run either periodically or on a dynamic schedule. It needs only basic data protection functionality:

1. Read the existing keyring, if any
2. Generate a new key if there isn't one or if the active one is near/past expiration
3. Revoke all keys (we probably don't want to deal with the complexity of specifying particular keys to revoke)
4. Delete long-unused keys to avoid unbounded keyring growth
5. Output the next time it should be run (if it's not going to happen on a fixed cadence)

Additional context

For compatibility, this component basically has to consume the existing Data Protection APIs. That effectively locks us to C#, but our Data Protection usage should be simple enough to allow AOT for consumers that don't have a CLR available.

We probably don't want to expose an API for all the possible storage locations of the keyring, so it will probably just be a path.

It's not yet clear whether this will be a reusable component or merely a sample/template that can be customized per-application.

[Tratcher]

This could be a comparable tool to dotnet-ef that used all of the configuration from the current project but ignored the read-only flag. That way it could support all the different types of data stores without additional configuration (e.g. key-vault, EF, files, custom). https://learn.microsoft.com/en-us/ef/core/cli/dotnet

edit project integration might make less sense if this is primarily intended for use in production.

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.