Narrative

The Keycloak's current method of loading Certificate Revocation Lists (CRLs) appears to be slow and resource-intensive, causing high memory and CPU usage during logins. This problem worsens with larger CRLs, sometimes leading to Keycloak crashes. For instance, for CRLs like the ones found here (https://crl.gds.disa.mil/) Keycloak can crash out of memory and can take up to 5 or 6 seconds for every login attempt to complete.
Additionally, CRLs aren't automatically refreshed, requiring manual management.
It is needed to have a caching mechanism and a more efficient CRL parser to enhance the memory handling and overall performance.

Value Proposition

• Addresses critical performance issue
• FedRAMP Rev 5 control IA-05 (02) requires implementing a local cache of revocation data to supplement in situations when the system is unable to access revocation information via the network.
• As a FedRAMP authorized organization, we must comply with these controls.

Goals

• Support for any number of CRLs of any size either as the primary certificate validation method or in concert with OCSP.
• Ensure a CRL handling of multiple large CRLs with good performance

Implementation note

• References to existing issues: 
  -> https://github.com/keycloak/keycloak/issues/26473
  -> https://github.com/keycloak/keycloak/pull/25863
  -> https://github.com/thomasdarimont/keycloak/commit/2ad93c91ed68982330f19ed8133e63f786e5c156
• When implementing a solution it must be considered that CRLs can be configured at the server-level (unsupported Quarkus option currently) as well as on individual x509 user authenticators in realms. We are also missing the ability to define CRLs for client x509 authentication. Essentially we need a centralized place to fetch/cache/parse CRLs and not multiple implementations