[ 
https://issues.apache.org/jira/browse/PDFBOX-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504540#comment-17504540
 ] 

Michael Klink commented on PDFBOX-5385:
---------------------------------------

Great, I just found the same thing ;)

I can confirm that the PAdES Conformance Checker shows no errors anymore.

> 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
>         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: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Reply via email to