[
https://issues.apache.org/jira/browse/PDFBOX-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694953#comment-16694953
]
Michael Klink commented on PDFBOX-3017:
---------------------------------------
Some remarks concerning your recent work with the validation example -
h2. OCSP responses
You added OCSP response signer certificate revocation checks in response to [my
SO comment
here|https://stackoverflow.com/questions/30617875/add-dss-dictionary/30754978#comment93640061_30754978].
*Identifying the correct certificate*
For this you determine the response signer certificate using
{code:java}
basicResponse.getCerts()[0]
{code}
This can return the wrong certificate.
[RFC 6960|https://tools.ietf.org/html/rfc6960#section-4.2.2.3] says _the
responder MAY include certificates in the certs field of BasicOCSPResponse that
help the OCSP client verify the responder's signature._ Thus, the expression
above may return the response signer certificate but it also may results in an
{{Exception}} if no certificates are given, or it may return the wrong
certificate. You should use the *ResponderID* to identify the correct
certificate: _The purpose of the ResponderID information is to allow clients to
find the certificate used to sign a signed OCSP response._
*No revocation check may be necessary*
[RFC 6960|https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1] says _a CA may
specify that an OCSP client can trust a responder for the lifetime of the
responder's certificate. The CA does so by including the extension
id-pkix-ocsp-nocheck._ In that case no revocation check is necessary, probably
not even possible...
*VRI section for OCSP response signer certificate revocation checks*
You add the revocation information determined for an OCSP response signer
certificate into the leading PDF signature's *VRI*. This is wrong, this
information should go into a separate *VRI* for the OCSP response in question:
||Key||Type||Value||
|VRI|dictionary|_(Optional)_ This dictionary contains Signature VRI
dictionaries (see 12.8.4.4, "Validation-related information (VRI)"). The key of
each entry in this dictionary is the base-16-encoded (uppercase) SHA1 digest of
the signature to which it applies ^a^ and the value is the Signature VRI
dictionary which contains the validation-related information for that
signature.|
|^a^ ... For the signatures of *CRLs* and *OCSP* responses, the bytes that are
hashed are the respective signature object represented as a BER-encoded OCTET
STRING encoded with primitive encoding.|
_(ISO 32000-2, Table 261 — Entries in the document security store (DSS)
dictionary)_
_(similarly ETSI EN 319 142-1, Section 5.4.2.2 — DSS Dictionary, Table "Entries
in a DSS Dictionary")_
h2. CRLs
You don't do CRL signer certificate revocation checks yet.
While often the CRL signer already is the CA certificate, this is not
necessarily so. Thus, in general you need to do revocation checks here, too.
The resulting revocation information should go into their own *VRI* dictionary,
see the quoted table above.
h2. VRIs
You add neither a *TU* nor a *TS* to your *VRI* dictionaries.
While this makes sense according to ETSI EN 319 142-1 (which says _the TU key
should not be used._ and _the TS key should not be used._), in my experience
Adobe Reader is unhappy without such a time indication.
----
Some experiences with Adobe Reader "LTV-enabled" signatures are in the
{{AdobeLtvEnabling}} class for iText 7 from e.g. [this SO
answer|https://stackoverflow.com/a/51675015/1729265]. It's not 100% correct but
mostly works.
> Improve document signing
> ------------------------
>
> Key: PDFBOX-3017
> URL: https://issues.apache.org/jira/browse/PDFBOX-3017
> Project: PDFBox
> Issue Type: Improvement
> Components: AcroForm, Signing
> Affects Versions: 2.0.0, 3.0.0 PDFBox
> Reporter: Tilman Hausherr
> Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: PDFBOX-3017_certificate_chain.diff,
> PDFBOX-3017_certificate_chain_Screenshot.png, QV_RCA1_RCA3_CPCPS_V4_11.pdf,
> pdfa_signed_insivible.pdf
>
>
> Improve signing code:
> - incremental save only works for signatures and doesn't respect certificates
> such as Adobe Extended Usage Rights
> - -{{prepareNonVisualSignature}} clears the AcroForm DR
> {{acroForm.setDefaultResources(null)}} which is not good if there are other
> form fields-
> - visual/nonVisualSignature should move into the {{interactive.forms}}
> package and be handled within the signature field
> - -verify signature (to have tests that go full circle)- done June 2016
> - document or refactor / rewrite visible labyrinthine signature code
> - why is it not possible to pass only the signatureField to addSignature,
> instead having to create a COSDocument with a page and annotations that has
> the signature field, and that must be searched for in
> {{prepareVisibleSignature()}}?
> - -support rotated pages (see
> https://stackoverflow.com/questions/34012293/pdfbox-sign-landscape-file-error/34359956#34359956
> )- done in PDFBOX-3671
> - -make sure that signed PDF/A files are still PDF/A (see
> http://www.pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-14.pdf
> ); /ID possibly not OK; /Annots is possibly required ([~tilman] removed this
> for invisible signatures); test signed files with PDF-Tools and with
> preflight- tested, they are OK with PDF-Tools and preflight
> - test whether "bad" signatures are detected by preflight (search in old
> issues)
> - -PDFBOX-3363 - why is the stream cached in a file? Should it be done in
> memory?- done on July 15, 2016
> - remove {{setVisualSignature(PDVisibleSigProperties
> visSignatureProperties)}} from SignatureOptions.java, all it does is to call
> {{visSignatureProperties.getVisibleSignature()}} which returns an
> {{InputStream}}, and this is already available
> - {{checkSignatureField}} violates the "do one thing" rule
> - -decide whether the whole certificate chain should be passed in the sample
> code, instead of only the first one- yes the whole chain is stored
> - -check certificate chain, revocation lists, etc,- only if needed by users,
> code
> [here|https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.1/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/]
> - deprecate / remove all PDVisibleSignDesigner constructors except those with
> a PDDocument object, to avoid a file being opened twice
> - ... your ideas...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
