What you will need to know about PDF digital signatures
First some vocabulary – this important because the terminology overlaps and isn’t always compatible.
An X509 Certificate (aka, PKCS 7 or 12) which represents a digital identity
A collection of Certificates that are related. A single cert on its own is useless as anyone can make them day in/day out. The chain represents a string of trust. Basically, the 2nd element says the first is OK and the 3rd says you can trust the 2nd.
Signing or applying a digital signature
This means to take the data from a Certificate or Certificate chain and apply it to a SignatureWidgetAnnotation such that the resulting PDF document can be verified to have been signed by the owner of the Certificate.
Certifying or Certification
This means applying a signature to a signature widget annotation in a PDF document for the purpose of expressing “this document, at the time of signing, is exactly how I intended it to be”. There can be no more than 1 certification signature applied to a document.
Example: I write a contract to be sent out for signing by multiple parties. When they receive the document, each party will understand that the content of the document is exactly as I produced it and the signing parties have been prevented from modifying it.
Second – what we do, what we don’t do, why, and how.
We are now providing the following new capabilities:
The only way to certify a PDF is through PdfDocument or PdfGeneratedDocument.
There is a new property, DocumentCertification, which contains the information necessary to certify the document. PdfDocument has very limited control over how the certification will appear, but that’s OK because most people certify a document by using an invisible signature widget annotation. PdfGeneratedDocument lets you make the signature look however you’d like.
At save, the document will be certified.
NOTE: You cannot and you will never be able to sign an existing signature widget annotation with either of these tools.
Why? Both PdfDocument and PdfGeneratedDocument rewrite the entire document. If the document had been previously certified or signed, this will destroy the certification.
Get Signature Information
Using PdfDocumentSigner, you can generate a PdfDocumentSignatureInformation object. We root through the PDF and pull out all the information that we can about the certification and signatures within the file letting you know if the document has been certified, if it has been signed, where all signatures are (signed or unsigned), and what errors were encountered in the process of digging this information out. Getting this info is as cheap as I could make it.
You cannot and you will never be able to repair a signed PDF. Repairing a PDF that is signed or certified will invalidate the signature.
You cannot construct PdfDocumentSignatureInformation directly, instead it gets factory built by PdfDocumentSigner.
Signing is always done with the PdfDocumentSigner class. PdfDocumentSigner is, in many respects very similar to PdfGeneratedDocument except that it gives you access only to the Form and to the Annotations. When you open a PDF in PdfDocumentSigner, you will see the same PdfForm object that you see in PdfGeneratedDocument and you will see a collection of collections called PagesOfAnnotations, which represents all the annotations on all the pages of the document. In addition, there is a PdfDocumentSignatureInformation.
When documents are certified, you can set how the document may or may not be subsequently changed. For example, you can specify no changes or no changes except for filling in form fields or no changes except filling in form fields and editing annotations.
We reflect this by locking everything that comes in in accordance with these rules.
For example, if you are only allowed to fill in forms, the collections that represent all annotations and fields will be read-only.
When you sign a document with PdfDocumentSigner, the changes are always appended onto the end of the document. This ensures that all existing signatures and the certification will remain intact (something PdfDocument cannot guarantee ever).
PdfDocumentSigner allows two actions:
Appending changes (which reflects any allowed changes made to annotations) – we sort through all the annotations and fields, find the changes (new content and edited old content) and append those to the PDF. This is only allowable when the cert specifies “fill in fields” or “fill in fields and edit annotations”.
Signing signatures and appending changes – this action will associate Certificates with SignatureWidgetAnnotations, then it calls the routine to append changes.
Once either signing or appending changes has been completed, the PdfDocumentSigner object is dead and can’t be used again. This is security-related and intentional.
The validation process (which is done through the PdfDocumentSignatureInformation object goes through all the PDF-centric items surrounding the signatures in the document and categorizes and presents them. For example, we verify that the file hashes are correct to detect changes. We check to see if someone edited a field they shouldn’t have, or added pages, or removed pages, or any other nasty little trick.
We do NOT validate the X509Certificates that we retrieve from the file. That is a big job and is out of our scope of expertise. We do, however, present you with X09Certificate2 objects, so it is your responsibility to manage / validate these in code as you see fit.
In order to use any of the signing features, you need a license for our DotPdf product. That would mean a serial number that begins with PDFG for SDK licensing or PDFX2 for server licensing. Please contact your sales rep or create a support case if you are unsure as to whether your current licenses support PDF Digital Signatures.