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