KeyRingProvider uses 24h refresh period even with expired keys and disabled key auto-generation

[DunetsNM]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When KeyRingProvider uses an expired key with AutoGenerateKeys = false, it schedules the next refresh for up to 24 hours in the future:

aspnetcore/src/DataProtection/DataProtection/src/KeyManagement/KeyRingProvider.cs

Lines 187 to 198 in 0230498

	var nextAutoRefreshTime = now + GetRefreshPeriodWithJitter(KeyManagementOptions.KeyRingRefreshPeriod);
	// The cached keyring should expire at the earliest of (default key expiration, next auto-refresh time).
	// Since the refresh period and safety window are not user-settable, we can guarantee that there's at
	// least one auto-refresh between the start of the safety window and the key's expiration date.
	// This gives us an opportunity to update the key ring before expiration, and it prevents multiple
	// servers in a cluster from trying to update the key ring simultaneously. Special case: if the default
	// key's expiration date is in the past, then we know we're using a fallback key and should disregard
	// its expiration date in favor of the next auto-refresh time.
	return new CacheableKeyRing(
	expirationToken: cacheExpirationToken,
	expirationTime: (defaultKey.ExpirationDate <= now) ? nextAutoRefreshTime : Min(defaultKey.ExpirationDate, nextAutoRefreshTime),

This creates a problem in multi-application scenarios where:

1. App A generates keys
2. App B has AutoGenerateKeys = false and relies on App A for new keys, but starts few minutes earlier than App A
3. When App B's key expires, it waits up to 24h before checking for new keys from App A

Since App B explicitly disabled auto-generation, it depends on other apps for new keys and should check for them more frequently when using expired keys (e.g., every 5 minutes).

Suggested fix:
Use a shorter refresh period when defaultKey.ExpirationDate <= now && !_keyManagementOptions.AutoGenerateKeys

[DeagleGross]

Thanks for posting the issue. I see such comment on keyRingRefreshPeriod:

            // This value is not settable since there's a complex interaction between
            // it and the key expiration safety period.

So it can be not so trivial to change the value here. Moreover, I think we should strive towards allowing to control those options, otherwise in some scenarios expiration period of 5 minutes as proposed by the author can also be not satisfying specific needs.

I am putting this to backlog for now, and we will revisit it later. Today workaround is to use reflection to set the desired value, but its user's responsibility to ensure other parts of DataProtection will work correctly