NO-JIRA: Add ECDSA P-256 key generation support

[fabiendupont]

Extends the crypto package to generate ECDSA P-256 key pairs in addition to existing RSA support, enabling OpenShift components to use modern elliptic curve cryptography.

Adds:

• KeyAlgorithm type for algorithm selection (RSA, ECDSA)
• newECDSAKeyPair() and newECDSAKeyPairWithHash() functions using P-256 curve
• newKeyPairWithAlgorithm() for unified key generation
• signatureAlgorithmForKey() for automatic algorithm detection
• CA.MakeServerCertWithAlgorithm() and CA.MakeServerCertForDurationWithAlgorithm()

All existing APIs remain unchanged, preserving 100% backwards compatibility. New functionality is opt-in through *WithAlgorithm functions.

ECDSA P-256 provides equivalent security to 3072-bit RSA with smaller keys (~87% smaller), faster operations, and better performance. This prepares OpenShift for modern TLS deployments and aligns with industry best practices.

Test coverage includes:

• Unit tests for key generation, signature algorithm detection, and encoding
• Integration tests for RSA CA + ECDSA server and vice versa
• Backwards compatibility tests verifying existing RSA functionality

[openshift-ci-robot]

@fabiendupont: This pull request explicitly references no jira issue.

Details

In response to this:

Extends the crypto package to generate ECDSA P-256 key pairs in addition to existing RSA support, enabling OpenShift components to use modern elliptic curve cryptography.

Adds:

• KeyAlgorithm type for algorithm selection (RSA, ECDSA)
• newECDSAKeyPair() and newECDSAKeyPairWithHash() functions using P-256 curve
• newKeyPairWithAlgorithm() for unified key generation
• signatureAlgorithmForKey() for automatic algorithm detection
• CA.MakeServerCertWithAlgorithm() and CA.MakeServerCertForDurationWithAlgorithm()

All existing APIs remain unchanged, preserving 100% backwards compatibility. New functionality is opt-in through *WithAlgorithm functions.

ECDSA P-256 provides equivalent security to 3072-bit RSA with smaller keys (~87% smaller), faster operations, and better performance. This prepares OpenShift for modern TLS deployments and aligns with industry best practices.

Test coverage includes:

• Unit tests for key generation, signature algorithm detection, and encoding
• Integration tests for RSA CA + ECDSA server and vice versa
• Backwards compatibility tests verifying existing RSA functionality

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: fabiendupont
Once this PR has been reviewed and has the lgtm label, please assign p0lyn0mial for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[p0lyn0mial]

Hmm, I might be wrong, but it looks like MakeServerCert and MakeServerCertWithAlgorithm are very similar. There are two differences. The first is the key algorithm, and the second is that MakeServerCertWithAlgorithm sets the signature algorithm.

I’m wondering if it would make sense to create a private common function for both. I think something like the following could work:

func (ca *CA) MakeServerCertWithAlgorithm(hostnames sets.Set[string], lifetime time.Duration, algorithm KeyAlgorithm, fns ...CertificateExtensionFunc) (*TLSCertificateConfig, error) {
	sigFn := func(template *x509.Certificate) error {
		template.SignatureAlgorithm = signatureAlgorithmForKey(ca.Config.Key)
		return nil
	}
	fns = append([]CertificateExtensionFunc{sigFn}, fns...)
	return ca.makeServerCertWithAlgorithm(hostnames, lifetime, algorithm, fns...)
}

and

func (ca *CA) MakeServerCert(hostnames sets.Set[string], lifetime time.Duration, fns ...CertificateExtensionFunc) (*TLSCertificateConfig, error) {
	return ca.makeServerCertWithAlgorithm(hostnames, lifetime, AlgorithmRSA, fns...)
}

[p0lyn0mial]

Since this is a private method I think we could return an error for unsupported algorithms.

[p0lyn0mial]

am I right that the differences between MakeServerCertForDuration and MakeServerCertForDurationWithAlgorithm mirror those between MakeServerCert and MakeServerCertWithAlgorithm (key algorithm and signature algorithm)? If so, could we refactor them in the same way?

[fabiendupont]

Good feedback. Makes sense.

[openshift-ci]

@fabiendupont: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.