[
https://issues.apache.org/jira/browse/PDFBOX-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-5385:
------------------------------------
Fix Version/s: 2.0.26
3.0.0 PDFBox
> 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
> Priority: Major
> Labels: PAdES, Signature, extension, validation
> Fix For: 2.0.26, 3.0.0 PDFBox
>
> Attachments: SO71225696_signed.pdf
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
