[
https://issues.apache.org/jira/browse/PDFBOX-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504523#comment-17504523
]
Tilman Hausherr commented on PDFBOX-5385:
-----------------------------------------
The OCSP and CRL signatures may not have been hashed correctly, I found this in
the specification:
{quote}
For the signatures of CRLs and OCSP responses, the bytes that are hashed shall
be the respective signature
objects represented as a BER-encoded OCTET STRING encoded with primitive
encoding{quote}
For the CRL, I've now replaced
{code}
signatureHash = MessageDigest.getInstance("SHA-1").digest(crl.getSignature());
{code}
with
{code}
BEROctetString berEncodedSignature = new BEROctetString(crl.getSignature());
signatureHash =
MessageDigest.getInstance("SHA-1").digest(berEncodedSignature.getEncoded());
{code}
The file is at
https://drive.google.com/file/d/1J2dOL_fBkyx3tys72qYL5vcPCWpEzCxP/view
> 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
