3

I'm treading into the murky waters of electronic document signatures, and I'm having trouble figuring out the right approach to deal with my requirements. I think this should be pretty straightforward, but endless searching has left me with no concrete examples.

I am building a platform (imagine an Uber-type model) for matching clients with professional service providers. At the end of the services being provided, the service provider needs to send a document (a PDF) to the client for a signature. We want to let the client electronically sign the document, and here's where things become unclear. We need these signatures to be legally binding, but it isn't clear to what lengths we need to go to get to that point.

Clients in this system will have to create a login and authenticate with our system before they can sign anything. Therefore, we know who they are when they go to sign. Some things that I have read suggest that having the user declare (check a box, type their name, etc.) something like the following would be enough: "I agree to blah, blah, blah, and I intend to convey the same significance to this electronic signature as I would to a physical signature". We could then stamp the document with a signature-looking text and be done with it.

Other extremes seem to be to electronically sign the PDF itself using PKI, requiring public/private keys for each user. Due to libraries (un)available in my technology stack, it's unlikely that I will be able to digitally sign the actual PDFs.

I thought maybe a middle ground would be to do asymmetric encryption on the document at the time of "signing", and store the signed document at that point. That way, we could later verify that the document was unaltered if it ever comes into question. However, this approach would also require public/private key pairs for each client, and we are not prepared to require our users to generate their own. Would it then be appropriate for us to generate pairs for each user, storing them on our own server and/or in our own database (along with their other user information)? Does this really get us any better security than we had just by having users log in?

I would really appreciate any insight here. Unfortunately, most documentation out there is from DocuSign or other vendors trying to sell their services. Obviously it would be a big relief to just use that, but the cost is exorbitant given the model we have (most charge per user).

UPDATE: This service will be US-based only for the foreseeable future (if that changes anything)

UPDATE: I see a related question (Digital signatures and truly validating what was actually agreed to) that talks about a similar problem. Basically responses there confirm my fear that yes, it might be invalid for me to maintain private keys for my users. In that case, how are other electronic signature providers (including DocuSign, HelloSign, etc.) able to provide this capability without their users needing to know about private keys?

Improve this question
4
  • Would Adobe's eSign (formerly known as EchoSign) service be suitable? This would be the most obvious approach, considering PDF documents.
    – Max Wyss
    Commented Dec 8, 2015 at 23:30
  • 1
    Thanks for the suggestion, but that's also $45/month/seat (which in our case would be a service provider). Given we may have hundreds of providers, each only needing to send a couple of forms perhaps, this wouldn't scale for us. 100 service providers would cost $4500/month. It's a similar story with nearly every "signature as a service" available, unfortunately.
    – creativename
    Commented Dec 9, 2015 at 0:09
  • Another related question: security.stackexchange.com/q/105752/61443
    – Mike Ounsworth
    Commented Dec 9, 2015 at 2:05
  • Thanks, I did come across that one as well but unfortunately the best answer requires users to manage their own keys (not realistic in our use case). It's also in pursuit of adhering to EU laws, and we'll be US-only for the foreseeable future (updated the original question as well)
    – creativename
    Commented Dec 9, 2015 at 3:15

1 Answer 1

Reset to default
1

See https://crypto.stackexchange.com/questions/29501/how-can-cryptographic-signatures-be-somehow-linked-to-a-physical-signature for an outstanding explanation of how services like DocuSign actually work - including their use or cryptography (or lack thereof). In short, these types of services basically function as a 'witness' to attest that someone with access to a particular user's account agreed to the terms of a particular document. Although these services tout the use of cryptography in their marketing materials, cryptography actually does not play an integral role in the actual 'signing' process.

Improve this answer
3
  • This link is awesome! Thank you. Essentially it confirms what I thought and initially proposed - they generate key pairs for each user as a way to verify the authenticity of documents offline. Otherwise, according to that answer, it would be exactly as legitimate if DocuSign/we were to store confirmation of a signature. However, it seems in this case that no asymmetric encryption is necessary on our end since it would all come down to all parties trusting us anyway. I would still like to see if anyone has any input on whether I'm understanding this correctly, though.
    – creativename
    Commented Dec 10, 2015 at 1:25
  • 1
    I think you're understanding this correctly. To do digital signing the 'right' way, nobody other than the signer should have a copy of the private key. If a 'signing service' (such as DocuSign) has a copy of a user's private key, then they could (if they wanted to) make it appear as if that user signed any document. So, everyone has to trust the signing service. On the other hand, if the user was capable of managing their own keys, they probably wouldn't need a service like Docusign, they would simply use PGP or something similar.
    – mti2935
    Commented Dec 10, 2015 at 15:22
  • What might work well is a web-based digital signing service, where all the crypto (including key generation, the signing, etc.) is done client-side - a la the way Proton Mail does the crypto for its secure mail service. That way, the provider never has the users' private keys used for signing documents. At most, the provider would have an encrypted copy of the private key that they would store on behalf of their users, but this key is encrypted/decrypted (e.g. using AES) client-side using a password that is never sent to the provider's server.
    – mti2935
    Commented Dec 10, 2015 at 18:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .