Feature Request: Transit Key Revocation

[abedra]

Feature Request:

While transit provides key rotation, revoking a key (and specifically a particular version of a key) is not possible. I'd would like to propose the following updates:

• A new endpoint that allows for revocation of a key. This would take a version number argument to support past keys and automatically rotate if the current key is assumed
• Updates to key metadata that list revoked key versions
• Automatic rewrapping for any data sent to transit encrypted with a revoked version of a key.

I am more than happy to do the work on this. I would like to make sure to have the design discussion here though to make sure this is something that would make it in if done properly.

[jefferai]

Hi there,

Can you explain the use case for this? I don't see how this is different from existing config options and ACL capabilities. What does revocation mean/imply exactly?

[abedra]

Here's my use case:

I am up to key version 5. I have data that has been encrypted using versions 1-5 of the key. At some point, version 3 of the key was compromised. I wish to revoke version 3 of the key and I would like anyone that is checking to know that they should send in any data that used version 3 of the key for re-encryption. As a nice to have I would just like to automatically perform re-encryption for anyone who presents data encrypted with version 3 of the key. Although I have had 5 key rotations, only version 3 is considered to be compromised. I don't want to destroy or revoke the other key versions, just version 3.

I'm effectively saying that version 3 of the key is no longer acceptable for use in any scenario.

[jefferai]

From what you described, it seems like you still want to allow decryption with version 3 (so that the ciphertext can be upgraded) but you don't want encryption with version 3. Doesn't the min_encryption_version parameter do what you need here, then? You can set that to 4 or 5 (or remove it, so it's always the latest) but leave min_decryption_version lower.

[abedra]

I would like to still be able to use key versions 1,2, and 4 as they are. From what I understand setting the min version to 5 would remove the ability to use 1-4.

[jefferai]

When you say "use" you mean encrypt and decrypt? If so, what is the rationale for encrypting with old key versions? Generally we don't see this, and in fact until recently transit didn't support it -- it's there for specific use-cases that require it (validation with convergent encryption mainly).

[abedra]

Yes, I am referring to encrypt and decrypt. While it's not preferred, there are situations where this becomes necessary.

[HridoyRoy]

Hi @abedra , this is a very interesting feature request!

However, in the case where a particular version of a key has been compromised, we recommend rotating the key to a new version and eol'ing both the compromised key version, as well as the earlier versions of the key. In general, we recommend that keys be rotated on a regular cadence for security purposes.

Thanks so much!

[abedra]

Hi @HridoyRoy,

This issue is no longer of direct concern to me, but I think it would be incredibly useful to have a more meaningful discussion about the reasons why it may not be desirable for a company to EOL a series of keys because of a single key compromise. There are quite a few companies who archive petabytes of data in an encrypted format. They may rotate keys yearly as standard practice, creating several versions of keys along they way as suggested above. If this is true, the following example could cause quite a major operational burden

• Company encrypts roughly 1 petabyte annually with a single key
• Company rotates keys annually, creating a new version each year
• Company continues this for 10 years
• Company discovers that on year 6, the key was compromised. They have evidence that it was only on year 6 and that the incident was contained.
• Company recognized the need to recall and re-encrypt all data from year 6

The question is, should Company have to feel the burden of recalling and re-encrypting 3 additional petabytes of data when the only compromise was the key from year 6? What if it happened during year 3?

To me this seems like an outsized obligation For an event that could be sized appropriately and potentially automated through Vault. It's certainly possible I am misunderstanding something here or that recent updates have made this scenario no longer an issue, but I figured I would leave this scenario here in case it makes the case any clearer.