The client App is essentially the server app, just uses a java based browser that is restricted to localhost in essence. The server distro is as one would expect. So all distros can be considered client/server software, although all authentication (apparently) occurs on he client which is a situation I've never encountered. I also don't have a good system to replicate what's in use, wouldn't know what driver/card/card-reader/Group-policy to apply to replicate it.
Has anyone tried pspdfkit? Seems to be a browser based pdf viewer with signing capabilities... don't want to learn another framework that isn't going to work though =), thought PDFBox would work in the beginning. I suspect this package relies on JS to do the signing, not sure if CaCs are supported yet. "For the PDF part: Prepare a PDF to be signed, like in the examples, then transfer the hash value (message digest) to wherever you have access to the card. Sign there and the return the PKCS#1 signature to where the document is waiting for it. Add the PKCS#1 signature into the CMS. Add the CMS to the PDF document." - I was just reading about that here, last solution: https://stackoverflow.com/questions/33216843/sign-pdf-with-plain-javascript/55676351#55676351 - I only understand 10% of these statements, but it sounds like the right approach that will maintain PDFBox as the tool, so I'll study this more today. The website doesn’t give you much information about the smartcard. Usually you can access the smartcard via PKCS#11 drivers or they integrated into the Windows infrastructure. Or use PC/SC to talk to the card directly, which I did for a couple of years. Anyway, it won’t be easy accessing the card vie JavaScript. Do you have a client application, which runs natively on Windows? Then you can access the drivers. Or do you have just browser app? 10 years ago we used Java-Applets to access these kind of cards. But Applets are dead and I am not up to date, what access a browser can give you. For the PDF part: Prepare a PDF to be signed, like in the examples, then transfer the hash value (message digest) to wherever you have access to the card. Sign there and the return the PKCS#1 signature to where the document is waiting for it. Add the PKCS#1 signature into the CMS. Add the CMS to the PDF document. Regards, Waldemar On 19. 12 2019, at 13:50, gunslingor gunslingorsadf <[email protected]> wrote: This are the kind of cards in use: https://www.cac.mil/common-access-card/ There are multiple types of distribution we do: Client Side Apps, Server based web pages and some special ones. Everything is java on the backend and JS on the front end, even client apps. No matter what package we release, they all use cards like these to login, sign PDFs and similar... the private key shouldn't leave the smartcard I agree. What I don't know is how these cards really work because I don't have access to them, but I know internet isn't required to use them and rarely is available on the client side apps. I have seen the end user sign a PDF with acrobat reader and they seem to do it normally, with a certificate selector. I would guess that these cards act as a sort of keystore themselves and the clients have special software installed that, when the card is inserted and authenticated, grants access to the certificate and perhaps imports them into the windows keystore so that apps (like acrobat) know where to look when signing... but that is just a laymen guess and I could be wrong... Based on my (lack of) knowledge on these cards, javascript seems like the only way... yet I suspect that would be more limiting in functionality than a java solution. Any questions? From: Wade Polk Sent: Wednesday, December 18, 2019 5:58 PM Yeah... it's our main use case but we won't have access to the smart cards anytime soon. Internet isn't an option so web services won't work. Javascript solution is the only way to go it would appear... at least for these smartcards; still need the keystore approach as well too though, not Need actual specifics here... everyone uses them. On Wed, Dec 18, 2019 at 5:15 PM Jason Pyeron <[email protected]> wrote: While this is not in regards to version 1.8, we are currently using smartcards and signing PDFs via web services. So no a keystore is not required, only the ability to digitally sign a digest value. -----Original Message----- From: gunslingor gunslingorsadf <[email protected]> Sent: Wednesday, December 18, 2019 3:32 PM To: [email protected] Subject: PDF Signing Validation PDFBox 1.8.10, in reference to visible signature examples Is it possible to sign a PDF without a keystore? i.e. folks use SIM card devices… they plug it into the computer, enter user/pass (or maybe alias/pin) and then the actual certificate is used and compared against the certificate stored in the user management system (i.e. cert == cert). This sounds a little odd to me, but I am no SSL expert, it was built before I arrived and these SIM devices (which I don't even have access to) make this situation a little different. Any help appreciated -------------------------------------------------------------------- - To unsubscribe, e-mail: [email protected] <[email protected]> For additional commands, e-mail: [email protected] <[email protected]> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] <[email protected]> For additional commands, e-mail: [email protected] <[email protected]> * Waldemar Dick* signing & security *Mobile* +49 (0)179 1106735 *Support* +41 (0)44 505 16 64 *E-Mail* [email protected] Pforzheimer Straße 128a, 76275 Ettlingen, Deutschland *Qualified electronic signing made easy.* Skribble.com <https://www.skribble.com>
