You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Move computation of ShouldGenerateNewKey to KeyRingProvider (#54264)
* Move computation of ShouldGenerateNewKey to KeyRingProvider
It used to be the case that part of IDefaultKeyResolver.ResolveDefaultKeyPolicy's job was to determine whether the current default key was close enough to expiration that a new one ought to be generated. This didn't make sense as the definition of "too close" depended upon the refresh period and propagation time of the ICacheableKeyRingProvider. That is, the IDefaultKeyResolver had to make assumptions about how often it would be polled for changed.
The old logic was also very subtle and, as far as I was able to determine, slightly incorrect. Formerly, the presence of any key activated prior to the current default key's expiration date and not expiring during the next propagation cycle was considered an acceptable replacement. Several things seem strange about this:
1. The logic for finding a successor key is not the same as the logic for finding a preferred key (e.g. CanCreateAuthenticatedEncryptor is not checked)
2. The propagation window is counted forward from the current time, rather than backward from the expiration time
3. It's not immediately clear what happens if the successor key is unexpired at the end of the propagation window but expired before the default key's expiration time (maybe that's impossible or maybe that would be caught next refresh?)
4. As mentioned above, it doesn't seem like the resolver should know about the refresh period or make assumptions about how often it's called
Now, the ICacheableKeyRingProvider is responsible for determining whether the returned default key is close enough to expiration that a new key should be generated. It checks whether the current time is within one propagation cycle of the expiration time, padding by an extra refresh period to account for the fact that we don't know where in the refresh cycle expiration will fall (i.e. so that we never generate a new key _less_ than a full propagation cycle ahead of when it's needed).
Part of #53654
* Don't repeat the second resolution after key generation
* Update comment
* Add explanatory comment
* Make comment more explicit
Copy file name to clipboardExpand all lines: src/DataProtection/DataProtection/test/Microsoft.AspNetCore.DataProtection.Tests/KeyManagement/DefaultKeyResolverTests.cs
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -74,7 +74,7 @@ public void ResolveDefaultKeyPolicy_ValidExistingKey_AllowsForClockSkew_AllKeysI
0 commit comments