Michael Klink created PDFBOX-5385:
-------------------------------------
Summary: Improve AddValidationInformation to handle exceptional
situations better
Key: PDFBOX-5385
URL: https://issues.apache.org/jira/browse/PDFBOX-5385
Project: PDFBox
Issue Type: Improvement
Components: Signing
Affects Versions: 2.0.25
Reporter: Michael Klink
While trying to create PAdES BASELINE-LTA signatures, the OP of [this stack
overflow question|https://stackoverflow.com/q/71225696/1729265] 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|https://stackoverflow.com/a/71337377/1729265] (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.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
