[
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: [email protected]
For additional commands, e-mail: [email protected]
