ADSS Admin Guide

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
7. E-Passport LDS

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:

• PDF Basic (Part 2 - based on ISO 32000-1): This is the basic PDF signature format verifiable in Adobe Reader 7+.
• PDF 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).
• PDF 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 to support European requirements for qualified electronic signatures. ADSS Signing Service partially supports the EN 319 142-1 (baseline) and the EN 319 142-2 (extended) versions. 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 BES 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-LT (Long term availability of validation data): This adds the revocation status information of the signer's certificate chain. These signatures aim to tackle the long term availability of the validation material.
• 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.

PAdES Supported Attributes:

Below are the list of attributes that are currently being supported in PAdES signatures for both Baseline and Extended versions. It includes attributes from PAdES-BES, PAdES-EBES, PAdES-T, PAdES-BLT and PAdES-LTA. 

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 (XAdES-BES with Timestamp Signature)
• XAdES-C (XAdES-T with Complete Validation Data References)
• XAdES-X (XAdES-C with Extended Validation Data)
• XAdES-X-L (XAdES-X with Long-term Validation Data)

Note: Above mentioned signatures have been explained below inside XAdES Signatures section. 

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 to support European requirements for qualified electronic signatures. ADSS Signing Service partially supports the EN 319 132-1 (baseline) and the EN 319 132-2 (extended) versions.

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: A XAdES-BES standard compliant basic signature provides requirements for the incorporation of signed and some unsigned qualifying properties when the signature is generated.
• XAdES-T (XAdES-BES with embedded timestamp): A Timestamp is added from existing TSA to XAdES-BES signature to ensure the signature itself existed at a certain date and time.
• XAdES-C (XAdES-T with Complete Validation Data References): XAdES-C is an extended version of XAdES-T on which qualifying properties containing references to certificates and references to status data value are added.
• XAdES-X-L (XAdES-X with Long-term Validation Data): XAdES-X-L ia an extended version of XAdES-X which are built on which qualifying properties containing certificates and revocation values are added.
• XAdES-A (XAdES-X-L with Archive Validation Data): In case of XAdES-A; XAdES-C, XAdES-X and XAdES-X-L are being created first. XAdES-A is created by adding ArchiveTimeStamp in above mentioned signatures.

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.

XAdES Supported Attributes:

Below are the list of attributes that are currently being supported in XAdES signature for both Baseline and Extended versions. It includes attributes from XAdES-BES, XAdES-EBES, XAdES-T, XAdES-ET, XAdES-LT, XAdES-ELT, XAdES-LTA and XAdES-ELTA:

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  to support European requirements for electronic signatures. ADSS Signing Service partially supports the EN 319 122-1 (baseline) and the EN 319 142-2 (extended) versions. 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 (Basic short-term signatures): 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 (CAdES-BES with 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 (CAdES-T with 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 (CAdES-C with 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 (CAdES-C with 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 (CAdES-X with 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 (CAdES-X-L with 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):
  
  

CAdES Supported Attributes:

Below are the list of attributes that are currently being supported in CAdES signature for both Baseline and Extended versions. It includes attributes from CAdES-BES, CAdES-EBES, CAdES-T, CAdES-ET, CAdES-LT, CAdES-LTA and CAdES-ELTA:

S/MIME Signing

S/MIME Signatures: Use this option for standard email signatures (as used by most email applications such as Microsoft Outlook®).

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.


E-Passport LDS
E-Passport also known as an electronic Machine Readable Travel Document (eMRTD), contains a contactless chip onto which the passport holder's personal information and biometrics are stored. To ensure the integrity and authenticity of this information, it is digitally signed by a Document Signer (DS). ICAO has defined a special structure to store data on the chip that is called LDS (Logical Data Structure). The LDS consists of different data groups where each group contains specific information related to the user. The signature computed on the LDS is a CMS signature based on RFC 3369. 
So this signature type is used to sign the E-Passport chips data according to RFC 3369 and ICAO guidelines.