Added JDBC OCSP cache, implemented nextUpdate for FileCache usage (CR…

Created by: ankex

Hi Pierrick,

This pull request address partially the discussed features and options within the DSS-1392. Therefore this pull request contains a JDBC based OCSPSource and extends the FileCacheDataLoader in order to support the nextUpdate feature (lastModified is the nextUpdate if available, otherwise default behavior).

Supplementary this pull request address also the diagnostic capability for the evtl. occurred and logged problems concerning the HTTP communication (CommonsDataLoader). Therefore I have extended some exception-messages to give a hint about the occurred technical problem, please see below:

before: ... [2019-01-10 14:41:21,234][ 17][ pool-3-thread-19][ 19472][ eu.europa.esig.dss.tsl.service.TSLLoader] - [WARN ] : Unable to load 'https://www.llv.li/files/ak/xml-llv-ak-tsl.xml' : Unable to process GET call for url 'https://www.llv.li/files/ak/xml-llv-ak-tsl.xml'. ...

now: ... [2019-01-10 14:41:21,234][ 17][ pool-3-thread-19][ 19472][ eu.europa.esig.dss.tsl.service.TSLLoader] - [WARN ] : Unable to load 'https://www.llv.li/files/ak/xml-llv-ak-tsl.xml' : Unable to process GET call for url 'https://www.llv.li/files/ak/xml-llv-ak-tsl.xml'. Cause: Received fatal alert: handshake_failure ...

To think about / Open: suppose that the nextUpdate is set somewhere in the future (let say 6 months in the future) and before the 6 months are over a new OCSP / CRL is available. The current implementations (old implementations too) will not load the new one since the nextUpdate is not outdated. This special case is currently not treated by any related specification (RFC), or am I wrong? A technical solution for this mentioned special case and for the current implemented caches is to limit the max nextUpdate to a configurable value ( > 0 ) - is currently not done since I wanted to hear your opinion first.

Cheers Adrian.