Signing on Server - Revision history

Tom: /* Meme */

2022-07-28T00:23:11Z

‎Meme

Tom: /* Co Sign */

2021-05-24T19:32:33Z

‎Co Sign

Tom: /* Solution */

2020-11-22T22:01:16Z

‎Solution

Tom: /* References */

2020-11-22T21:59:43Z

‎References

Tom: /* Solution */

2020-11-22T21:59:16Z

‎Solution

Tom: Created page with "==Meme== If the user's browser cannot access a function, put the function on a server. ==Solution== ===Co Sign=== The problem that you're running into is a common one with ol..."

2020-11-22T21:57:35Z

Created page with "==Meme== If the user's browser cannot access a function, put the function on a server. ==Solution== ===Co Sign=== The problem that you're running into is a common one with ol..."

New page

==Meme==
If the user's browser cannot access a function, put the function on a server.

==Solution==
===Co Sign===
The problem that you're running into is a common one with old-style PKI systems that store the signer's private key at the boundary (eg in a smart card, a token, etc). This system was designed when the PC (and apps running on it) was the focus. But that isn't true this century. Now either the browser or the mobile is the focus.

You have tension between the nature of web apps (they're either running on the host or are sandboxed JavaScript on the browser) versus the idea of local hardware that "protects" the private key.

Breaking out of the browser's sandbox

One design direction is to try to break out of the browser's sandbox to access the local hardware private key store. You've listed a number of options. An additional one is the Chrome USB access library. But all of these solutions are:

Limited to specific browsers
Hard (and expensive) to install
Hard (and expensive) to maintain
High level of administrative overhead to help the users with their questions about keeping the system working.
Re your question 5 "Any other options?"

Yes: Centralized signing

A better option (IMHO) is to sign centrally. This way the keys are kept in a centralized FIPS-secure server. Meanwhile, the signers just use a webapp to authorize the signing. The signers don't need to hold the private key since it is stored in the secure server.

To authenticate the signers, you can use whatever level of security your app needs: user name/password; One Time Password; two factor authentication via SMS; etc.

The CoSign Signature API and CoSign Signature Web Agent are designed for this. Centralized PKI signing is also available from other vendors.

Added in response to comment

From the 2nd part of your answer - If the certificate is stored in the server and retrieved by authenticating the user by using uname/pwd or with 2FA, then why do digital signing at all? i.e. what advantage does it offer over just authenticating the transaction with uname/pwd or 2FA?
A: In the centralized design, the private key does not leave the central server. Rather, the document or data to be signed is sent to the server, is signed, and then the signed doc or data (e.g. XML) is returned to the webapp.

Re: why do this? Because a digitally signed document or data set (eg XML) can be verified to guarantee that the document was not changed since signed and provides a trust chain to provide assurance of the signer's identity. In contrast, passwords, even when strengthed by 2FA etc, only provide the app with signer identity assurance, not third parties.

PKI digital signing enables third parties to assure themselves of the signer's identity through the verification process. And the strength of the assurance can be set, as needed, by choosing different CAs.

==References==

[[Category: Trust]]

@@ Line 1: / Line 1: @@
 ==Meme==
-If the user's browser cannot access a function, put the function on a server.
+If the user's browser cannot access a function, like protecting a [[Signing]] [[Private Key]], put the function on a server.
 ==Context==

@@ Line 4: / Line 4: @@
 ==Context==
 in authentication the user may need to provide proof of a second Authentication factor that is know known to the browser.
 ==Solution==

← Older revision		Revision as of 21:59, 22 November 2020
Line 41:		Line 41:

	[[Category: Trust]]		[[Category: Trust]]
		+	[[Category: Authentication]

@@ Line 34: / Line 34: @@
 Added in response to comment
-From the 2nd part of your answer - If the certificate is stored in the server and retrieved by authenticating the user by using uname/pwd or with 2FA, then why do digital signing at all? i.e. what advantage does it offer over just authenticating the transaction with uname/pwd or 2FA?
+From the 2nd part of your answer - If the certificate is stored in the server and retrieved by authenticating the user by using uname/pwd or with 2FA, then why create a [[Digital Signature]] at all? i.e. what advantage does it offer over just authenticating the transaction with uname/pwd or 2FA?
 A: In the centralized design, the private key does not leave the central server. Rather, the document or data to be signed is sent to the server, is signed, and then the signed doc or data (e.g. XML) is returned to the webapp.