Clarification for CMK expiration date

[kamilzzz]

Documentation mentions:

Before you attempt to configure the CMK, be sure to address the following requirements. [...] The key activation date (if set) must be a date and time in the past. The expiration date not set.

Please explain whether the The expiration date not set requiement is still valid and what's the reasoning behind it.

I successfully configured key with expiration date as CMK for encryption and I would say that would be the expected behaviour because:

• Key Vault's key auto-rotation feature always sets key expiration when it rotates a key inside the Key Vault, if MySQL Flexible Server wouldn't support keys with expiration date set that would render Key Vault's auto-rotation mechanism useless for this purpose
• decrypt and unwrap operations are allowed to be performed on expired keys as described here

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: 099cae46-9d09-ac46-7f03-580d56d578b8
• Version Independent ID: d0f05904-70e3-f6ae-3e9c-af3fde6f6f68
• Content: Data encryption with customer managed keys - Azure Database for MySQL - Flexible Server
• Content Source: articles/mysql/flexible-server/concepts-customer-managed-key.md
• Service: mysql
• Sub-service: flexible-server
• GitHub Login: @SudheeshGH
• Microsoft Alias: sunaray

[PesalaPavan]

@kamilzzz Thanks for your feedback! We will investigate and update as appropriate.

[Naveenommi-MSFT]

Hello @kamilzzz The requirement for setting an expiration date on cryptographic keys stored in Azure Key Vault is still valid. This is because setting an expiration date on keys is a recommended security practice that helps to reduce the risk of unauthorized access to sensitive data. While it is possible to use keys with an expiration date set as customer-managed keys (CMKs) for encryption in Azure Database for MySQL Flexible Server, it is important to note that the expiration date must be set in the Key Vault, not in the MySQL Flexible Server.

As you mentioned, Key Vault's key auto-rotation feature always sets key expiration when it rotates a key inside the Key Vault. This ensures that keys are rotated regularly and that any compromised keys are retired promptly. However, it is still recommended to set an explicit expiration date on keys to ensure that they are retired even if they are not rotated by the auto-rotation feature. Regarding the ability to perform decrypt and unwrap operations on expired keys, it is true that expired keys can still be used for these operations. However, it is important to note that using expired keys can pose a security risk, as they may have been compromised or weakened over time. Therefore, it is recommended to retire expired keys promptly and replace them with new keys.

I hope this helps clarify the reasoning behind the requirement for setting an expiration date on cryptographic keys stored in Azure Key Vault.

[kamilzzz]

Thanks @Naveenommi-MSFT. That explain pretty well why setting expiration date is in general recommended best security practice. The issue is MySQL Flexible Server documentation specifies expiration date should not be set (this is not enforced service-side anyway).

[Naveenommi-MSFT]

@kamilzzz Thank you for bringing this to our attention. I've delegated this to content author @SudheeshGH, who will review it and offer their insightful opinions.