Renewal of timestamps (resigning)

For the signing process the root hash values of a hash tree are sent to a timestamp service provider, which generates a signature based on the hash values and the current time obtained from a trustworthy source. Based on this signature and associated time, you can prove that a certain hash value is present and valid on the signed point of time in ImageMaster.

The signatures of timestamp service providers are usually qualified and subject to the framework requirements as specified by the SOG-IS algorithm catalog. This means that used algorithms and key length requirements arise from the algorithm catalog for which a new version is published annually. The timestamps, which complied with the requirements of the algorithm catalog when they were created, can lose their evidential value later.

Example:

A timestamp service provider makes use of the signature mechanism RSA with a key length of 1976 bits. This length is accepted in the algorithm catalog of 2015 and can be used prospectively up to the year 2021. After this point in time the evidential value is not accepted anymore as this signature must be considered prone to forgery.

For this reason timestamps must be renewed before they lose their evidential value. The TR-ESOR specification envisages that a new timestamp is generated on top of the existing one. The newer timestamp uses stronger cryptographic properties like a longer RSA key, which prolongs the evidential value of the first timestamp. The new timestamp must be generated before the original one loses its evidential value. In the example above a renewal of the timestamp with another signing procedure or a longer RSA key before 2021 would be a solution.

In general, the following cases require a renewal of existing timestamps:

  • The signature key is weakening over time and considered insecure according to the algorithm catalog.

  • The signature’s underlying certificate of the timestamp service provider expires.

Ideally renew the time-stamps of the hash trees on a regular base (e.g. every two years) instead of waiting until the algorithms are announced to get weak. Also it is a good practice to have different hash trees in parallel with different hash-algorithms for the same content.

Data with evidential value consists of an initial timestamp and the renewed timestamps provided in the Evidence Record Syntax (ERS) format. The ArchiSig-Module only generates binary encoded evidence records that comply with the requirements of RFC 4998. These- records adhere to the profiling standards of the Federal Office for Information Technology Security in Germany.

Conducting a timestamp renewal

For the renewal of timestamps, access to a timestamp service is required, which provides timestamps with the desired properties.

Basically, the following options exist:

  • The existing timestamp service provider is also capable of providing timestamps with the new properties. The URL (for accessing the timestamp service) stays the same and the configuration of the Crypto-Module, which requests the timestamps, remains unchanged.

  • A different timestamp service is used (another provider or a different URL). In this case the configuration of the Crypto-Module must be adjusted and the new timestamp service must be defined. Then the configuration of the Crypto-Module must be reloaded.

The Crypto-Module will generate timestamps with the new desired cryptographic properties that fulfill the new quality requirements.

In a second step, the existing timestamps must be processed. This step consists of two steps:

  • Identify the timestamps, which must be renewed, based on a search for the cryptographic properties of the timestamps.

  • Resign the timestamps by using the Crypto-Module’s timestamp service.

The steps are triggered with the Signature Service REST interface. The search for timestamps is performed with the operation /trees/{treeName}/timestamps. This operation searches for timestamps and displays them, but it does not run any resign process. Possible search criteria are:

  • hash value procedure used in the timestamp signature

  • signature procedure used in the timestamp signature

  • issuer and serial number of the timestamp certificate

These timestamps can also be counted with operation /trees/{treeName}/timestamps/count.

The operation /trees/{treeName}/renewals/timestamps prepares the renewal of all timestamps of a hash tree and a tenant according to the search criteria. The following search criteria are supported:

  • hash value procedure used in the timestamp signature

  • signature procedure used in the timestamp signature

  • issuer and serial number of the timestamp certificate

A timestamp renewal entry holding the information is created. This can be started with the operation /trees/{treeName}/renewals/timestamps/process. The operation /trees/{treeName}/renewals/timestamps/process executes a task, which is represented by a renewal entry created before with the operation /trees/{treeName}/renewals/timestamps.

The timestamps are updated in blocks and the new operation renews the timestamps of one block. As a result, you can see if the renewal of all timestamps is finished or not. If not, the operation has to be executed again. The result shows the current state of a complete renewal task, not just a single block processing. A loop to call the process is as follows:

  while  <finished> = false 
    do
        # Call command to process one block
        curl -X POST ... /trees/<tree-name>/renewals/timestamps/process?blocksize=<block-size>
        
        # Analyze the http code ...
        # Read the value of finished from the result
        # {
        #  "treeName": "treeName",
        #  "created": "2022-07-21T17:32:28Z\n",
        #  ...
        #  "finished": true
        # }
        
        <finished>= ...
    done

There are also operations to list and delete the renewal entries and count the timestamps left to renew. The documentation of the complete SignatureService REST webservice is part of ima-ws-references<version>.zip and provided in the assembly file.

Execution time

The time that is required by the ArchiSig-Module for the renewal of timestamps depends on the number of timestamps. Normally, the number of timestamps in a system does NOT depend on the total number of content objects:

In a typical configuration the creation of timestamps is triggered in a time-controlled manner to lower the costs for the timestamp service (see Configuration of ArchiSig-Module). The TR-ESOR specification envisages timestamps to be created at least once a day, so the number of timestamps in a system is at most the number of days that the system was in operation. For days when no new content objects are archived, the ArchiSig-Module does not create a timestamp. As a result, the execution time does not depend on the total number of documents. A time-controlled daily creation is the default setting of the ArchiSig-Module, which should be kept as is if there are no serious reasons against this.

Before a timestamp renewal another timestamp check is conducted, which together with the resign process requires a few seconds. Timestamps of multiple tenants can be renewed in parallel to reduce the overall execution time.