Pluggable ServerCA / RA mode for external per-SVID signing

[drewterry]

FIPS 140-3 compliance (NIST 800-57, ISO 19790) requires CA signing keys to be generated inside validated cryptographic modules via witnessed ceremony and to never leave the module boundary. Currently SPIRE's architecture doesn't accommodate this, instead the UpstreamAuthority plugin handles getting the intermediate CA certificate signed, but the intermediate CA key still has to be available to SPIRE at runtime for SVID signing.

Organizations with existing PKI infrastructure (Venafi, Keyfactor, EJBCA, etc.) already have FIPS-validated signing services with ceremony-established keys. SPIRE should be able to delegate per-SVID signing to those services rather than holding a signing key itself.

Proposal

An extension point that allows SPIRE to delegate individual SVID signing to an external service:

• Per-SVID mode for UpstreamAuthority — extend UpstreamAuthority so it can be invoked per-SVID rather than only per-CA-rotation.
• ServerCA as a plugin type — a gRPC plugin interface alongside KeyManager and UpstreamAuthority. Implementations would receive signing requests and return signed certificates, calling external CAs (Venafi, EJBCA, cert-manager, etc.).

There are real tradeoffs (signing latency, availability dependency on the external CA, throughput limits), but the current architecture forces a choice between FIPS compliance and using SPIRE.

Related

#4482 — Custom ServerCA
#525 — ServerCA HSM plugin
#2238 — Define SPIRE Server's CA explicitly

[nweisenauer-sap]

Hey @drewterry , since you can extend SPIRE with a custom KeyManager plugin, this custom plugin could delegate "GenerateKey" and "SignData" to an external validated cryptographic module. This validated cryptographic module would keep the private keys in a secure place external to the SPIRE server and only respond with signature strings.
This would work in tandem with a custom UpstreamAuthority plugin that talks to the same validated cryptographic module.
Could you see this approach being FIPS 140-3 compliant?

[drewterry]

@nweisenauer-sap I believe that the custom KeyManager plugin concept would work for a system with a PKCE#11 interface, but not for something like Venafi's Zero-Touch PKI API which requires submitting CSRs and retrieving signed certificates directly.

In addition, this concept would not allow adding the signing CA to the distributed trust bundle (although maybe a custom UpstreamAuthority plugin could?)

[amartinezfayo]

Thank you @drewterry for opening this issue.
Assuming there is a FIPS-compliant Key Manager plugin available, what is the remaining gap in SPIRE that prevents achieving FIPS 140-3 compliance in your use case?

[drewterry]

We don't have a PKCE#11 infrastructure in place. We have Venafi's ZTPKI API. We need to outsource the signing of CSRs to an external system.

[sorindumitru]

Thanks for the answers. We discussed this today and this seems to be very different from the way the project is currently used, so we don't think this is likely to be supported. Apart from it being completely different it also comes with a lot of questions:

• How do we support other SVID types?
• Credential composer plugins can add all sorts of attributes to the SVID, which might not be possible through the CSR.
• CA tainting/rotation would be difficult.

[drewterry]

All fair questions, I suppose I have been hyperfocused on our x509 use case. Can you recommend any other ways to outsource cert signing without having to generate an intermediate CA in SPIRE, or is that just outside the use case?