For fun, I recently build a e-signature web app to allow users to add a handwritten signature to PDF (IE signing a TOS agreement).
It only took a couple minutes of research to realize my method of just added a written signature image to a PDF probably wouldn't hold up very well in a legal dispute.
A cryptographic digital signature is needed to verify the identity of the signee as well as ensure the document has not been altered since signing.
It got me wondering how companies like Docusign can provide digital signatures without having a certificate from the signee.
I found this marketing heavy explanation where it says that they are considered a trusted CA themselves.
Does this mean Docusign is issuing certificate to the users who are signing for them to sign with?
Even that you just need a link to a document envelope to sign (in most cases), this doesn't seem very meaningful.
UPDATE
Looks like you can "verify" signatures using acrobat reader to see the details. I opened up a PDF that I recently signed on Docusign and it appears that docusign is the signing identity?
Maybe I'm confusing "adding an e-signature" with "digitally signing", but shouldn't I be the Signed By __ identify?
Re: It got me wondering how companies like Docusign can provide digital signatures without having a certificate from the signee.
Answer: DocuSign enables three different types of electronic signatures:
Simple Electronic Signatures (SES) are legal in the US and other common law countries for many purposes. They don't require a digital cert from the signer.
Advanced Electronic Signatures (AES) are a digital signature which provides a guarantee that the signer was identified by a digital cert and that the signed document has not been changed since it was signed. This type of signature is required for some purposes in common law countries (like the US) and for many purposes in civil law countries.
Qualified Electronic Signatures (QES) are like AES signatures but the signer cert is granted by a company that is authorized directly or indirectly by a government authority.
How it works
If the DocuSign signature is an SES signature then no signer cert is needed. And yes, these types of signatures are valid and legal for most any type of transaction in the US. See a lawyer for details on whether your transaction type can use this type of eSignature or not. Here is a summary of the law for the US.
For these types of signatures, when you download the signed document from DocuSign, the downloaded document is digitally signed (using an AES signature) by the company DocuSign. The DocuSign AES signature assures you that the document is the same as the document that was signed by one or more signers who used SES via DocuSign.
For AES signatures via DocuSign, the signer can use a cert that is issued to them by DocuSign. Or the signer can use a cert issued to them by their associated company/organization.
For QES signatures via DocuSign, the signer's cert comes from a qualified trust provider.
Re: Does this mean Docusign is issuing certificate to the users who are signing for them to sign with?
Yes, for AES signatures, DocuSign can issue a cert to a signer. But that is not what happened in your example screenshot. In your screenshot, DocuSign enabled the signer to use a SES eSignature. DocuSign then provided an AES signature to guarantee to any relying party that the document was SES signed via DocuSign.
Related
I've been looking for guidelines regarding my question to no avail because I couldn't think of a proper combination of keywords to filter out irrelevant results.
Suppose I have issued a document in some PDF format, signed by an implementation of some digital signature technology. The validity of the document is contingent upon the holder complying to certain rules. Once such compliance has been found to be broken, I'd like to revoke the document. How do I go about doing that?
I don't want to revoke my 'digital certificate' (of the X.509 kind) associated with the signature of that document. I just want to invalidate the document, whose invalid status would be apparent upon verification.
If I were to go the Verifiable Credentials route instead, the scenario can be implemented through the property credentialStatus along with some revocation infrastructure. I'm trying to think of an equivalent way in the conventional PDF world. Could you please give me some pointers?
You cannot revoke the document as revocation mechanisms are only specified and implemented for identities (better said certificates unsing trust chains and certificate revocation lists - see RFC5280).
X.509 certificate has signature value.
I want to verify the signature in client certificate with public key of root CA or intermediate CA.
I know the information of both of them. But I don't know what messages needed.
I want to ask what's the messages needed to generate the signature value?
It only need Issuer information or Subject Name by hex? or is the issuer arbitrary when generating a certificate?
Verifying the signature is not sufficient, you need to validate the certificate chain and all of the associated policy constraints. In Windows / C you would use CertGetCertificateChain(https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certgetcertificatechain), but each platform has its own approach to this problem. Its far more complicated than most realize (https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf) so please stick to platform APIs for this validation.
I'd like to create a X.509 public key certificate to verify signatures, esp. JWT Tokens.
I'd like to know which properties and extensions properties to set to which values on the certificate to restrict it for JWT verification.
Unfortunately, the specification of X.509 extensions is pretty verbose. So, I'd also be very thankful for a brief overview of available X.509 extensions, properties and their meaning.
JWT signing and validation with asymmetric keys is done using exclusively a key pair, not certificates. It is only needed a public key to validate the token signature.
The public key can be contained in a certificate in order to be sent to the verification party, but this is not really needed, and the recipient is not obliged to perform the validation with respect to any attribute or extension that the X509 certificate may have.
The type of certificate extensions you need to enforce such restriction is... Key Usage and/or Extended Key Usage extensions. For any kind of digital signature, you need at least the Key Usage called... digitalSignature, as specified in RFC 5280. Standard (Extended) Key Usage extensions are all specified in ยง 4.2.1.3 and 4.2.1.12 of the RFC.
You can always avoid certificates for the sake of simplicity, by maintaining a truststore (a static list) of public keys (or fingerprints if you want to optimize memory/disk usage) on the JWT verifier's side. But this has some limitations, such as:
No standard revocation mechanism: if the signing key has been compromised, how does the verifier become aware of that? With certificates, you have the possibility to revoke certificates, and verifiers use standard OCSP or CRL to verify the revocation status.
You have to know in advance all public keys potentially used for JWT signing. This is not always the case. (E.g. in some cases, all you want to know as a verifier is that the key belongs to some trusted organisation's entity and that it has been allowed for signing.)
If the list of public keys is/becomes too big, it is hardly manageable.
If the keys change too often (remember that keys should be renewed regularly), it is hardly manageable.
Therefore, if such limitations affect you, X.509 certificates offer a more scalable and flexible solution, but with an extra layer of complexity of course. With certificates, it works like this:
Each JWT issuer has a certificate issued by one or more Certificate Authorities (CA)
JWT verifiers should trust these CAs (list of trusted CAs), instead of trusting each JWT issuer's certificate specifically.
JWT include the signer's certificate (or certificate chain if you use sub-CAs) in the x5c header parameter of the JWS header as per RFC 7515 (X.509 Certificate Chain), so that the verifier can link the certificate (chain) to one of the trusted CAs.
I am currently using the latest version of iText and using the example from the Digital Signing White Paper by Bruno Lowagie.
When I sign a PDF and view it within Adobe Reader the Certificate Chain is not shown and the Signer cannot be validated. What do I need to do in order to include the Certificate Chain with the Signature so the Signature is automatically validated by Adobe?
The certificate comes from Entrust..which is a member of the Adobe AATL program. So I am expecting the Signature to be automatically verified without me having to change trust settings within Adobe reader.
The iText software does not add the intermediate certificate so the chain of trust is broken. Entrust is a member of aatl, but only sells cds certificates
I am using iText to apply digital signatures in PDF. The digitally signed PDF is showing message like "the validity of the document certification is unknown. The author could not be verified.At least one signature has problems." at the top.
When I add the certificate to my trust identities which is used to create signed PDF, then the generated signed PDF shows "Signed and all signatures are valid".
Is it possible to fix this by without adding certificate to trusted identities?
Thanks in advance.
There are two reasons for the message to be displayed.
First, it's that you used self-signed certificate or other certificate, whose certificate chain doesn't end with the root certificate, trusted by validating application.
Second is when the signature parameters are not set right and Reader doesn't know that it needs to look for certificates in Windows certificate store. I don't know how to specify what I mean in iText - in our SecureBlackbox there's a property for this.
Please read https://itextpdf.com/book/digitalsignatures
Section 3.4 is named "How to get a green check mark."
The short version: if you want a PDF that shows a green check mark without having to install a root certificate manually, you need at least a private key that is stored on a physical device such as a Hardware Security Module, a USB token or a smart card.
Do you have such a key? Did you ask your CA for CDS or AATL certificate?
Re: Is it possible to fix this by without adding certificate to trusted identities?
Answer: no, unless you switch to a digital signature cert that was granted by a Certificate Authority trusted by Adobe.
This is an on-going issue with Adobe since Adobe Reader doesn't trust the CA's in the operating system. -- Instead, Adobe has their own list.
So either:
You get a personal cert from one of the companies on the Adobe list.
You publish your organization's root certificate on your website and provide instructions to recipients on how to tell Adobe to trust you. (Your organization can have just one member if you wish.) See below for more on this.
You tell your recipients how to click on the Adobe signature toolbar to inspect the details of the signing cert (and ignore the scary default warnings from Adobe).
In the wet-signature world, there are cases where you simply sign something, and other cases where you need to provide a copy of your government issued identity document. Unfortunately, in the current digital signature world, it's as if every signature needs to be accompanied by a copy of your driver's license. And that is simply not reality.
A common and successful answer is to publish your organization's root cert for all of the organization's signers. See Apple and Wells Fargo examples.
You can publish your root cert on an SSL-protected page with a cert from a trusted CA. That will enable a business partner to feel secure about trusting that your org's root cert is really from your org.