PDF Java Toolkit

Digital Signatures in Java

The Java Cryptography Extensions (JCE) environment provides a mechanism by which third parties can implement their own providers for encryption, digests, and signature algorithms. PDF Java Toolkit uses the JCE where appropriate, including when generating digital signatures for the adbe.x509.rsa_sha1 subfilter.

This particular subfilter computes a simple digital signature using a SHA1 digest with RSA encryption. This can be computed using the class java.security.Signature. PDF Java Toolkit does not specify which provider of RSAWithSha1 should be used, but this can be controlled at the client installation by appropriate settings in the JVM’s Security policy file.

For PKCS#7-based subfilters—adbe.pkcs7.sha1 and adbe.pkcs7.detached—the JCE does not provide any interfaces for processing or building PKCS#7 packets. For PKCS#7 support, PDF Java Toolkit accesses the RSA cert-j library directly. The JCE does not provide support for processing ASN1-based structures, so the RSA asn1 library is accessed directly.

Private Keys, Certificates, and Keystores

To build a digital signature, the following components are needed:

  1. Data to be signed
  2. A private key to sign the data
  3. A public certificate that a recipient of the data and signature can use to verify the person who signed the data
  4. A certificate chain that allows the recipient to validate the signing certificate up to some trusted root certificate. PDF Java Toolkit uses JCE classes to represent private keys and certificates. PDF Java Toolkit requires certificates to be X509 certificates. Keystores are entities that store private keys and/or certificates. PDF Java Toolkit supports JCE keystore mechanisms as well.

The following JCE classes are used in PDF Java Toolkit.

  • security.PrivateKey
  • security.cert.X509Certificate
  • security.Keystore
  • security.MessageDigest


Timestamps on data that is digitally signed involves passing the digest to a timestamp server prior to encrypting the digest to create a digital signature. The digest passed to the timestamp server is itself digitally signed to provide authentication (at least with respect to the trust level of the signing timestamp server) and the digitally signed timestamp is then included into the PKCS# SignedData packed.


A Certificate Revocation List (CRL) is a static file that lists all of the certificates signed by a Certifying Authority (CA) that have been revoked.  A Certifying Authority, a vendor that provides a service of verifying the authenticity of signatures on electronic documents, might revoke a certificate because one of the certificates in a certificate chain has had its private key compromised. The certificate might be vulnerable to being misused, allowing someone to pretend to be the signer of a document.

CRL lists have several problems, however. CRL files are static and not standard mechanism exists for vendors to distribute updated copies to customers.  Also, since they are designed to be comprehensive, they would potentially grow to be quite large.


The Online Certificate Status Protocol (OCSP) was designed to overcome many of the problems with CRL files. OCSP defines a transaction protocol whereby a server can be queried to determine whether the certificates in a given set of certificates are still valid. OCSP defines both an OCSP request and an OCSP response. The OCSP response contains the validity of the certificate or certificates.