Release 5.3.3

A new notice has been published in the Official Journal of the European Union on April 15, 2026, updating the set of signer certificates for LOTL. This marks the beginning of the transition period, ahead of the LOTL pivot-chain reset, concluding on April 29, 2026.

During that period, the first EU LOTL instance references both the previous and the new EU Official Journal publications, and LOTL resolution may succeed via either publication. After the transition period, the old EU Official Journal publication reference and the pre-reset part of the pivot chain are removed.

This update is required so LOTL access and authenticity verification continue to work through the transition. Separate information will be provided for other DigiDoc4j versions.

Summary of the major changes since 5.3.2

• Updated LOTL signers' truststore for PROD mode according to the latest EU Official Journal notice: https://eur-lex.europa.eu/eli/C/2026/1944/oj
• Fixes to unit tests

Known issues

• We have noticed a decrease in performance of parsing/validating XAdES signatures that cover numerous data files since updating to DSS 6.0
• We have noticed a slight increase in TSL loading times due to pivot LOTL support
• We have noticed a decrease in performance with the introduction of properly accessing AIA certificate resources
• Opening a container that contains signatures, triggers TSL loading (TSL lazy loading does not work as expected)

Release 6.1.1

A new notice has been published in the Official Journal of the European Union on April 15, 2026, updating the set of signer certificates for LOTL. This marks the beginning of the transition period, ahead of the LOTL pivot-chain reset, concluding on April 29, 2026.

During that period, the first EU LOTL instance references both the previous and the new EU Official Journal publications, and LOTL resolution may succeed via either publication. After the transition period, the old EU Official Journal publication reference and the pre-reset part of the pivot chain are removed.

This update is required so LOTL access and authenticity verification continue to work through the transition. Separate information will be provided for older DigiDoc4j versions.

Summary of the major changes since 6.1.0

• Updated LOTL signers' truststore for PROD mode according to the latest EU Official Journal notice: https://eur-lex.europa.eu/eli/C/2026/1944/oj
• Migrated unit tests from JUnit 4 to JUnit 5
• Fixes and improvements to unit tests
• Migrated to JMH library for DigiDoc4j Performance tests
• Updated dependencies

Known issues

• We have noticed a slight increase in TSL loading times due to pivot LOTL support
• We have noticed a decrease in performance with the introduction of properly accessing AIA certificate resources
• Opening a container that contains signatures, triggers TSL loading (TSL lazy loading does not work as expected)

Release 6.1.0

Summary of the major changes since 6.0.1

• Updated DSS to 6.2 (sd-dss 6.2.d4j.1):
  • Check changes in open-eid/sd-dss here: https://github.com/open-eid/sd-dss/releases/tag/dss-6.2.d4j.1
  • Check changes in esig/dss since 6.0 here:
    • DSS 6.1.RC1: https://github.com/esig/dss/releases/tag/6.1.RC1
    • DSS 6.1: https://github.com/esig/dss/releases/tag/6.1
    • DSS 6.2.RC1: https://github.com/esig/dss/releases/tag/6.2.RC1
    • DSS 6.2: https://github.com/esig/dss/releases/tag/6.2
  • Performance decrease related to validating XAdES signatures that cover numerous data files has been fixed
• Changes in validation policies:
  • Changes in accepted cryptographic algorithms (as enforced in default constraint files):
    • DSA is no longer considered as accepted encryption algorithm
    • SHA3-224 and RIPEMD160 are no longer considered as accepted digest algorithms
    • Minimum accepted key size for ECDSA was unified to 256 for all signature components
    • RSA and RSASSA-PSS encryption algorithms with key sizes less than 1900 are considered expired since 2019-10-01
    • SHA224 digest algorithm is considered expired since 2026-01-01
  • Signatures with revocation data taken more than 24h after signature timestamp are no longer considered as invalid; instead, a warning is issued
  • Add SHA-1 validation warning to DDoc signatures which have not been wrapped into timestamped ASiC-S containers before 2018-07-01
• API changes in TSLCertificateSource interface, caused by changes in DSS:
  • New API methods:
    • List<String> getAlternativeOCSPUrls(CertificateToken)
    • List<String> getAlternativeCRLUrls(CertificateToken)
    • CertificateTrustTime getTrustTime(CertificateToken)
    • int getNumberOfTrustedEntityKeys()
  • Deprecated API methods:
    • int getNumberOfTrustedPublicKeys()
• Improved reference URI handling in ASiCArchiveManifest for timestamped ASiC-S containers
• Improved datafile name validation via ContainerBuilder
• Fixes and improvements to unit tests
• Updated dependencies

Known issues

• We have noticed a slight increase in TSL loading times due to pivot LOTL support
• We have noticed a decrease in performance with the introduction of properly accessing AIA certificate resources
• Opening a container that contains signatures, triggers TSL loading (TSL lazy loading does not work as expected)

Release 5.3.2

EU and its member states are expected to transition to version 6 of the EU Trust List format in the second half of May 2025.

DigiDoc4j version 5.x.x users must upgrade to DigiDoc4j version 5.3.2 or 6.0.1 before EU member states adopt EU Trust List version 6. If the upgrade is not done, it won't be possible to load EU Trust Lists, which results in failure on signature creation and validation.

Separate info will be provided for older versions, though we strongly recommend upgrading to the latest version.

Summary of the major changes since 5.3.1

• Updated DSS to 6.0.1 (sd-dss 6.0.1.d4j.1). Check changes in DSS here: https://github.com/esig/dss/releases/tag/6.0.1
  • Added support for EU Trust List v6; EU Trust List v5 remains supported
• Fixes and improvements to unit tests
• Updated dependencies

Known issues

• EDIT 09.01.2026: NB! Starting from January 1, 2026, signature creation fails if revocation data is acquired from OCSP responders using RSA keys smaller than 3000 bits to sign their responses. It is recommended to upgrade to at least DigiDoc4j version 6.1.0 or apply a workaround as described here. More information about the incident can be found here.
• We have noticed a decrease in performance of parsing/validating XAdES signatures that cover numerous data files since updating to DSS 6.0
• We have noticed a slight increase in TSL loading times due to pivot LOTL support
• We have noticed a decrease in performance with the introduction of properly accessing AIA certificate resources
• Opening a container that contains signatures, triggers TSL loading (TSL lazy loading does not work as expected)

Release 6.0.1

EU and its member states are expected to transition to version 6 of the EU Trust List format in the second half of May 2025.

DigiDoc4j version 6.0.0 users must upgrade to DigiDoc4j version 6.0.1 before EU member states adopt EU Trust List version 6. If the upgrade is not done, it won't be possible to load EU Trust Lists, which results in failure on signature creation and validation.

Separate info will be provided for older versions, though we strongly recommend upgrading to the latest version.

Summary of the major changes since 6.0.0

• Updated DSS to 6.0.1 (sd-dss 6.0.1.d4j.1). Check changes in DSS here: https://github.com/esig/dss/releases/tag/6.0.1
  • Added support for EU Trust List v6; EU Trust List v5 remains supported
• Fixes to encoded reference URI handling in ASiCArchiveManifest for timestamped ASiC-S containers
• Fixes and improvements to unit tests
• Updated dependencies

Known issues

• EDIT 09.01.2026: NB! Starting from January 1, 2026, signature creation fails if revocation data is acquired from OCSP responders using RSA keys smaller than 3000 bits to sign their responses. It is recommended to upgrade to at least DigiDoc4j version 6.1.0 or apply a workaround as described here. More information about the incident can be found here.
• We have noticed a decrease in performance of parsing/validating XAdES signatures that cover numerous data files since updating to DSS 6.0
• We have noticed a slight increase in TSL loading times due to pivot LOTL support
• We have noticed a decrease in performance with the introduction of properly accessing AIA certificate resources
• Opening a container that contains signatures, triggers TSL loading (TSL lazy loading does not work as expected)

Release 6.0.0

Summary of the major changes since 6.0.0-RC.1

• Added possibility to check the extendability of LT/LTA signatures before extending them
• Improved validation of ASiC-S containers with timestamp tokens
  • Add warnings to timestamp tokens that do not cover the data file of the container
• Added possibility to configure custom TSP sources (via TSP source factories)
  • Separate TSP source factories for signature timestamps and archive timestamps
• Improvements in the presentation of validation results:
  • Improved details in the warning message about non-fresh OCSP response
  • Improved the propagation of ASiC container warnings to validation results and reports
  • Added container warnings to container validation report
  • Improved report saving functionality
• Improved thread-safety of legacy DDoc configuration loading
• Changes to performance tests:
  • Fixes to accommodate changes in handling timestamped ASiC-S containers
  • New performance tests to cover added functionality
• Fixes and improvements to unit tests
• Updated dependencies

Known issues

• EDIT 09.01.2026: NB! Starting from January 1, 2026, signature creation fails if revocation data is acquired from OCSP responders using RSA keys smaller than 3000 bits to sign their responses. It is recommended to upgrade to at least DigiDoc4j version 6.1.0 or apply a workaround as described here. More information about the incident can be found here.
• We have noticed a decrease in performance of parsing/validating XAdES signatures that cover numerous data files since updating to DSS 6.0
• We have noticed a slight increase in TSL loading times due to pivot LOTL support
• We have noticed a decrease in performance with the introduction of properly accessing AIA certificate resources
• Opening a container that contains signatures, triggers TSL loading (TSL lazy loading does not work as expected)

Release 6.0.0-RC.1

Summary of the major changes since 5.3.1

• Improved LTA support
  • LTA signatures can be extended repeatedly
    • Each extension adds a new LTA archive timestamp to the signature, extending its long term availability and integrity
  • Specific signatures to extend inside a container can be explicitly specified
    • Signatures can be extended one at a time
• Improved support for ASiC-S containers with timestamp tokens
  • Timestamp tokens are now created and validated using DSS
    • Validation rules are stricter: old timestamp tokens from withdrawn services produce warnings
      • Re-timestamping of old timestamped ASiC-S containers is recommended to avoid future incompatibilities
  • ASiC-S containers now support multiple timestamp tokens
    • Each new timestamp token covers container's data file and previous timestamp tokens, extending the container's long term availability and integrity
  • New API for adding timestamp tokens to, removing from, and querying from containers (analogous to signatures API)
    • New Timestamp interface for interacting with an individual timestamp token
    • TimestampBuilder for creating timestamp tokens
  • Deprecation of old API-s:
    • Classes: TimeStampTokenValidator
    • Methods in Container interface and its implementing classes, AsicParseResult class:
      • void setTimeStampToken(DataFile)
      • DataFile getTimeStampToken()
    • Methods in AsicContainerCreator class:
      • void writeTimestampToken(DataFile)
• Support for composite containers
  • Inside timestamped ASiC-S containers, nested ASiC, BDOC, and DDOC containers are supported
  • New CompositeContainer interface for identifying composite containers
    • API methods for accessing the contents of a nested container inside a timestamped ASiC-S container
  • CompositeContainerBuilder for wrapping an existing container inside a timestamped ASiC-S container
  • Validating a composite container, also triggers validation of its nested container
    • A nested container is validated against the creation time of the earliest valid timestamp token of its parent container
    • Validation results/reports contain the aggregated results of both nesting and nested containers
• Support for creating T profile signatures
• Improved configurability
  • Added possibility to configure custom OCSP sources (via OCSP source factories)
  • Added possibility to configure separate timestamp service to be used for archive timestamps
  • Added possibility to configure digest algorithms to be used for archive timestamps
• Improved ContainerValidationResult
  • Validation results of individual signatures and timestamp tokens are now accessible via their unique IDs
  • New API methods:
    • ValidationResult getValidationResult(String)
    • List<String> getSignatureIdList()
    • List<String> getTimestampIdList()
• Removed "META-INF/manifest.xml" requirement for signed ASiC-S containers
• Stricter rules for parsing ASiC-S containers
  • ASiC-S containers with illegal or unsupported contents fail to parse (for more information, see DigiDoc4j wiki)
• Changes in validation policies
  • Allow timestamps from TSA/QTST services only
• Updated dependencies

Known issues

• EDIT 09.01.2026: NB! Starting from January 1, 2026, signature creation fails if revocation data is acquired from OCSP responders using RSA keys smaller than 3000 bits to sign their responses. It is recommended to upgrade to at least DigiDoc4j version 6.1.0 or apply a workaround as described here. More information about the incident can be found here.
• We have noticed a decrease in performance of parsing/validating XAdES signatures that cover numerous data files since updating to DSS 6.0
• We have noticed a slight increase in TSL loading times due to pivot LOTL support
• We have noticed a decrease in performance with the introduction of properly accessing AIA certificate resources
• Opening a container that contains signatures, triggers TSL loading (TSL lazy loading does not work as expected)

Release 5.3.1

Summary of the major changes since 5.3.0

• Updated DSS to 6.0.d4j.2 in order to fix memory leak issue in XAdESSignature
• Updated Bouncy Castle to 1.78.1
• Fixed/updated unit tests

Known issues

• EDIT 09.01.2026: NB! Starting from January 1, 2026, signature creation fails if revocation data is acquired from OCSP responders using RSA keys smaller than 3000 bits to sign their responses. It is recommended to upgrade to at least DigiDoc4j version 6.1.0 or apply a workaround as described here. More information about the incident can be found here.
• EDIT 05.12.2024: We have noticed a decrease in performance of parsing/validating XAdES signatures that cover numerous data files since updating to DSS 6.0
• We have noticed a slight increase in TSL loading times due to pivot LOTL support
• We have noticed a decrease in performance with the introduction of properly accessing AIA certificate resources
• Opening a container that contains signatures, triggers TSL loading (TSL lazy loading does not work as expected)

Release 5.3.0

Summary of the major changes since 5.2.0

• DSS version update to 6.0 (sd-dss.6.0.d4j.1), previously used DSS 5.11.1. Check changes in DSS here: https://github.com/esig/dss/releases
  DSS update has caused the following notable changes to dependencies:
  • Migration from Javax to Jakarta namespace
  • JAXB dependencies updated from 2.3.X to 3.0.X
  • Apache Santuario xmlsec updated from 2.3.X to 3.0.X
  • Bouncy Castle updated from jdk15on:1.70 to jdk18on:1.76
  • SLF4J updated from 1.7.X to 2.0.X
• Prefer to use AIA OCSP by default on signature creation
  • In DigiDoc4J command line utility, deprecated -aiaocsp parameter and added new -noaiaocsp parameter
• TEST mode default timestamp URL updated to http://tsa.demo.sk.ee/tsa
• Changes in validation policies
• Updated dependencies

Known issues

• EDIT 09.01.2026: NB! Starting from January 1, 2026, signature creation fails if revocation data is acquired from OCSP responders using RSA keys smaller than 3000 bits to sign their responses. It is recommended to upgrade to at least DigiDoc4j version 6.1.0 or apply a workaround as described here. More information about the incident can be found here.
• EDIT 10.06.2024: NB! Underlying DSS library version used in this release has memory leak since DSS 5.13.RC1. We are working on fixing it ASAP.
• EDIT 05.12.2024: We have noticed a decrease in performance of parsing/validating XAdES signatures that cover numerous data files since updating to DSS 6.0
• At the time of release, the newest supported Bouncy Castle version is 1.76
  Bouncy Castle version 1.77 causes OCSP response parsing to fail
• We have noticed a slight increase in TSL loading times due to pivot LOTL support
• We have noticed a decrease in performance with the introduction of properly accessing AIA certificate resources
• Opening a container that contains signatures, triggers TSL loading (TSL lazy loading does not work as expected)

Release 5.2.0

Summary of the major changes since 5.1.0

• Disabled the possibility to create signatures with LT_TM and B_EPES profiles
• Fixed OCSP request nonce encoding (in CommonOCSPSource) on signature creation - OCSP nonce, used in id-pkix-ocsp-nonce OCSP extension, is now a DER-encoded OCTET STRING, which is encapsulated as another OCTET STRING (see RFC 4366, section 3.6 and RFC 6961, section 2.2)
• Deprecated "full report" configuration flag, as enabling it can produce false negative validation results in some cases:
  • Deprecated setFullReportNeeded and isFullReportNeeded methods in Configuration class
  • Deprecated -err/-showerrors command line option in DigiDoc4J command line utility
• Updated dependencies

Known issues

• EDIT 09.01.2026: NB! Starting from January 1, 2026, signature creation fails if revocation data is acquired from OCSP responders using RSA keys smaller than 3000 bits to sign their responses. It is recommended to upgrade to at least DigiDoc4j version 6.1.0 or apply a workaround as described here. More information about the incident can be found here.
• We have noticed a slight increase in TSL loading times due to pivot LOTL support
• We have noticed a decrease in performance with the introduction of properly accessing AIA certificate resources
• Opening a container that contains signatures, triggers TSL loading (TSL lazy loading does not work as expected)
• While upgrading from versions older than 2.1.1 be sure that your integration :
  • doesn't use Xalan or XercesImpl dependencies
  • uses a patched Java version (JDK8 or higher)
    Xalan and XercesImpl were used to patch XML vulnerabilities in older java versions. They should be discarded with higher versions because they override default Java XML security.
    If it is not possible to remove Xalan, then you can set your system property to override TransformerFactory : System.setProperty("javax.xml.transform.TransformerFactory","com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl");