Add proposal for Strimzi-native configurable RSA key sizes

[kyguy]

Type of Change

• New Proposal

Description

This proposal adds a keySize property to the CertificateAuthority configuration in the Kafka custom resource allowing users to configure the RSA key size used by Strimzi's internal CAs for both CA keys (clusterCa and clientsCa) and the certificate keys they issue.

Addresses: strimzi/strimzi-kafka-operator#12769

Checklist

Please go through this checklist and make sure all applicable tasks have been done

• AI assistance was used to create this PR (see the Strimzi AI policy)
• The proposal uses Markdown format with one sentence per line
• BEFORE MERGING: The next free sequence number was used for the proposal and all its assets (images, etc.)
• BEFORE MERGING: The proposal index in README.md was updated

[scholzj]

Thanks for the proposal @kyguy. I left some nits, but it looks mostly good.

[tinaselenge]

Thanks @kyguy for the proposal. It mostly looks good to me but I've left a couple of comments.

[tinaselenge]

We have this issue raised to address a problem with validityDays and renewalDays by separating these internally for at least KafkaUser certificates. This might be something to consider for the implementation but also makes me wonder if we should reconsider separating CA cert and end-entity cert configurations in general.

[kyguy]

This might be something to consider for the implementation

Thanks for the heads up. I'll pay close attention to this during the implementation regardless of whether the implementation lands before or after the CA refactor work. (I'll coordinate with you and Kate on this)

also makes me wonder if we should reconsider separating CA cert and end-entity cert configurations in general.

I was thinking about this as well while putting this proposal together. Separating the configurations would give users more flexibility; however, I'm not sure there has been much ask for it. Given it would require an API redesign and add complexity to the codebase, and there hasn't been much demand for separate configurations (as far as I know) I would leave it as it is for now.

[tinaselenge]

I am assuming that the reason we had 2 different keySize is that root CA keys are long-lived and high-impact if compromised, so they should be the strongest. Whereas, leaf keys are short-lived and is likely to be renewed frequently, so smaller keys are a reasonable trade-off for better TLS handshake performance. The default keySize would be increased to 4096, even though 3072 typically meets security requirements, so that we don't compromise root CA key strength. However, leaf keys are used on every TLS handshake, so this could have a performance impact for clients that may reconnect frequently? Also, are there scenarios where compliance regulations apply differently to CA keys vs leaf keys, requiring stronger keys for the CA but allowing smaller keys for leaf certs?

This make me wonder if we should add a per-KafkaUser keySize override for clients CA, similar to how validityDays and renewalDays work today after #214. This way users can configure smaller keySize for user certificates without affecting the CA key strength. What do you think?

[kyguy]

I am assuming that the reason we had 2 different keySize is that root CA keys are long-lived and high-impact if compromised, so they should be the strongest. Whereas, leaf keys are short-lived and is likely to be renewed frequently, so smaller keys are a reasonable trade-off for better TLS handshake performance.

I believe the CA keys were set to 4096 for security impact reasons, but I'm not sure the leaf keys were kept smaller for performance reasons. Since the leaf keys use OpenSSL's default, I think the decision was effectively outsourced to OpenSSL rather than being a deliberate performance trade-off.

The default keySize would be increased to 4096, even though 3072 typically meets security requirements, so that we don't compromise root CA key strength. However, leaf keys are used on every TLS handshake, so this could have a performance impact for clients that may reconnect frequently?

It could but I think for most Kafka clusters the impact would be minimal since Kafka connections are long-lived and reconnections should be infrequent. Users could always set the key size lower and bring their own CA with a higher key size if this was a requirement. I imagine if a user really needed tighter security for the CA, they would bring their own CA anyway.

Also, are there scenarios where compliance regulations apply differently to CA keys vs leaf keys, requiring stronger keys for the CA but allowing smaller keys for leaf certs?

Most of the security authorities mentioned in the Motivation section of the proposal (all except the CA/Browser Forum) set a uniform minimum key size and don't differentiate between CA and leaf key requirements. Even though the CA/Browser Forum does specify different key sizes, it's to ensure stronger protection for root CAs due to their higher security impact not to allow weaker leaf keys for performance reasons.

This make me wonder if we should add a per-KafkaUser keySize override for clients CA, similar to how validityDays and renewalDays work today after #214. This way users can configure smaller keySize for user certificates without affecting the CA key strength. What do you think?

For the leaf certificates used by KafkaUser clients correct? If so, yes I think that is reasonable. However, I think it is something we should keep out of scope for this proposal for simplicity's sake and add the feature in a follow-up proposal or PR.

How does that sound to you?