CDOC 2.0

In 2024, the Information System Authority started the transition to the new CDOC 2.0 file format for file encryption, tentatively called CDOC2.

CDOC is a file format designed to encrypt data in such a way that it is accessible (decryptable) to a specific user or group of users.

The CDOC format relies on a public key infrastructure (PKI), where data encrypted with a public key can be decrypted with a private key, and vice versa: data encrypted with a private key can be decrypted with a public key.

CDOC1 is an XML-ENC-based CDOC format that predates the CDOC2 specification.

CDOC2 is the code name for Estonia's new file encryption standard.

In e-services that use an encryption solution, additional changes must be made to implement CDOC2. A Java library and a C++ library have been created for e-services. Standard users can encrypt and decrypt CDOC2 format with DigiDoc4 and RIA DigiDoc applications. A more detailed plan for commissioning is outlined in the schedule.

Analysis of CDOC2: https://installer.id.ee/media/cdoc/2020-03-26-cdoc20aruanne.pdf

CDOC2 documentation: https://open-eid.github.io/CDOC2/

CDOC1, the currently used digital file encryption and decryption solution, was created in 2002 with the introduction of the ID-card. To date, several problems with the CDOC1 format have been revealed - for example, it cannot be used for long-term storage of classified information, because after the device (ID-card, Digi-ID) is damaged or lost, the encrypted information becomes unavailable. Also, in the long term, the weakening of the cryptographic algorithms of classified files accumulated in the backup copies of cloud service providers and e-mail service providers may become a problem. To solve these problems, the CDOC2 encryption standard was developed.

CDOC2 addresses the following issues with CDOC1 specifications and implementations:
- CDOC1 does not provide future security. An attacker who has stored a CDOC container can open it in the future if the keys or cryptographic algorithms used to create the container are compromised.
- The CDOC1 format and the software designed to process it do not distinguish between encryption of a file for transport between parties and encryption of a file for storage by one party.
- The CDOC1 format does not allow sending an encrypted file to a recipient who only uses a mobile eID device (Mobile-ID or Smart-ID).
CDOC2 format support is being built in stages:
- In the first stage, the transport cryptography solution and storage cryptography for long-term encryption were developed and implemented in the java library, C++ library and DigiDoc4 application. Also the key transfer server software was created.
- In the next stage, the possibility to encrypt with a mobile eID tool (Mobile-ID or Smart-ID) will be developed.
Transport cryptography is intended for short-term protection of data when transferring a file from one party to another.

Both the CDOC1 format and the CDOC2 format support transport cryptography. In the CDOC2 format, for additional security of transport cryptography, a key transfer server has been introduced, whose task is to transfer the key capsule required for decrypting the CDOC envelope from the sender to the receiver.
Storage cryptography is the encryption of a file that needs to be encrypted for personal use to protect the file from outside unwanted interest and attacks.

The CDOC1 format is inherently intended for short-term protection of data during the transfer of a file from one party to another and is not intended for long-term storage of a file by one party.

The CDOC2 format also makes it possible to provide long-term confidential storage of files, as the current use of cryptography shows that users want to store information in an encrypted form (crypto containers intended for transport were also used for storage in their unaltered form).
The CDOC1 format does not allow sending an encrypted file to a recipient who only uses a mobile eID device (Mobile-ID or Smart-ID).

The CDOC2 format will also enable encryption and decryption with a mobile eID tool (Mobile-ID or Smart-ID).

The solution for encryption and decryption with the mobile eID tool is currently under development. In the future, regular users will be able to encrypt and decrypt information with the mobile eID tool through the DigiDoc4 and RIA DigiDoc applications. In the future, e-services will be able to use Java and C++ libraries for encryption and decryption with the mobile eID tool. More detailed information is given in the schedule.
A key capsule is a part of the CDOC2 format that contains the key needed to decrypt an encrypted data set, a part of that key, or data needed to calculate that key by the receiver. The sender may include the key capsule in an envelope or transmit it via key transfer servers, but the additional security features provided by CDOC2 only apply if the key capsule is transmitted via key transfer servers. The key capsule transmitted by the sender is stored in the key transfer server until the end of the validity period specified in the capsule, and after the specified time, the key transfer server deletes the key capsule in order to reduce the damage caused by possible compromise of the key server.

The key transfer server is a component of the CDOC2 system that transmits the key capsule needed to decrypt the CDOC container through a secure communication channel from the sender to the recipient. The key transfer server provides the sender with a service for uploading the key transfer capsule and the receiver with a service for downloading the key transfer capsule. The sender service does not require sender authentication - anyone can use this service. The service intended for the recipient requires authentication of the recipient using TLS client authentication - this service can only be used by users who have a supported eID device (for example, an ID-card, henceforth also Mobile-ID or Smart-ID).

The key transfer server is open source, so anyone can download it and set it up on their own server.

Several key transfer servers may be in use at the same time, and they may be operated by different organizations. Security requirements imposed during implementation may require that each individual key transfer server be run by independent organizations.

What needs to be done in order to use CDOC2 in your e-service or application?

Currently, it is possible to use the cdoc4j Java library to create CDOC1 format encryption and decryption support in e-services.

In order to use the CDOC2 format in your e-service, additional changes must be made to the e-service and required libraries need to be integrated. Currently, the following libraries with CDOC2 support are available:

C++ library: https://github.com/open-eid/libcdoc
Java library: https://github.com/open-eid/cdoc2-java-ref-impl

Standard users can encrypt and decrypt data using the DigiDoc4 and RIA DigiDoc applications. These applications currently use the CDOC1 format by default for encryption and decryption. Support for the CDOC2 format has also been added to the applications. To use this functionality, CDOC2 must be explicitly enabled in the settings.

Mobile eID encryption in DigiDoc applications is currently in the works, and this support will be added to DigiDoc applications at a later date. More detailed information can be found in the schedule.
Currently, CDOC1 encryption and decryption support is available in DigiDoc4 and RIA DigiDoc applications for general users. For e-services, there is a cdoc4j library for encryption and decryption in CDOC1 format.

CDOC1 encryption support is planned to be removed from DigiDoc4 and RIA DigiDoc in 2027. CDOC1 format envelope decryption support will initially be maintained so that users can decrypt their existing CDOC1 format envelopes.

Depending on the functionality offered by a particular e-service, it may be necessary to maintain CDOC1 support even after the transition to CDOC2. Therefore, the updating of the cdoc4j library will continue for the time being.

More detailed information about the schedule for the end of the CDOC1 support period in DigiDoc applications and the library can be found in the schedule.

Schedule

Disclosure of DigiDoc4 application with CDOC2 decryption support - released 8 September 2023

Disclosure of the CDOC2 Java platform library - released 22 November 2024

Disclosure of CDOC2 Key Transfer Server Code - released 30 May 2024

Disclosure of the key transmission server of the Information System Authority - released 27 November 2024

Disclosure of DigiDoc4 release with CDOC2 encryption support - released 30 December 2024
- By default, the CDOC1 format remains in use.
Disclosure of RIA DigiDoc Android mobile application with CDOC2 encryption and decryption support - released 17 December 2025
- By default, the CDOC1 format remains in use.
Disclosure of RIA DigiDoc iOS mobile application with CDOC2 encryption and decryption support - released 30 March 2026
- By default, the CDOC1 format remains in use.
Disclosure of the CDOC2 C++ platform library - released 8 April 2026

Disclosure of DigiDoc4 release with CDOC2 long-term cryptography support – released 13 May 2026

Disclosure of RIA DigiDoc iOS and Android mobile application with CDOC2 long-term cryptography support – August 2026
Schedule to be specified
CDOC2 will become the default format in the DigiDoc4 application – November 2026

CDOC2 will become the default format in the RIA DigiDoc Android and iOS mobile application – November 2026

Removal of CDOC1 encryption support from DigiDoc4 - 2027 I semester (date to be specified)

Removal of CDOC1 encryption support from RIA DigiDoc iOS and Android mobile application - 2027 I semester (date to be specified)

End of CDOC1 support, i.e. CDOC1 decryption support will be removed from DigiDoc4, RIA DigiDoc iOS and Android mobile apps and C++ encryption library, and cdoc4j library will not be developed further:
- Removal of CDOC1 decryption support from DigiDoc4 - 2029/2030 (date to be determined)
- Removal of CDOC1 decryption support from RIA DigiDoc iOS and Android mobile app - 2029/2030 (date to be specified)
- Removal of CDOC1 decryption support from C++ encryption library - 2029/2030 (date to be specified)
- cdoc4j EOL - 2029/2030 (date to be specified)

Testing

To test encryption solutions, we recommend ordering a test card. For more information about ordering test cards: https://www.id.ee/artikkel/id-kaardi-testimine/

What kind of tests should be done?

If the CDOC2 solution is integrated into your own information system, then the solution should also be tested.

Encryption solutions

In information systems that use encryption for the ID-card certificate, at least the following test should be performed:

Data encryption in the information system for the owner of the ID-card and data decryption with the ID-card in the DigiDoc4 application with CDOC2 support.

Depending on the functionality provided by the specific online service, completing additional tests could be necessary.

FAQ

How can users encrypt and decrypt envelopes in CDOC2 format?

Standard users can encrypt and decrypt data using the DigiDoc4 and RIA DigiDoc applications. Currently, DigiDoc4 and RIA DigiDoc use the CDOC1 format by default for encryption and decryption. Support for the CDOC2 format has also been added to the applications. To use it, CDOC2 must be enabled separately in the settings

Can envelopes in CDOC2 format be encrypted and decrypted even without an internet connection?

DigiDoc applications and encryption libraries enable encryption and decryption of envelopes in CDOC2 format even without an Internet connection, but in this case the key transfer server is not used, which is an additional secure communication channel between the sender and the recipient. DigiDoc applications with default settings use a key transfer server for encryption and decryption.

I want to give feedback, where should I report it?

Feedback and development suggestions can be sent to [email protected].