Signature
The Signature section of the admin console helps you define the different signature profiles and timestamp servers that are applied at the time of responding to the signature of a document made through the DSS signature service.
DSS profiles
This view provides a list of defined profiles, as well as functions for searching and filtering items.
A signature profile consists of a number of parameters that are applied or checked at the time of signing. Some of these parameters can have a forced value in the profile or offer a range of possible values to be chosen by the client. The following table shows the behavior of the signature service depending on whether a parameter is forced in the profile and/or the request specifies a specific value for that parameter.
| Forced Value | Range of values | |
|---|---|---|
| Request with specified value compatible with the profile | Signature with specified value / forced | Signature with specified value in the request |
| Request with specified value not compatible with profile | Return error | Return error |
| Request with unspecified value | Signature with value specified to the profile | Return error |
Signature creation wizard
General
The New button opens a wizard where you define the signature profile.
The first step is to choose a name for the profile, the status of the profile and the type of signature on which the profile will be based.
| Setting | Description |
|---|---|
| Name | Descriptive name of the profile. It must be unique, as it will be the identifier of the profile at the time of the signature request against the service |
| Status | Profile status (enabled/disabled). |
| Select a signature type | Select the signature type from CMS, XMLDSIG, XAdES, CAdES, or PAdES. |
Configuration
Depending on the type of signature selected, the following steps of the wizard will vary. The following section shows the configuration options for XAdES, which is the one that has all the possible configuration options.
| Section | Setting | Description |
|---|---|---|
| Levels | Force | Allows you to specify which signature level the profile must meet. Choose a possible set of levels or force a specific one. |
| Select the signature levels | CMS and XMLDSig: No levels | |
| XAdES and CAdES BES: basic form that simply meets the legal requirements of the directive for advanced electronic signature. EPES: basic form to which signature policy information has been added. T: (timestamp), adds a timestamp field to protect against repudiation. C: (complete), adds references to verification data (certificates and revocation lists) to signed documents to allow off-line verification and validation in the future (but doesn't store the data itself). X: (extended), adds timestamps to references introduced by C to prevent a certificate chain from being compromised in the future. XL: (extended long-term), adds the certificates and revocation lists themselves to the signed documents to allow verification in the future even if the original sources (certificate lookup or revocation lists) are no longer available. A: (archiving), adds the possibility of periodic (for example, every year) timestamping of archived documents to prevent them from being compromised due to signature weakness over a long storage period. | ||
| PAdES BES: basic form that simply meets the legal requirements of the Directive for advanced electronic signatures. EPES: basic form to which signature policy information has been added. LTV: This level allows a valid signature beyond the validity of the signing certificate itself. | ||
| Modes | Force | Allows you to specify the signature mode. Choose a possible set or force a value or one of them. |
| Allowed modes | Enveloped: (XMLDSig, XAdES, PAdES) The signature is inside the signed document itself. Enveloping: (CMS, XMLDSig, CAdES, XAdES) The signed document is inside the signature. Detached: (CMS, XMLDSig, CAdES, XAdES) The signature and the original signed document are in separate files. To validate the signature, it must always be accompanied by the original document. | |
| Algorithms | Signature | Allows you to choose a set of signature algorithms and a digest algorithm. The signature algorithms supported for each type are: RSA: (CMS, XMLDSig, CAdES, XAdES, PAdES) the most widespread type, it's valid for both encryption and signing. DSA: (CAdES, XAdES, PAdES) standard of the Federal Government of the United States of America, it's used for signing but not for encryption and requires more computation time than RSA. ECDSA: (CAdES, XAdES, PAdES) modification of DSA, uses operations on elliptic curve points. |
| Digest | The digest algorithms supported for each type are: SHA1: (CMS, XMLDSig, CAdES, XAdES, PAdES) Secure Hash Algorithm, second version of the system, produces a 20-bit digest. The use of this method is discouraged. SHA256 and SHA512: (CAdES, XAdES, PAdES) Two of the four functions of SHA2, which is the next version of SHA1, produce 32-bit and 64-bit summaries respectively. |
TSA (optional)
In this step you can choose the TSA (Time Stamp Authority) servers that the server can use to time stamp the signatures that require it. You can choose a primary and a secondary server, which will be used only if the primary one isn't available.
In case no TSA is chosen and the signature profile requires time stamping, the highest priority time stamping servers defined in the system will be used.
Refer to the TSAs section of this manual to configure and add time stamping authorities to the system.
Policy (optional)
In this step you can specify whether signatures should include a reference to their compliance with a particular signature policy and/or commitment. You can specify the policy using an OID identifier and/or a policy hash. You can also define the signing commitment type by adding an external ID.
The use of signature policies is restricted to level EPES and above.
Validation (optional)
Before signing a document, you can specify whether some validation is required. The types of validation available are Certificate Validation and Certificate chain validation.
The option Certificate Validation allows you to specify if the signing certificate needs to be validated before signing. If the certificate isn't valid the signature will fail. You can configure who performs this validation, by default it's done by the device itself, but it can be configured to be performed externally through a service provided by a third party.
The option Certificate chain validation gives the possibility to specify a set of certificates that the signing certificate must have within its chain of trust. If this isn't the case, the signature request is rejected. The certificates available for this chain are those found in the Local CAs section. This option allows you to restrict a signature's access to certificates issued only by a specific CA.
Profile management and versioning
Redtrust allows the versioning of signature profiles. Profiles are immutable, once created they can't be modified, which ensures the integrity of all signatures made with that profile. You can version the profile by modifying the required parameters. Since signatures include its version, any new requests will take into account the new parameters whilst including references to previous versions.
To create a version of a profile, hold the pointer over the profile and select Version.
This option opens a profile dialog box. You can edit the version parameters but not the name and type of signature.
The Version field indicates the version of the profile and data. The disable option is useful when you have multiple versions of the same profile, the version that's taken into account is the one enabled, leaving the other versions disabled.
Using the filter, you can choose to see only the active or recent profiles or see all versions.
TSAs
A Timestamp Authority (TSA) is a trusted third party that issues timestamps to verify the existence of a document or data at a specific point in time. These timestamps have to be secure to serve as proof of time for relevant transactions.
TSA creation
The TSA tab helps to create Time Stamp Authorities that comply with the RFC 3161 standard. You can include these authorities in the signature profiles as primary and/or secondary servers of the time stamp protocol.
The New TSA button opens a dialog box where you define the TSA. To register a new TSA, a name and the URL of the service must be specified. Optionally, if the service requires it, the policy to be used by the TSA and/or the Authentication data against the service can be specified.
| Setting | Description |
|---|---|
| Name | |
| URL | |
| Priority | Indicates which TSA will be used as a priority in case the profile doesn't specify any TSA but the signature you are trying to generate requires it. |
| Status | |
| Policy | |
| Authentication |
TSA management
The management, both individually and in bulk, of the TSA list items is done in the same way as in other sections of the admin console. By selecting multiple TSAs, they can be deleted or enabled/disabled as a group.
Clicking on a TSA opens a display window that allows the TSA data to be modified.