ADSS Admin Guide

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 an extended format

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.

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

• XAdES-BES -> XAdES-T, XAdES-C, XAdES-X, XAdES-X, 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 
• (An existing XAdES-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: Only the first signature within the document is converted using this mechanism.

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-C
• XAdES-X
• XAdES-X-L
• XAdES-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)
• RipeMD128, RipeMD160

SHA256 is recommended

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
• Detached

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"

3. Signature Policy User Notice

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