Key Management Design – Separation and Rotation

[inthirakumaaran]

Below are some common key management requirements that may be needed for Thunder, along with a possible approach to modularizing them.

1. Key Separation Capability

We may need to support key separation in the following scenarios:

1. Deployment-level separation
   We can allow different keys for different purposes:

   • Primary – for external signing and encryption
   • Internal – for internal data encryption
   • TLS Communication – for transport-level security

   Initially, we can start with a single key used for all three purposes, but the system should provide the capability to separate them when required.

2. Protocol-level separation
   Separate keys for protocols such as OIDC and SAML.

3. Application-level separation
   This was suggested earlier — to support application-specific keys for signing and encryption.

Typically, internal keys are not rotated, but primary keys and protocol/application-level keys may require rotation.

---

2. Key Rotation

Primary keys must be rotated and should have proper expiration dates. Therefore, we need a proper key rotation mechanism where:

• Old keys and new keys can coexist for a grace period.
• JWKS endpoints should expose both old and new keys during the transition period.
• Signature validation should support multiple keys during key rotation.

---

Initial Scope Suggestion

For the initial phase, it would be better to focus on:

1. Deployment-level key separation
2. Primary key rotation support

More advanced separation (protocol-level and application-level keys) can be added later.

[hwupathum]

Tn thunder, we do not use keystores, instead we pass the keys directly to the conffiguration files making the key management out of Thunder.

Typically, internal keystores are not rotated, but primary keys and protocol/application-level keys may require rotation.

In Thunder, we already have 2 different default keys (Signing and TLS) [1]. We do not need internal keystores for Thunder.

Protocol-level separation
Separate keys for protocols such as OIDC and SAML.

Application-level separation
This was suggested earlier — to support application-specific keys for signing and encryption.

We already have the ability to use multiple keystore and map the key alias to different protocols [1]. We need to improve this to use different keys in different applications [2].

[1] #1117
[2] #1617