Tenant-specific configuration
The configuration for one tenant is done within the XML element “Tenant” and contains the following:
-
name
This is a technical label of a tenant. It is used in log files and to refer to one tenant via the administration interface.
-
enabled
Via this Boolean value a tenant can be activated or deactivated. For a deactivated tenant all operations of the ArchiSig-Module fail with an error.
-
HashTreeAlgorithms(deprecated for backward compatibility)
The element contains a list of hash value algorithms, which can be used to generate hash trees. In case HashTreeAlgorithms is still used in a configuration it must map to a tree with the same name as its algorithm with Default=true and ReadOnly=false (for compatibility).
-
HashTrees
This is a list of elements defining the hash trees. It is important to note that this list must not be confused with the list of active hash trees! For example, if a system was initialized with a hash tree with SHA-256 algorithm, in this list only a tree with algorithm SHA-256 is present. In the context of a renewal and recreation of a new hash tree with SHA-512, the tree having SHA-256 algorithm is finalized and locked (in a read only fashion), and only the tree having SHA-512 digest algorithm remains in usage, although this cannot be seen in the configuration. To retrieve a list of currently used algorithms, the administration interface provides a set of operations (Administration of the ArchiSig-Module).
-
HashTrees\HashTree
The element defines one hash tree. For each tree, on startup the ArchiSig-Module checks if a hash tree with this algorithm already exists in the system. If not, the ArchiSig-Module creates a new empty tree using the defined algorithm (see below).
-
HashTrees\HashTree\Name
This is the name of a hash tree. It must be unique for one tenant.
-
HashTrees\HashTree\Algorithm
The algorithm is referenced by its name according to the topic Identifiers for algorithms.
-
HashTrees\HashTree\ReadOnly
The element indicates if the tree is read-only which means that no new hashes can be stored in the queue and finally in the hash tree. Existent entries in the queue can be stored in the hash tree.
-
HashTrees\HashTree\Default
-
TriggerTimestampMaxUnstamped
This number represents the maximum number of hash values that can be queued for timestamp creation. The ArchiSig module regularly checks if this limit is exceeded. If it is, the timestamp creation is triggered automatically.
The number also defines the maximum number of hash values that can be combined into a single subtree. This is important if you have many hashes waiting in the queue. The value must be set carefully. If it is too large, the time to process incoming hashes can increase from seconds to minutes. More critically, the time to retrieve an evidence record can increase from milliseconds to dozens of seconds. If you need to retrieve thousands of evidence records to verify attachments, a subtree that is too large could pose a significant problem.This setting is optional. The default is 10.000.
-
TriggerTimestampMaxAgeMinutes
This number represents the maximum waiting period in minutes of a hash value in the queue. All hash values waiting for the creation of an initial archive timestamp, are regularly checked with respect to their waiting time. If this limit is exceeded, the creation of the initial archive timestamp is triggered.
For the configuration it is important to note that the TR-ESOR specification prescribes that the timestamp has to be created at least once a day. The setting is optional. The default is 1440 minutes (1 day).
-
AdminCertificates
The element exists for backward compatibility.
With respect to the definition of tenants the following conditions apply:
-
When putting the module into service at least one tenant must be configured.
-
The number of tenants is restricted to 63.
-
The tenant must exist in ImageMaster.
-
The names of the tenants must be unique.
The communication certificates of the administrators grant the permission to use the administration interface for the corresponding tenant. One certificate is permitted to be assigned to multiple tenants. To achieve this, the certificate is registered for the corresponding tenants as an administration certificate by pasting its Base64 encoded representation in the XML element.
Each administration certificate is assigned to a unique name. A duplicate entry of the same certificate in the configuration of one tenant is not allowed.
Example
<smc:SigModuleConfig xmlns:smc="http://www.t-systems.com/ima/safe/sig-module-config" xmlns:lc="http://www.t-systems.com/ima/safe/4.0/logConfig">
<smc:Tenants>
<smc:Tenant>
<smc:name>unnamedTenant1</smc:name>
<smc:enabled>true</smc:enabled>
<smc:TriggerTimestampMaxUnstamped>10</smc:TriggerTimestampMaxUnstamped>
<smc:TriggerTimestampMaxAgeMinutes>30</smc:TriggerTimestampMaxAgeMinutes>
<smc:HashTreeAlgorithms/>
<smc:HashTrees>
<smc:HashTree>
<smc:Name>SHA-256</smc:Name>
<smc:Algorithm>SHA-256</smc:Algorithm>
<smc:ReadOnly>false</smc:ReadOnly>
<smc:Default>true</smc:Default>
</smc:HashTree>
<smc:HashTree>
<smc:Name>SHA-512</smc:Name>
<smc:Algorithm>SHA-512</smc:Algorithm>
<smc:ReadOnly>false</smc:ReadOnly>
<smc:Default>true</smc:Default>
</smc:HashTree>
<smc:HashTree>
<smc:Name>SHA-256_2</smc:Name>
<smc:Algorithm>SHA-256</smc:Algorithm>
<smc:ReadOnly>false</smc:ReadOnly>
<smc:Default>false</smc:Default>
</smc:HashTree>
</smc:HashTrees>
<smc:AdminCertificates/>
</smc:Tenant>
</smc:Tenants>
<smc:OperationalSettings>
<smc:TimerDisabled>false</smc:TimerDisabled>
</smc:OperationalSettings>
</smc:SigModuleConfig>
The example illustrates the configuration of tenant1 in a shortened manner. Only the beginning part of a Base64 encoded certificate is shown (“MIIC”). For this tenant a hash tree with SHA-256 is initialized and the archiving timestamp is generated at least once a day.