ADSS Server supports these signature types:

  1. PDF Signing
  2. Microsoft Office Signing
  3. XML Signing
  4. File Signing
  5. S/MIME Signing
  6. PKCS#1 Signing



PDF Signing 

PDF is a common business document format and therefore PDF signatures are the ideal choice when human users need to view and sign documents. Standard PDF signature formats exist (e.g. ISO 32000-1 and ETSI PAdES), which means PDF documents signed using ADSS Server can be verified using other third party PDF software including the ubiquitous Adobe® Reader.

At a high-level ADSS Server supports both PDF Certify signatures and PDF Approval signatures. A certify signature is a special type of PDF signature in which certain restrictions can be applied while signing; e.g. No Changes Allowed, Allow Form fill-in and digital signatures, Allow Annotations, Form fill-in and digital signatures. The PDF specifications only allow a certify signature to be applied if it’s the first signature on a document. An approval signature is any normal digital signature which does not specify any restrictions.


ISO 32000-1 Signatures:

  • PAdES Basic (Part 2 - based on ISO 32000-1): This is the basic PDF signature format verifiable in Adobe Reader 7+.
  • PAdES Basic with embedded timestamp: As above but ADSS Server will also embed a timestamp from a trusted TSA - this helps to independently prove the time of signing. The configuration of TSA address(es) is described in this section: Configuring Time Stamp Authorities (TSA).
  • PAdES Basic with embedded timestamp and revocation information: As above but ADSS Server will embed the revocation information of the signer's certificate chain within the signature – this helps to prove the status of the signer’s certificate at the time of signing. Such signatures support Long Term Validation (LTV) as they can be successfully verified even after the signer’s certificate expires.


PAdES Signatures:

PAdES stands for “PDF Advanced Electronic Signatures” and is a set of standards published by ETSI (TS 102 778 parts 1 to 5) to support European requirements for qualified electronic signatures. The purpose is specifically for long-term validation, i.e. the ability to successfully verify signature later, even years or decades after signing. PAdES signatures formats are based on the ETSI CAdES signature formats, this allows such PDF signatures to be extended for long-term validation by either the signer at time of signing or later by relying parties.

ADSS Server supports these PAdES signatures formats: 

  • PAdES-BES (Part 3 - PAdES Enhanced): A PAdES standard compliant basic signature. These signatures are PAdES Part 3 compliant.
  • PAdES-EPES: As above but ADSS Server also embeds the signature policy information at the time of signing. These signatures are also PAdES Part 3 compliant.
  • PAdES Basic with embedded timestamp: This adds a signature timestamp to the above format. This timestamp is from a trusted TSA which provides independent proof of the time of signing. The configuration of TSA address(es) is described in this section: Configuring Time Stamp Authorities (TSA). These signatures are also PAdES Part 3 compliant.
  • PAdES-LTV (Part 4 - Long Term): This adds the revocation status information of the signer's certificate chain and an outer document timestamp protecting all the evidence inside. Such signature supports Long Term Validation (LTV). The outer document timestamp protects the whole evidence material inside from expiry, so such signatures can be verified up to the expiry of the outer document timestamp. These signatures are PAdES Part 4 compliant. Note from a technical perspective these are equivalent to a CAdES-X-Long signature.


PDF Hash Signing: 

ADSS Server is also able to sign just the hash of a PDF document. This is advantageous where the business application does not want to send the whole PDF to ADSS Server for reasons of confidentiality or performance. The PDF hash is usually created via the ADSS Client SDK, (or Auto File Processor) and this hash is sent to ADSS Server for signing. When the signed hash is returned, the ADSS Client SDK assembles this back within the PDF and then returned the signed PDF to the business application.

NOTE: This PDF hash signing approach is not supported for PAdES-LTV signing because ADSS Server needs to receive the whole PDF in order to embed the revocation information and document timestamp. These objects are not embedded inside the signature dictionary but elsewhere in the PDF document.


Microsoft Office Signing

Microsoft Office signatures can be created for Office Word/Excel 2013 (ISO/IEC 29500-2) documents. Word/Excel documents signed using ADSS Server are fully compliant with Office Word/Excel 2013 and vice versa. Basic and long-term formats are supported including:

  • XAdES-BES
  • XAdES-T (Signature Timestamp))
  • XAdES-C (Complete Validation Data References)
  • XAdES-X (Extended Validation Data)
  • XAdES-X-L (Long-term Validation Data)

XAdES-X-Type 2 signatures and Archive signatures are not supported by Office Word/Excel 2013. These extended ETSI signature formats are explained in further detail in the CMS section below.



XML Signing

ADSS Server supports ETSI XAdES signature formats, XAdES stands for “XML Advanced Electronic Signatures” and is a set of standards published by ETSI (TS 101 903) to support European requirements for qualified electronic signatures. The purpose is specifically for long-term validation, i.e. the ability to successfully verify signature later, even years or decades after signing.

XML Dsig Signatures:

This format allows XML to be hashed and signed by generating a XML Dsig signature. 


XAdES Signatures:

ADSS Server supports these XAdES signatures formats (these are explained in the CAdES formats discussed below):



  • XAdES-BES
  • XAdES-T (Signature Timestamp))
  • XAdES-C (Complete Validation Data References)
  • XAdES-X (Extended Validation Data)
  • XAdES-X-L (Long-term Validation Data)
  • XAdES-A (Archive Validation Data)


ADSS Server also supports the original W3C XML DigSig standard with modes:

  • Enveloping: The original XML file is contained inside the signature.
  • Enveloped: The XML signature is embedded within the original XML file.



File Signing 

File Signing is the term used to describe traditional binary-based ASN.1 signature formats. ADSS Server supports the historical signature formats in this category (i.e. PKCS#7 and CMS) and also the latest CAdES formats. It is recommended to use CAdES formats unless the older signature formats are required for backward compatibility. The type of supported signature can be further defined as:

  • Enveloping: The original file is contained inside the signature.
  • Detached: The signature contains just the hash of the original file.


Following signature types are supported for File signing:


PKCS#7 Signatures: 

This format allows any type of file to be hashed and signed by generating a PKCS#7 signature. In this category both enveloping signatures (the original file is contained inside the signature) and detached signatures (the signature only contains the hash of the original file) are supported.


CMS Signatures: 

This format allows any type of file to be hashed and signed by generating a CMS signature. CMS is essentially a later version of the PKCS#7 signature format. Both enveloping signatures and detached signatures are supported.


CAdES Signatures:

CAdES stands for “CMS Advanced Electronic Signatures” and is a set of standards published by ETSI (TS 101 773) to support European requirements for electronic signatures. The purpose is specifically for creation of Long-Term signatures that are verifiable for years or even decades. CAdES specifies the use of signature formats for signing the file content. So the use of CAdES signatures will allow these signatures to be extended by either the signer or relying parties to ensure that signatures can be verified for as long as is necessary. Following are the different standard CAdES signatures formats:

  • CAdES-BES: This allows any type of file to be hashed and signed by generating a CAdES-BES signature. This is illustrated as follow:
  • CAdES-EPES: As above but the Signature Policy ID information is also added to the signature as a signed attribute. This is illustrated as follow:


  • CAdES-T (Signature Timestamp): As above but ADSS Server also adds a timestamp from a trusted TSA - this helps to independently prove the time of signing. The configuration of TSA address(es) is described in this section: Configuring Time Stamp Authorities (TSA):
  • CAdES-C (Complete Validation Data References): This adds the complete-certificate-references and complete-revocation-references attributes. The complete-certificate-references attribute contains references to all the certificates present in the certification path used for verifying the signature. The complete-revocation-references attribute contains references to the CRLs and/or OCSP responses used for verifying the signature. Storing the references allows the values of the certification path and the CRLs or OCSPs responses to be stored elsewhere, reducing the size of a stored electronic signature.
  • CAdES-X (Extended Validation Data) Type1: This adds a time-stamp token on the CAdES-C itself to provide trust over all the elements and references. This protects the certificates, CRLs, and OCSP responses in case of a later compromise of a CA key, CRL key, or OCSP issuer key.
  • CAdES-X (Extended Validation Data) Type2: This adds to the CAdES-C format the CAdES-C-time-stamped-certs-crls-references attribute, whose content is a time-stamp token on the certification path and revocation information references. This provides integrity and trusted time protection over all the references. This may protect the certificates, CRLs and OCSP responses in case of a later compromise of a CA key, CRL key or OCSP issuer key. Note Type 1 and Type 2 are essentially very similar and protect against the same threat.
  • CAdES-X-L (Long-term Validation Data): This can be based on either Type 1, Type 2. CAdES-X Long adds the certificate-values and revocation-values. Certificate-values contain the whole certificate path required for verifying the signature; the revocation-values contain the CRLs and/or OCSP responses required for the validation of the signature. This provides a known repository of certificate and revocation information required to validate a CAdES-C and prevents such information from getting lost.
  • CAdES-A (Archive Validation Data): CAdES-A builds on a CAdES-X Long Type 1 or 2 by adding one or more archive-time-stamp attributes. This form is used for archival of long-term signatures. Successive time-stamps protect the whole material against vulnerable hashing algorithms or the breaking of the cryptographic material or algorithms (i.e. each outer timestamp can use stronger algorithms or key lengths):


PKCS#1 Signing

PKCS#1 signatures are the lowest level digital signature format often referred to as a “raw” signature. It is created over the document hash using the signer’s private key. This basic PKCS#1 signature is the core element within the other signature formats explained above.

See also

Document Signing Configurations

Certificate Generation Configurations
PKCS10/CSR Creation