Add a DocTimeStamp signature on Server/Desktop

When providing trusted certificate(s) through the VerificationOptions.AddTrustedCertificate method, ensure that it is the root certificate corresponding to the chain used by the timestamp authority to sign the timestamp token.

Check your Certificate Authority's website for a list of root certificates they have publicly available, and choose the root certificate corresponding to the set of certificates that have been signed by that root certificate for your usage.

To add a DocTimeStamp signature:

using (PDFDoc doc = new PDFDoc(in_docpath))
{
	DigitalSignatureField doctimestamp_signature_field = doc.CreateDigitalSignatureField();
	TimestampingConfiguration tst_config = new TimestampingConfiguration("URL_to_timestamp_authority");
	VerificationOptions opts = new VerificationOptions(VerificationOptions.SignatureVerificationSecurityLevel.e_compatibility_and_archiving);
	/* It is necessary to add to the VerificationOptions a trusted root certificate corresponding to 
	the chain used by the timestamp authority to sign the timestamp token, in order for the timestamp
	response to be verifiable during DocTimeStamp signing. */
	opts.AddTrustedCertificate(in_trusted_cert_path);
	/* By default, we only check online for revocation of certificates using the newer and lighter 
	OCSP protocol as opposed to CRL, due to lower resource usage and greater reliability. However, 
	it may be necessary to enable online CRL revocation checking in order to verify some timestamps
	(i.e. those that do not have an OCSP responder URL for all non-trusted certificates). */
	opts.EnableOnlineCRLRevocationChecking(true);

	SignatureWidget widgetAnnot = SignatureWidget.Create(doc, new Rect(0, 100, 200, 150), doctimestamp_signature_field);
	doc.GetPage(1).AnnotPushBack(widgetAnnot);
	Obj widgetObj = widgetAnnot.GetSDFObj();

	// (OPTIONAL) Add an appearance to the signature field.
	Image img = Image.Create(doc, in_appearance_img_path);
	widgetAnnot.CreateSignatureAppearance(img);

	Console.WriteLine("Testing timestamping configuration.");
	TimestampingTestResult config_result = tst_config.TestConfiguration(opts);
	if (config_result.GetStatus())
	{
		Console.WriteLine("Success: timestamping configuration usable. Attempting to timestamp.");
	}
	else
	{
		// Print details of timestamping failure.
		Console.WriteLine(config_result.GetString());
		if (config_result.HasResponseVerificationResult())
		{
			EmbeddedTimestampVerificationResult tst_result = config_result.GetResponseVerificationResult();
			Console.WriteLine("CMS digest status: %s\n", tst_result.GetCMSDigestStatusAsString());
			Console.WriteLine("Message digest status: %s\n", tst_result.GetMessageImprintDigestStatusAsString());
			Console.WriteLine("Trust status: %s\n", tst_result.GetTrustStatusAsString());
		}
		return false;
	}

	doctimestamp_signature_field.TimestampOnNextSave(tst_config, opts);

	// Save/signing throws if timestamping fails.
	doc.Save(in_outpath, SDFDoc.SaveOptions.e_incremental);
}

Digital signatures
Full code sample which demonstrates using the digital signature API to digitally sign, certify, and/or verify PDF documents.

If it is important that a signature in a document have a timestamp that is verifiable with a third-party entity (i.e. Certificate Authority), then performing DTS would allow verification of when the document was signed. A Certificate Authority that hosts a timestamp server publicly is known as a Timestamp Authority (TSA). Timestamping a signature can be achieved by sending a hash of the signature data to the TSA's timestamping server ( which is what is achieved with the above code sample). If the request is deemed valid, the server will combine the hash provided by the client and an authoritative date-time of timestamping, signed by a private key from the Certificate Authority. The Timestamp Token is then recorded into the document alongside the signature.

If future viewers that open the timestamped and signed document have the same TSA as part of their trust list, then the viewer's PDF viewing application will acknowledge that the signature has been verifiably timestamped.

A chain of certificates, starting with a root certificate, an intermediate certificate and an end-entity certificate, forming a linked path of validation and verification from a trust anchor (i.e. Certificate Authority) down to an end-entity certificate. As the name implies, a root certificate is analogous to the root of a tree, where each branch of the tree is it's own chain of trust.

Note that "chain of trust" is also sometimes known as a "trust path"

A root certificate is the top-most certificate in a chain of trust/trust path, the private key of which is used to "sign" other certificates. All certificates signed by the root certificate inherit the trustworthiness of the root certificate.

Act as a middle-man between the protected root certificate and the end-entity certificate. Note there is always at least one intermediate certificate in a chain of trust, but there could be more than one.

The last in a chain of trust (i.e. a leaf node of the tree) that identifies either a business, a website, or a person. With respect to digital signatures, identifying the individuals who signed a document is where the trust worthiness of the chain(s) (i.e. where the end-entity certificates originated from) is important.

A trusted third party acting as the authoratative entity providing a timestamp, via a timestamp token. Clients who contact a TSA server will create a hashed value (as a unique identifier of the data or file that needs to be timestamped), and send the hashed value to the TSA.

More information about TSAs can be read about in the Time-Stamp Protocol (RFC 3161) industry standard.

A combination of the hash provided by the client and the authoritative date-time of timestamping, digitally signed with the TSA's private key, that is received by the client, and recorded into the document.

Future client applications who open the document will use the TSA's public key to

1. Authenticate the TSA
2. Re-calculate the hash of the original data

This new hash is compared to the originally created hash, and if any changes to the data has been made since the timestamp was originally created, then a warning should be raised by the client application.