Skip to content

Datafiles augmentation

Juku Trump edited this page Jan 17, 2025 · 1 revision

Introduction

This page describes the validation process performed by SiGa on ASiC datafile containers before the augmentation for Long Term Archival (LTA). The augmentation is executed by calling the datafiles augmentation endpoint on an existing container session (which can be created, for example, by uploading a container).

Checks performed by SiGa before augmenting XAdES signatures in ASiC-E container

  1. There must be at least 1 signature in the container
    • If there are no signatures, the process is cancelled with an exception
  2. There must be at least 1 Estonian signature in the container
    • Estonian signature is detected by having C = EE value on Subject Distinguished Name field of the signer certificate
    • All non-Estonian signatures are filtered out before the next validation steps
    • If there are no Estonian signatures, the process is cancelled with an exception. Non-Estonian signatures must not be augmented.
  3. All the signatures are validated with both EE (Estonian) configuration and EU configuration. These validation results will be used in the following steps.
  4. Only personal signatures can be augmented
    • Personal signatures are detected by having substring Sig (case sensitive) in signatureLevel for EE validation result
    • All non-personal signatures (like e-seals) are filtered out before the next validation steps
    • If there are no personal signatures, the process is cancelled with an exception. E-seals must not be augmented.
  5. Containers that contain signatures with LT_TM profile are wrapped into ASiC-S container
    • For EE validation result, it is checked whether signatureFormat is equal to XAdES_BASELINE_LT_TM
    • If there is at least 1 Estonian personal signature that satisfies that condition, the whole container is encapsulated into an ASiC-S container, an archival timestamp is added to it and the process is stopped here
  6. The profile of all the signatures must be LT or LTA
    • It is checked that signatureFormat must be either XAdES_BASELINE_LT or XAdES_BASELINE_LTA. This condition must be satisfied for both EE and EU validation results.
    • If there is at least 1 Estonian personal signature that does not satisfy this condition, then:
      • If all Estonian personal signatures have lower level than LT with both Estonian and EU validation results, the process is cancelled with an exception
      • If there is at least 1 Estonian personal signature that has LT or LTA profile by EE validation results, the whole container is encapsulated into an ASiC-S container, an archival timestamp is added to it and the process is stopped here (any opposite cases, where the signature would be LT or LTA only by EU validation result, are currently unknown to us and therefore not handled)
  7. The augmentable signatures must be valid
    • It is checked that indication = TOTAL-PASSED and signatureLevel = QESig by EE validation result
    • It is checked that indication = TOTAL-PASSED by EU validation result
    • If there is at least 1 Estonian personal signature that does not satisfy at least 1 of these 2 previous conditions, the whole container is encapsulated into an ASiC-S container, an archival timestamp is added to it and the process is stopped here
  8. If all the previous checks have passed, the container is augmented
    • All the Estonian personal signatures in the container are augmented with archival timestamps. Any other signatures in the container are not modified.
    • The datafiles stay the same as in the original container.

Checks performed by SiGa before augmenting timestamped ASiC-S container

Prerequisites: as ASiC-S container must already be uploaded to SiGa, it must conform to the rules imposed by DigiDoc4j on ASiC-S containers.

  1. The container must not contain any signatures
    • If there are both signatures and timestamps in the container, SiGa doesn't even allow to upload such a container
    • If the container contains a signature, but not a timestamp token, an exception will be thrown in the next step while checking for timestamp
    • The inner container (which is encapsulated inside the ASiC-S container as its datafile) is allowed to contain signatures
  2. The container must contain a timestamp token
    • If there is no timestamp token, the process is cancelled with an exception. Timestamping an existing container which does not already have a timestamp token is not allowed in SiGa.
  3. The container may only contain a DDOC, BDOC, ASiC-E or ASiC-S container as its datafile
    • If the datafile is of any other type, the process is cancelled with an exception
    • To detect the type of inner container, the inner container itself must also be parsed with DigiDoc4j, so if there is a problem opening that container, the process is cancelled with an exception
  4. If the previous checks have passed, a new archival timestamp is added to the container