[
https://issues.apache.org/jira/browse/PDFBOX-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17220723#comment-17220723
]
Michael Klink edited comment on PDFBOX-2776 at 10/26/20, 2:20 PM:
------------------------------------------------------------------
{quote}The remaining problem is "have LTV" in a pdf whose signature is
"certified"
{quote}
More exactly, _in PDFs whose signature is "certified" with *no changes
allowed*_. Applying LTV to documents with signatures certified with *only form
fill-ins allowed* or with *form fill-ins and annotation creation, deletion, and
modification allowed* can be LTV-enabled just like PDFs with mere approval
signatures.
ISO 32000-2 explicitly does allow adding DSS information to PDFs whose
signature is certified with no changes allowed but Adobe Acrobat rejects such
attempts nonetheless, see PDFBOX-3017.
This might even not be a simple Acrobat bug (one could hope to be fixed
sometime soon) but actually a deviation from the standard desired by Adobe
(never to be fixed); maybe they based their implemented work flows too strictly
on PDFs not changing anymore once they are certified with no changes allowed.
So as long as Adobe Acrobat validation code is not fixed in this regard, you
cannot LTV-enable signatures certified with no changes allowed after signing.
What you can do, though, is adding validation related information together with
the signature (using Adobe's Revocation Information signed attribute or maybe
even a DSS in the signed document revision).
was (Author: mkl):
{quote}The remaining problem is "have LTV" in a pdf whose signature is
"certified"
{quote}
More exactly, _in PDFs whose signature is "certified" with *no changes
allowed*_. Applying LTV to documents with signatures certified with *only form
fill-ins allowed* or with *form fill-ins and annotation creation, deletion, and
modification allowed* can be LTV-enabled just like PDFs with mere approval
signatures.
ISO 32000-2 explicitly does allow adding DSS information to PDFs whose
signature is certified with no changes allowed but Adobe Acrobat rejects such
attempts nonetheless, see PDFBOX-3017.
This might even not be a simple Acrobat bug (one could hope to be fixed
sometime soon) but actually a deviation from the standard desired by Adobe
(never to be fixed); maybe they based their implemented work flows too strictly
on PDFs not changing anymore once they are certified with no changes allowed.
> support "Long Term Validation" signature extensions (LTV)
> ---------------------------------------------------------
>
> Key: PDFBOX-2776
> URL: https://issues.apache.org/jira/browse/PDFBOX-2776
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
> Affects Versions: 2.0.0
> Reporter: Ralf Hauser
> Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: nonSigPdf-sig1.pdf,
> notCertified_368835_Sig_en_201026090509.pdf,
> notCertified_368835_Sig_en_201026090509_report.png
>
>
> in recent acrobat readers, every signature is commented w.r.t. "LTV"
> ETSI TS 102 778-4 V1.1.2 (2009-12) Technical Specification
> referenced as part 4 in
> http://en.wikipedia.org/wiki/PAdES
> It would be great if pdf signatures created with PDFBox would assist in
> creatign those.
> Target test setup:
> 1) input of an unsigned PDF-1.5 document
> 2) signature with
> a) local key pair
> b) hsm
> c) remote signature service (e.g. via soap)
> 3) add ocsp response for LTV (crls typically are larger)
> ==> Result: signed pdf where acrobat reader claims it to be "LTV enabled"
> see also PDFBOX-1848
> more in
> http://stackoverflow.com/questions/26090558/ltv-enabled-signature-in-pdf
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
