Just want to come back to the initial question in case anybody else is interested.
I had this fine gentleman from IBM responding privately to me, confirming that CRLs are not cached locally and so whenever a certificate is checked against a CRL, a new version of that CRL is downloaded.
The parameter kess.crlInterval determines the time to cache a "CRL decision" for a given cert.
So to wrap it all up: When a CRL check is executed, the CRL is downloaded *each time*. Triggering the download by validating a specific certificate can be prevented by caching the CRL check decision for a period of time, specified in the kess.crlInterval advanced configuration parameter.
Note that multiple certificates, sharing the same issuing CA could still trigger a download of the CRL before the kess.crlInterval time has passed by since the last download.
This feels counter-intuitive to me. I would expect a CRL system to work as follows: CRLs are downloaded in the background on regular bases and anyway before they expire. There should be a parameter that lets you control the interval of downloading a CRL. Than, whenever a certificate needs to be validated, the CRL check is performed against the local copy of the CRL.
Additionally, it would be great if you could disable CRL (or OCSP for that matter) checking for specific certificates. In general, CRL checking is important, but in SAML integrations, I think it's acceptable to use selfsigned certificates (or certificates that are signed by some internal CA that does not provide OCSP or CRL distribution points that are publicly available).
The reason is because in SAML integrations, you trust the certificate itself rather than the CA and a property identifying the certificate. So if a certificate used for signing or encrypting SAML messages gets compromised and the admin wants to revoke it, (s)he will need to replace the cert and inform the partners anyway, as they need to trust the new certificate.
In a scenario where some partners insist in using certificates without OCSP/CRL distribution point, it would be interesting to disable OCSP/CRL checking *for those certificates only* while still performing revocation validation for all others where it *is* possible to do.
If you don't agree with this reasoning, I would be more than interested in hearing your point of view!
I added that idea of exceptions to my RFE as a comment. If you agree, it may be a good idea to add it to your RFE if anybody is still filing one for the OCSP functionality :)
Have a nice day.
------------------------------
Kristof Goossens
------------------------------
Original Message:
Sent: 02-04-2019 11:05 AM
From: Kristof Goossens
Subject: federation advanced config param kess.crlInterval
Hi community,
I am a bit confused by the federation module documentation for an advanced configuration property: kess.crlInterval.
Documentation states the following:The amount of time, in seconds, between successive CRL checks. Using an interval of time between CRL checks reduces the performance impact of doing the checks every time a certificate needs to be validated.
A value less than or equal to zero means that the runtime performs a CRL check every time it wants to use a certificate. The default is 0 seconds.
If kess.crlEnabled is set to false, this value is ignored. Data type: Integer
Example: 86400
This value means that a CRL check on a certificate is performed once per day.
Does this mean that a specific certificate is checked once every configured period when used (e.g.: Federation module keeps track of which certificates have been crl-checked and at what time) or does this mean that the federation module will try to check if there is a new CRL available (and try to download it) whenever a certificate is to be validated?
Given the default of 0, I'd suppose the former is the case, but I just wanted to be sure.
Thanks in advance
------------------------------
Kristof Goossens
------------------------------