pdfbox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Klink (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PDFBOX-3017) Improve document signing
Date Wed, 21 Nov 2018 17:07:00 GMT

    [ 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

*Identifying the correct certificate*

For this you determine the response signer certificate using

This can return the wrong certificate.

[RFC 6960|https://tools.ietf.org/html/rfc6960#section-] 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-] 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:

|VRI|dictionary|_(Optional)_ This dictionary contains Signature VRI dictionaries (see,
"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

_(ISO 32000-2, Table 261 — Entries in the document security store (DSS) dictionary)_

_(similarly ETSI EN 319 142-1, Section — DSS Dictionary, Table "Entries in a DSS

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

To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org

View raw message