[OID4VCI] Harden key attestation x5c certificate validation - #51042

Is it possible to add more details about this option? For example:

• How exactly is revocation verified?
• Does the leaf certificate (or ca certificate) needs to have some elements in itself, which allow to validate this? Does it use revocation list, OCSP or something similar?

I am asking as it is not clear to me how this works and it looks that automated test OID4VCKeyAttestationTest does not have any successful test with certificate revocation checking enabled. If it is not clear, would it be possible to remove this option Certificate revocation checking for now and instead add some WARNING to this documentation that certificate revocation checking is not yet supported?

I traced the current behavior through the configured PKIX provider. In the standard crypto provider, enabling this flag invokes Bouncy Castle’s default CRL checker, but we do not provide a CRL store or configure CRL Distribution Point retrieval, and no OCSP checker is wired into this path. Therefore, there is no supported successful revocation configuration through Keycloak, which also explains why the test only covers failure when revocation information is unavailable.
I will remove the option for now, explicitly disable provider-default PKIX revocation, and document the limitation with a warning. Proper CRL/OCSP support should be handled separately with explicit configuration, Keycloak-managed network access, and successful/revoked/unavailable test coverage.

If I understand correctly, for x5c-based attestations, it is required that extended key usage needs to be configured. Is it please possible to mention this more clearly in the documentation, that it is required in the configuration and also required to be present in the certificate? Also possibly with some example value, which is typically used for this (not sure if 1.3.6.1.4.1.55555.1.1 is typical OID used for this purpose or if different OIDs are usually used for this?)

@forkimenjeckayang One additional thing: The OIDCIdentityProvider also implements TrustMaterialIdentityProvider . However it doesn't override resolveX509Trust method. So if I understand correctly, for OIDCIdentityProvider, it is not yet supported to handle x5c-based attestations? Might be likely good to document this limitation of OIDC Identity provider with some warning here?

I clarified that the EKU configuration is mandatory and that the attestation leaf certificate must contain at least one EKU OID exactly matching a configured value. OID4VCI does not define a universal key-attestation EKU, so the documentation directs administrators to use the device-vendor or trust-framework OID and provides a documentation-only private-PKI example.
I also added a warning that the built-in OIDC identity provider exposes only JWK trust material. It cannot validate x5c chains because it does not implement X.509 trust resolution; x5c configurations must currently use Default Trust or a custom X.509-capable trust-material provider.

Would be good to replace EKU with something like Extended key usage (EKU) . As it may not be clear what the shortcut means...

It could be nice if this documentation paragraph is a bit expanded (or converted into dedicated section) - maybe with some example picture/diagram of 2 certificates like ca and leaf and example showing that ca should be configured on IDP side and both leaf and ca included in the x5c of proof etc. As this topic is not trivial and might be nice to make sure that documentation is not confusing for people, who are not deeply familiar with the topic...)

I expanded this into a dedicated X.509 certificate-chain validation section with a diagram showing the relationship between the certificates presented in x5c and the root/EKU policy configured in the identity provider.
I clarified one detail: the leaf must be x5c[0], and any required intermediate certificates follow it. The configured root may also be included as the final entry, but it is not required because it is already available as the trust anchor. For a leaf issued directly by the configured root, x5c can therefore contain only the leaf. Including a root in x5c never makes it trusted by itself.

nitpick: It seems confusing that using revocationEnabled=null as parameter of this method runAttestationWithX5cCertificateChain means testing with system truststore. Is it perhaps possible to rather introduce new flag to the method runAttestationWithX5cCertificateChain instead of mis-using revocationEnabled flag?

This has been addressed as part of removing the unsupported certificate-revocation option. runAttestationWithX5cCertificateChain now has a dedicated configureTrustProvider boolean. The system-truststore regression passes false, while tests using the configured X.509 attestation trust provider pass true. There is no longer a nullable revocationEnabled parameter or overloaded meaning.

When checking this, I am thinking about this corner-case scenario:

• default-trust identity provider has configured certificate with subject=my-ca, issuer=my-ca, which is self-signed by ca-keypair1
• The proof has x5c element with something like this (single leaf certificate, root certificate is omitted):
  • cert[0]: subject=my-leaf, issuer=my-ca, which is signed by ca-keypair2

In other words, the issuer from x5c is same value my-ca as the trusted CA certificate from identity provider configuration. However the x5c is signed by incorrect keypair ca-keypair2 (not by the ca-keypair1 from IDP config).

Just thinking about possible attack, when attacker knows the name of configured CA, however attacker creates his own CA certificate of same name, but signed by his own keypair (ca-keypair2), which he would use to sign his own root certificate and leaf certificate attached.

Do you think that such scenario would be rejected? Might be good to have automated test for this though?