[Disclosure: I work for CoSign.]
The problem you are facing is common with old-style PKI systems that store the signer's private key at the border (for example, on a smart card, token, etc.). This system was developed when PCs (and applications running on it) were in the spotlight. But this is not so in this century. Now the focus is either the browser or the mobile.
You have a tension between the nature of web applications (they either run on the host or are isolated from JavaScript in the browser) compared to the idea of local hardware that protects the private key.
Break out of an isolated browser program
One of the design directions is an attempt to leave the isolated area of the browser to access the local private hardware storage. You have indicated several options. Optional is the Chrome access access library . But all these solutions:
- Limited to specific browsers
- Hard (and expensive) to install
- Hard (and expensive) to maintain
- High level of administrative overhead to help users ask questions about the operation of the system.
Repeat your question 5 "Any other options?"
Yes: Centralized Signing
The best option (IMHO) is to subscribe centrally. Thus, the keys are stored in a centralized FIPS-protected server. Meanwhile, signatories simply use webapp to authorize signatures. Subscribers do not need to hold the private key because it is stored on a secure server.
For authentication of signers, you can use any level of security that your application requires: username / password; One-time password two-factor authentication via SMS; and etc.
The CoSign Signing API and the CoSign Web Signing Agent are designed to do this. Centralized PKI signing is also available from other vendors.
Added in response to comment
From the second part of your answer. If the certificate is stored on the server and retrieved by authenticating the user using uname / pwd or using 2FA, then why sign the number at all? that is, what advantage does it offer for simply authenticating a transaction using uname / pwd or 2FA?
A: In a centralized design, the private key does not leave the central server. Rather, the document or data to be signed is sent to the server, signed, and then the signed document or data (such as XML) is returned to the webapp.
Re: Why do this? Since a digitally signed document or dataset (such as XML) can be verified to ensure that the document has not been modified since it was signed, it provides a chain of trust to ensure that the name of the signer is secure. On the contrary, passwords, even if they are enhanced by 2FA, etc., provide the application with only the subscriber’s ID, and not third parties.
PKI digital signing allows third parties to assure themselves of their identity through the verification process. And the power of confidence can be established as necessary by choosing different CAs.