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

Michael Klink edited comment on PDFBOX-5385 at 3/10/22, 10:32 AM:
------------------------------------------------------------------

{quote}I believe this is being done (I did that part myself).{quote}

Ah, ok. I have to admit that I didn't verify but simply interpreted the OP's 
comments that way...

{quote}I tried running AddValidationInformation, it goes until the end and uses 
the CRL after OCSP fails, but the file isn't accepted as LTV by Adobe 
Reader.{quote}
Which version is your Adobe Reader? And which certificate have you added to 
your trust anchors?

I'm using version 2021.011.20039 and have added the GemBoxCA root certificate 
to my trust anchors, and for me the output of {{AddValidationInformation}} is 
displayed by Adobe Reader as PAdES B-LT and _LTV enabled_.


was (Author: mkl):
{quote}I tried running AddValidationInformation, it goes until the end and uses 
the CRL after OCSP fails, but the file isn't accepted as LTV by Adobe 
Reader.{quote}
Which version is your Adobe Reader? And which certificate have you added to 
your trust anchors?

I'm using version 2021.011.20039 and have added the GemBoxCA root certificate 
to my trust anchors, and for me the output of {{AddValidationInformation}} is 
displayed by Adobe Reader as PAdES B-LT and _LTV enabled_.

> 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