You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Tilman Hausherr (Jira)" <ji...@apache.org> on 2022/03/08 16:08:00 UTC
[jira] [Comment Edited] (PDFBOX-5385) Improve AddValidationInformation to handle exceptional situations better
[ https://issues.apache.org/jira/browse/PDFBOX-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503038#comment-17503038 ]
Tilman Hausherr edited comment on PDFBOX-5385 at 3/8/22, 4:07 PM:
------------------------------------------------------------------
Commit 1898736 from Tilman Hausherr in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1898736 ]
PDFBOX-5385: support protocol redirection from http to https, as suggested by Michael Klink
was (Author: jira-bot):
Commit 1898736 from Tilman Hausherr in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1898736 ]
PDFBOX-5385: support protocol redirection from http to https
> 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
>
> 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-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org