Within the Signing Profile configuration the following form is presented if XML Dsig signatures were selected (each option is discussed in the table below):



The configuration items are as follows:

Items

Description

Signature Settings

Select the signature format to be produced. For more details see the section Supported Signature types

Timestamp (TSA) Settings

Select the required timestamp authority (or potentially several authorities) from the list of pre-registered TSAs. The configuration of TSA address(es) is described in this section: Configuring Time Stamp Authorities (TSA).

Note: Following rules are applied:

  • If the issuer CA of the signing certificate in Trust Manager have one or more configured associated TSA there then this overrides any TSAs defined in this signing profiles.
  • If the issuer CA of the signing certificate in Trust Manager have not configured an associated TSA there then the TSAs configured in the signing profiles will be used.

Enhance existing signature to baseline and extended formats

When the signing service receives data or a hash to sign, this option is ignored. This is a special option to be used only when the business application send data with a basic signature to the service in order to have it extended to a long-term format. The recommended approach is to use the Verification Service for this so that the signature can be checked first and then extended.

Legacy Signatures:

If this option is to be used, then the following legacy signatures can be converted as follows:

  • XAdES-BES -> XAdES-T, XAdES-C, XAdES-X, XAdES-X-L, XAdES-A
  • XAdES-T -> XAdES-C, XAdES-X, XAdES-X-L, XAdES-A
  • XAdES-C -> XAdES-X, XAdES-X-L, XAdES-A
  • XAdES-X -> XAdES-X-L, XAdES-A
  • XAdES-X-L -> XAdES-A
  • XAdES-A -> XAdES-A


Baseline Signatures:

If this option is to be used, then the following baseline signatures can be converted as follows:

  • XAdES-B-B -> XAdES-B-T, XAdES-B-LT, XAdES-B-LTA
  • XAdES-B-T -> XAdES-B-LT, XAdES-B-LTA
  • XAdES-B-LT -> XAdES-B-LTA
  • XAdES-B-LTA -> XAdES-B-LTA 


Extended Signatures:

If this option is to be used, then the following extended signatures can be converted as follows:

  • XAdES-E-BES -> XAdES-E-T, XAdES-E-C, XAdES-E-X, XAdES-E-X, XAdES-E-A
  • XAdES-E-T -> XAdES-E-C, XAdES-E-X, XAdES-E-X-L, XAdES-E-A
  • XAdES-E-C -> XAdES-E-X, XAdES-E-X-L, XAdES-E-A
  • XAdES-E-X -> XAdES-E-X-L, XAdES-E-A
  • XAdES-E-X-L -> XAdES-E-A
  • XAdES-E-A -> XAdES-E-A 
  • (An existing XAdES-E-A signatures can again be archived multiple times as needed. Successive time-stamps protect the whole material against vulnerable hashing algorithms or the breaking of the cryptographic material or algorithms). 

Note:  

  1. The Only the first signature within the document is converted using this mechanism.
  2. If business application requests a parallel signature by sending an already signed document then a new signature will be produced instead of enhancing the existing signature in the document in such a scenario this checkbox functionality will be ignored

Signature Grace Period

This will define how long ADSS Server should wait after the signing time indicated in the signature (either by TSA or by signer's local time) before converting the basic signature to an advanced signature.

Note: The default value set to '0'. The value '0' indicates that do not consider signature grace period while converting to advanced signature type.

Revocation Status Information Unavailable Error

If one of following signature types are selected:

  • XAdES-E-C
  • XAdES-E-X
  • XAdES-E-X-L
  • XAdES-E-A

Then an extra check box is offered to decide if ADSS Server should return an error if it cannot embed the revocation information when creating the Long-Term signature.

Such signatures  require embedded status/ revocation information for the signer's certificate chain. This is useful to stop basic signatures being created when a communication failure prevents revocation information being obtained from external resources.  If this check box is not selected then the signature will be produced but it may not contain the embedded revocation if this was unavailable at the time of signing, e.g. if the relevant OCSP is not responding or if the dynamic CRL is unavailable. ADSS Server is generally configured to cache CA CRLs locally and it also has a short-life cache for dynamic CRLs and OCSP responses.

Note: It is recommended you always tick this box.

Hashing Algorithm

Select which hash algorithm to use as part of the signature creation process. The following algorithms are supported:  

  • SHA1
  • SHA2 (SHA224, SHA256, SHA384, SHA512)
  • SHA3 (SHA224, SHA256, SHA384, SHA512)
  • RipeMD128, RipeMD160

SHA256 is recommended

SHA3 Hashing Algorithm is only supported with RSA and PSS padding schemes in case of XML/XAdES and Office Signatures.

Signature/Document Relationship

This defines how the signature is to be provided. Either the signature can be wrapped around the data or provided separately. The following options are supported:

  • Enveloping
  • Enveloped

Canonicalization Method

Select the Canonicalization algorithm that will be used to canonicalize the XML before computing the hash. One of the following algorithms can be selected:

  • Inclusive (http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
  • Exclusive (http://www.w3.org/2001/10/xml-exc-c14n#)

Note: By Default 'Inclusive' will be selected.

XML Part Signing

This defines how a specific element can be signed in the XML document. Element can be defined individually or via XPath. Multiple signing elements can also be added. XPath uses path expressions to select nodes or node-sets in an XML document. XPath uses path expressions to navigate in XML documents. XPath can be set in number of ways. If checkbox is enabled and the system is unable to find the defined XML signing element then it will return an error. 

If signature/document relationship is Enveloped then XML part signing settings will be enabled.

Xpath Examples:

/root/books/author

//publisher

EPES signature

Explicit Policy Based Electronic (EPES) signature settings are only available for the XAdES signature types. By enabling the check box Add Signature Policy Identifier, the signing profile can be used to produce (EPES) signatures where a signature policy OID, URI and user notice are added in the digital signature as specified below:

1. Signature Policy Object ID

Provide the Signature Policy OID to be added for EPES signatures.


2. Signature Policy URI

Provide the Signature Policy URI to be added for EPES signatures.

If there is no Policy URI defined inside the signing profile then EPES configurations should be made in policy.properties file located at: [ADSS Installation Directory]/service/


Open this file in any text editor and enter policy OID and path to the policy document 

e.g. 1.2.3.4.5 = "F:/Policy_File"

The ADSS Signing Service can retrieve the signature policy document in either one of the following ways:

  • Using Policy URI defined in signing profile. The ADSS Signing Service uses this policy URI to retrieve the online available policy document. Its hash value is calculated and embedded in the signed properties of the signature.
  • Using a locally configured signature policy document. The ADSS Signing Service uses this text file pointer to retrieve the local policy document, hashes it and embeds it in the signed properties of the signature.


3. Signature Policy User Notice

You must provide a user notice to be added to the EPES signatures produced.


See also

PDF/PAdES Signing Attributes

PDF/PAdES Hash Signing Attributes
Microsoft Office Signing Attributes
PKCS7 Signing Attributes
CMS/CAdES Signing Attributes
S/MIME Signing Attributes