[jira] [Commented] (FOP-3300) Extra Constructor for org.apache.fop.pdf.PDFSignParams?

"DaveLaw (Jira)" <[email protected]> Fri, 27 Mar 2026 10:16:00 +0000 (UTC)
Newsgroups gmane.text.xml.fop.devel
Message-ID <[email protected]>
    [ https://issues.apache.org/jira/browse/FOP-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18068954#comment-18068954 ] 

DaveLaw commented on FOP-3300:
------------------------------

Sorry, couldn't get back to you earlier.
Being a pensioner, my calendar is full !! :P

The Customer I wrote a FOP-Server for a couple of years back was kind enough to forward yesterdays Daily Stats:
100,000 Invocations with an average (elapsed) duration of 70ms
And their Server does a _lot more_ than a couple of SAX transformations.
(eg. FOP, CUPS print, Javamail, Zip archive, ftp, Entire-X communication...)

And the Linux boxes they are using are not exactly high-end. 

So in that context, 54ms to read the Keystore is pretty significant.
(ok, I guess that was not measured on a high-end box either)

There is also another, equally significant, issue:
the current implementation takes the first X509 Trust Chain it finds in the Keystore & ignores the rest.
My (ex-)Customer already uses a Keystore for SOAP, so they might end up
having to use multiple Keystores, which could be bothersome.

I envisage, we could add a means of supplying the following to the FopFactory :
- the PrivateKey
- the Leaf X509 Certificate
- a Bouncy Castle JcaCertStore (which contains the Cert Trust Chain)
- Name, Location & Reason as at present

(or, instead of the JcaCertStore, the Cert Trust Chain, obviating exposure of Bouncy Castle)

That would optimise the Signature as far as possible.

If you like, I could take a look at this...

> Extra Constructor for org.apache.fop.pdf.PDFSignParams?
> -------------------------------------------------------
>
>                 Key: FOP-3300
>                 URL: https://issues.apache.org/jira/browse/FOP-3300
>             Project: FOP
>          Issue Type: Improvement
>          Components: renderer/pdf
>    Affects Versions: 2.11
>            Reporter: DaveLaw
>            Assignee: Simon Steiner
>            Priority: Minor
>
> I suspect org.apache.fop.pdf.PDFSignature is rather performance-hungry in a high-volume production environment.
> Would it be possible to add another Constructor to org.apache.fop.pdf.PDFSignParams,
> replacing the Keystore & its Password with a Supplier<Certificate[]> ?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)