spiffe
x5c property in the oidc-discovery-provider
When attempting to link SPIRE and RadosGW together like we did with Minio, it would appear that RadosGW has an additional requirement. It looks for an x5c property in document returned from the jwks_url. Reading through some of the literature it is done that way for performance reasons, so I think adding x5c property support is probably a good thing to do for SPIRE in general.
Since there are working examples of the RadosGW linked to Keycloak, I took a look at what Keycloak was doing, and it looks like their x5c property is a minimal self signed cert using the pub/priv keypair of the jwt signing keys.
Seems like it would be relatively simple to provide this property, except the oidc discovery provider does not have access to the needed private key, nor should it.
So the question becomes, what generates the cert (spire-server?) and what mechanism is used to convey it to the oidc discovery provider (maybe extend the spiffe bundle spec)?
Seems like it would be relatively simple to provide this property, except the oidc discovery provider does not have access to the needed private key, nor should it.
So the question becomes, what generates the cert (spire-server?) and what mechanism is used to convey it to the oidc discovery provider (maybe extend the spiffe bundle spec)?
If you want to authenticate to a system that requires X.509-based JWS signatures, you can fetch an X.509-SVID from SPIRE, use its private key to sign the JWS, and include the X.509-SVID + chain in the x5c header parameter of the JWS.
The oidc-discovery-provider only needs the X.509 CA certificates containing the public keys, not the private keys. You would not want to publicly share private keys in a JWKS since anyone can take that private key and impersonate the signer.
This use case of supporting verification of x5c-signed JWTs by relying parties seems reasonable to me and is also supported in the OIDC spec.
Since the oidc-discovery-provider key set will effectively double in size when the X.509 CA keys are included into the JWKS, I think it would be good to wrap this behavior behind a new configuration flag in oidc-discovery-provider. There are some applications that are known to enforce limits on how any keys can be present in the OIDC JWKS, see https://github.com/spiffe/spire/issues/4699. For that reason, I am a little concerned that rolling this out without a config could unintentionally break some users.
Yeah, a config option sounds good.
I dont think using an x509 svid would work for the x5c. it seems to need to be signed using the priv key for which the public key being presented is signed with, not an arbitrary one, or a child key.
One thing I realised after a question on Slack is that generally if you want to use an X509-SVID to issue yourself a JWT with it, on the validation side you'd want some additional checks to make sure the certificate used is allowed to issue the claims in the JWT (for example you might want the sub claim to match the SPIFFE ID of the X509-SVID). So maybe it's not that good of an idea to have X.509 CAs in the JWKS.
I don't know if there are a lot of things out there who would validate these JWTs, but maybe RadosGW is one of them.
I dont see how using an X509-SVID is at all valid for issuing a JWT.
That would require that the public key for that specific svid shows up on /keys on the oidc-discovery provider ?
I did a survey of a bunch of public oidc providers. about 1/3 has x5c properties. Of those, all of them were self signed. So for maximum compatibility, we should probably do the same.
Looks like RadosGW will change this requirement: https://github.com/ceph/ceph/pull/63047/files
That's not available in any build yet, but seems to be on its way to being merged. So maybe this won't be an issue anymore.
It will eliminate my immediate need for it, yeah. But I wonder how many other things we may want to integrate with require the property.
Thanks for the heads up. :)