Feature Overview

Currently service-ca uses legacy PKCS#1 (x509.SHA256WithRSA)[1] private key format. The go x509 library used by service-ca[2] also supports *rsa.PublicKey, *ecdsa.PublicKey and ed25519.PublicKey [3]. 

We have long standing RFE [4] and inactive cards [5] to address this situation and this Feature is to finally do so. 

[1]https://docs.openshift.com/container-platform/4.13/security/certificates/service-serving-certificate.html

[2]https://github.com/openshift/service-ca-operator/blob/master/pkg/operator/util/cert.go

[3] https://pkg.go.dev/crypto/x509

[4] https://issues.redhat.com/browse/RFE-1803

[5] https://issues.redhat.com/browse/COREPLAN-18

Goals (aka. expected user outcomes)

• Explore the use of _ed25519.PublicKey
• Explore the use of PKCS#8 as replacement
• Explore automatic migration from PKCS#1 to PKCS#8
• Provide option for cluster admin to select service-ca to only use PKCS#8

Customer Considerations

• To bring awareness to customer trying to enforce PKCS#8, consider raising an alarm and requiring acknowledgement if non-OCP components are using PKCS#1 based keys.
• When migrating from PKCS#1 to PKCS#8 as a day-2 operation, consider forcing rotation of PKCS#1-based keys.

Interoperability Considerations

Which other projects and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.