You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Michael Klink (Jira)" <ji...@apache.org> on 2026/07/06 17:46:00 UTC
[jira] [Commented] (PDFBOX-6215) LTV DSS generation creates duplicate certificate streams
[ https://issues.apache.org/jira/browse/PDFBOX-6215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18094079#comment-18094079 ]
Michael Klink commented on PDFBOX-6215:
---------------------------------------
Indeed, here are duplicate streams.
In the file at hand we have
* duplicates of certificates; different streams containing the same certificate are referenced from different VRI dictionaries; the DSS Certs array only references one of them;
* duplicates of OCSP responses; different streams containing the same OCSP response are referenced from the same VRI and also from the DSS OCSPs.
This of course is wasteful. In this file it is not that serious, but if the same issue can occur for CRLs, this can be substantial as CRLs sometimes are several MBs in size.
Whether it is standard compliant, is a bit difficult to say. According to ISO 32000-2 the certificates, CRLs, and OCSP responses in a VRI dictionary shall be selections of the certificates, CRLs, and OCSP responses respectively in the DSS dictionary. According to ETSI EN 319 142-1, any values in the Cert, CRL and OCSP arrays of a Signature VRI dictionary shall also be present in the DSS dictionary. Neither one explicitly refers to stream objects containing the certificates, CRLs, or OCSP responses in question. But one may argue that they "obviously" are meant.
Having two copies of the same OCSP response in a VRI dictionary is even more questionable: The values in a VRI dictionary are intended to be values used for verifying the signature in question. The verification routine in question must be somewhat weird to need two identical copies of an OCSP response.
Nonetheless, as neither spec is explicitly against multiple stream objects containing the same object here, I don't think you can really consider this a violation of the standards.
> LTV DSS generation creates duplicate certificate streams
> --------------------------------------------------------
>
> Key: PDFBOX-6215
> URL: https://issues.apache.org/jira/browse/PDFBOX-6215
> Project: PDFBox
> Issue Type: Improvement
> Affects Versions: 4.0.0
> Reporter: robo
> Priority: Minor
> Attachments: timestamped_LTV.pdf
>
>
> If I run `TestCreateSignature::testCreateSignedTimeStamp` with e.g. `http://timestamp.digicert.com` as TSA, then `AddValidationInformation` adds the incremental update containing the `DSS` dictionary. This works, however, it looks like the same certificates are written more than once to the PDF.
> I extracted the streams like this:
> {code:java}
> qpdf "timestamped_LTV.pdf" --show-object=[obj] --filtered-stream-data > "obj-[obj].bin"{code}
> and compared them with
> {code:java}
> sha256sum *.bin | sort{code}
> resutling in:
> {code:java}
> 33846b545a49c9be4903c60e01713c1bd4e4ef31ea65cd95d69e62794f30b941 obj-43.bin
> 33846b545a49c9be4903c60e01713c1bd4e4ef31ea65cd95d69e62794f30b941 obj-49.bin
> 3e9099b5015e8f486c00bcea9d111ee721faba355a89bcf1df69561e3dc6325c obj-44.bin
> 3e9099b5015e8f486c00bcea9d111ee721faba355a89bcf1df69561e3dc6325c obj-50.bin
> 3e9099b5015e8f486c00bcea9d111ee721faba355a89bcf1df69561e3dc6325c obj-52.bin
> b0765f42a321cf66788b939d350bd958d8bd0361bfb1099528ae0732bf66fae6 obj-45.bin
> b0765f42a321cf66788b939d350bd958d8bd0361bfb1099528ae0732bf66fae6 obj-46.bin
> ca0b1554ecd901ea19dcad8749e9f2648c8d6dfcea1add9d2c2109415bb82ccd obj-42.bin
> ca0b1554ecd901ea19dcad8749e9f2648c8d6dfcea1add9d2c2109415bb82ccd obj-48.bin{code}
> Pointing to already existing objects with the same content should still be be standard-compliant (I don't see why not, please let me know if this is not correct). Like this, the output could be kept slightly smaller and cleaner.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org