[PDFBOX-5385] Improve AddValidationInformation to handle exceptional situations better

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.0.25
• Fix Version/s: 2.0.26, 3.0.0 PDFBox
• Component/s: Signing
• Labels: PAdES Signature extension validation
• External issue URL: https://stackoverflow.com/a/71337377/1729265
• Assignee: Tilman Hausherr
• Reporter: Michael Klink
• Created: 08/Mar/22 09:48
• Updated: 21/Apr/22 15:38
• Resolved: 11/Mar/22 17:06

Description

While trying to create PAdES BASELINE-LTA signatures, the OP of this stack overflow question also tried to use the AddValidationInformation class to get from BASELINE-T to BASELINE-LT.

Due to a bad choice of test CA (the gembox test pki) he stumbled from one problem to the next, see his comments to my answer (the answer itself focused on generating a PAdES conform CMS signature container). In this context he indirectly identified possible improvements to AddValidationInformation. In particular:

• When doing web requests to retrieve certificates, CRLs, and OCSP responses, AddValidationInformation does not follow HTTP Moved Permanently/Temporarily responses across protocol changes because the Java URL connection implementations don't.
  While in general there might be valid security reasons for not following redirects across protocols, in the use case at hand redirects between HTTP and HTTPS URLs should be supported. In particular there likely are many HTTP-to-HTTPS redirects nowadays after in the recent years a lot of sites started redirecting that way even for their freely accessible resources.
• Other connection issues also result in exceptions that the AddValidationInformation class does not handle itself but allows to go through and cancel the whole process.
  Here the helper should catch more and continue working; for example, if there are currently problems to retrieve revocation information from the OCSP responder of some PKI, one can try and retrieve a CRL instead.
• Reading the specification there are two variants of OCSP-via-HTTP requests, one using GET with URL encoded request data and one using POST with the request data in the body. At first glance the OcspHelper.performRequest() method looks like it executes a mix thereof, using GET (by default) combined with the request data in the body.
  Probably many OCSP responders supports this, ignoring the method and retrieving the request data from wherever they are. Nonetheless, this should be investigated (maybe my first glance ignored something relevant) and fixed if applicable.