CipherMail 6.4.0: ECDSA, ECDH and S/MIME for EDI@Energy
CipherMail 6.4.0: ECDSA and ECDH for EDI@Energy market communication
CipherMail 6.4.0 introduces ECDSA signature verification and ECDH decryption to support the S/MIME requirements of German energy market communication. Released on 30 September 2026, the update addresses important cryptographic interoperability requirements defined by EDI@Energy and BSI TR-03116-4.
For energy suppliers, grid operators and other market participants, secure electronic communication is not just a cybersecurity consideration. It is also governed by specific technical requirements for digital signatures, encryption algorithms and certificate validation.
Since 1 October 2023, German energy market participants have been required to receive S/MIME messages signed with ECDSA and encrypted using ECDH. Until version 6.3.5, the CipherMail Secure Email Gateway did not support these capabilities.
CipherMail 6.4.0 closes that gap.
The release notes explicitly reference the German EDI@Energy requirements and BSI TR-03116-4. The update introduces the cryptographic functionality needed to support the specified S/MIME email communication methods.
Version 1.10 of the EDI@Energy Regelungen zum Übertragungsweg has applied since 1 October 2026 and references the 3 July 2025 edition of BSI TR-03116-4.
For administrators, however, upgrading alone is not enough. Several required cryptographic settings are not enabled by default and must be configured for the relevant market communication domains.
What are the EDI@Energy S/MIME encryption requirements?
EDI@Energy defines cryptographic requirements for secure email communication between German energy market participants. These include approved algorithms for outgoing messages, mandatory support for receiving additional elliptic-curve-based messages, and regular certificate revocation checks.
The requirements in Chapter 5.3 of the Regelungen zum Übertragungsweg can be divided into three areas.
1. Digital signatures and encryption
For outgoing S/MIME communication, EDI@Energy specifies:
- Digital signatures: RSASSA-PSS with SHA-256 or SHA-512.
- Content encryption: AES-128-GCM.
- Content encryption key protection: RSAES-OAEP with SHA-256 or SHA-512.
- RSA certificates: A minimum key length of 3072 bits.
These requirements define the cryptographic methods used for the applicable email communication channel.
2. Receiving ECDSA and ECDH messages
Market participants must additionally be capable of receiving:
- S/MIME messages digitally signed with ECDSA.
- S/MIME messages encrypted using ECDH key agreement.
- Messages using the recommended elliptic curve brainpoolP256r1.
An important distinction is that the cited rules require support for receiving these methods but do not permit their use for outgoing market communication.
3. Certificate revocation checking
Chapter 5.5 requires market partner certificates to be checked against certificate revocation lists at least once per day.
CipherMail supports cached revocation lists, which are updated every six hours by default.
EDI@Energy Requirements vs CipherMail 6.4.0
Important: There is no official test or certification procedure for EDI@Energy or BSI TR-03116-4. This comparison describes supported cryptographic capabilities and does not constitute a formal declaration of conformity.
For more information about revocation list caching, see our related article on CipherMail 6.3.5: Reduced Memory Usage, CRL Cache and the New Company Portal.
What's new in CipherMail 6.4.0? ECDSA and ECDH support
The most significant cryptographic improvements in CipherMail 6.4.0 concern elliptic-curve digital signatures and key agreement.
These capabilities improve interoperability with systems using the cryptographic methods referenced by EDI@Energy and BSI TR-03116-4.
ECDSA digital signature verification
ECDSA (Elliptic Curve Digital Signature Algorithm) is a digital signature algorithm based on elliptic-curve cryptography.
CipherMail 6.4.0 can verify ECDSA signatures using:
- SHA-256
- SHA-384
- SHA-512
This enables the gateway to process incoming S/MIME messages signed using supported elliptic-curve certificates.
ECDH email decryption
ECDH (Elliptic Curve Diffie-Hellman) is a key agreement mechanism used to establish cryptographic keying material.
CipherMail 6.4.0 can decrypt incoming S/MIME messages whose content encryption key was established using ECDH.
The implementation supports:
- Standard Diffie-Hellman key agreement.
- Cofactor Diffie-Hellman.
- X9.63 key derivation.
- AES Key Wrap.
- RFC 5753 processing.
- CBC and GCM content encryption.
Together, these capabilities allow CipherMail to receive a broader range of elliptic-curve-based encrypted email messages.
Supported Brainpool and NIST elliptic curves
CipherMail 6.4.0 supports the following curves:
Brainpool curves
- P-256
- P-384
- P-512
NIST curves
- P-256
- P-384
- P-521
This includes brainpoolP256r1 and NIST P-256, the two curves identified in Section 4.7 of BSI TR-03116-4 as minimum interoperability requirements.
Brainpool certificate chain validation
According to CipherMail, version 6.4.0 also introduces validation of certificate chains using Brainpool curves.
Previously, the JDK's elliptic-curve provider did not support these curves, preventing verification of the corresponding certificate chains.
This improvement is particularly relevant for environments using Brainpool-based PKI infrastructure.
User Keying Material (UKM)
When CipherMail itself performs ECDH encryption, for example outside EDI@Energy market communication, it can include random User Keying Material in the key derivation process.
This follows the recommendation in Section 4.4.2 of BSI TR-03116-4.
The setting smime-key-agreement-ukm is enabled by default.
Hardware Security Module considerations
Organisations storing private keys in a Hardware Security Module (HSM) should verify ECDH support before upgrading or enabling relevant functionality.
ECDH key agreement takes place where the private key resides.
If the HSM does not support the required operations, the gateway's software-level cryptographic support alone may not be sufficient.
.png)
How to configure CipherMail for EDI@Energy sending restrictions
One of the most important aspects of the CipherMail 6.4.0 update is the distinction between receiving ECDSA/ECDH messages and sending them.
Although EDI@Energy requires market participants to receive messages using these methods, the applicable rules do not permit their use for outgoing market communication.
CipherMail 6.4.0 supports ECDH encryption when an elliptic-curve certificate is available for a recipient.
If a recipient has both RSA and EC certificates, the gateway can encrypt for both.
The release notes explicitly acknowledge that this default behaviour is not suitable for EDI@Energy communication.
Four new cryptographic configuration switches
CipherMail 6.4.0 introduces four switches that control outgoing cryptographic operations:
smime-rsa-encryption-enabledsmime-ec-encryption-enabledsmime-rsa-signing-enabledsmime-ec-signing-enabled
All four are enabled by default.
To meet the outgoing EDI@Energy restrictions, administrators should disable EC encryption and EC signing for the relevant market communication domains.
smime-ec-encryption-enabled = false
smime-ec-signing-enabled = false
Disabling these settings prevents the gateway from encrypting to EC certificates or signing with EC keys for the configured scope.
Incoming ECDSA signature verification and ECDH decryption remain available.
The switches can be configured globally, per domain or per recipient.
Prevent unintended unencrypted email
There is an important operational consequence.
If a recipient only has an EC certificate and EC encryption is disabled, CipherMail cannot use that certificate for outgoing S/MIME encryption.
What happens next depends on the domain's encryption policy.
For energy market communication, the policy should be configured to prevent messages from being sent in plaintext when the required encryption cannot be applied.
This is a critical configuration consideration when enabling the new cryptographic capabilities.
Required CipherMail 6.4.0 settings for EDI@Energy
CipherMail 6.4.0 supports the required cryptographic algorithms, but the relevant EDI@Energy settings are not the default values.
Administrators must therefore configure the appropriate market communication domains after upgrading.
Default settings vs EDI@Energy configuration
Why domain-specific configuration matters
These settings should be applied to the domains used for energy market communication rather than indiscriminately at the global level.
Different communication partners and email clients may have different cryptographic capabilities.
According to CipherMail, Microsoft Outlook does not support AES-GCM in the relevant S/MIME context.
Applying the EDI@Energy settings globally could therefore affect other email communication workflows.
Domain-specific configuration allows organisations to implement the required algorithms while preserving appropriate settings for unrelated email traffic.
AS4 vs S/MIME: Which is required for German energy market communication?
Not every German energy market communication process continues to use S/MIME email.
The sector has progressively migrated several established EDIFACT communication processes to AS4.
AS4 (Applicability Statement 4) is a secure business-to-business messaging protocol used for structured electronic data exchange.
S/MIME, by contrast, provides cryptographic protection for email messages.
The required transmission channel depends on the specific market process and its applicable communication rules.
AS4 requirements for electricity market communication
Since 1 April 2024, AS4 has been mandatory for the following electricity market processes:
- GPKE
- MPES
- WiM
- MaBiS
For these processes, traditional S/MIME email is no longer the prescribed transmission channel.
AS4 requirements for gas market communication
Since 1 April 2025, AS4 has also been mandatory for relevant gas market processes, including:
- GeLi Gas
- GaBi Gas
- KoV processes
Where S/MIME email remains relevant
S/MIME email remains a permitted transmission channel for Redispatch 2.0 and for formats that are not assigned to AS4 in the applicable overview of check identifiers (Prüfidentifikatoren).
Organisations must therefore identify which communication formats still use email and apply the corresponding EDI@Energy cryptographic requirements.
AS4 support in CipherMail
AS4 uses certificates from the BSI Smart Metering PKI.
As described in the CipherMail 6.4.0 source material, AS4 is not included in the current gateway release.
CipherMail B.V. has indicated plans to implement AS4 in the first quarter of 2027. This is a planned development, not a confirmed release commitment.
CipherMail 6.4.0 upgrade checklist for energy market operators
Organisations using CipherMail for German energy market communication should plan the update to version 6.4.0 and review the relevant cryptographic policies.
The following checks are particularly important.
Important change to the built-in Certificate Authority
CipherMail 6.4.0 introduces a change to the built-in CA configuration.
The setting ca-key-algorithm replaces ca-key-length.
Its default value is RSA_3072.
If an organisation previously configured a higher RSA key length, that value is not automatically carried over.
Administrators using the gateway's built-in CA should therefore review the setting after the upgrade.
For the complete technical changes, consult the CipherMail Gateway Release Notes.
Secure EDI@Energy email communication with CipherMail
CipherMail 6.4.0 represents an important update for organisations using S/MIME in German energy market communication.
By adding ECDSA signature verification, ECDH decryption and Brainpool certificate chain support, the gateway addresses previously missing cryptographic capabilities.
However, supporting the required algorithms is only one part of the implementation.
Administrators must also configure the correct outgoing signing and encryption methods, restrict EC-based sending where required, maintain certificate revocation checking and apply suitable encryption policies.
For organisations operating across multiple communication channels, it is equally important to distinguish the processes that require AS4 from those where S/MIME email remains permitted.
The key takeaway: CipherMail 6.4.0 provides the cryptographic capabilities needed for the EDI@Energy S/MIME requirements, but correct domain-specific configuration remains essential.
Frequently asked questions about EDI@Energy and CipherMail 6.4.0
What is EDI@Energy?
EDI@Energy is a framework of technical and organisational rules for electronic data exchange in the German energy sector. Its transmission-channel requirements specify how certain market communication messages must be exchanged and protected.
What are the S/MIME requirements for EDI@Energy?
For the applicable email channel, EDI@Energy specifies RSASSA-PSS signatures, AES-128-GCM content encryption, RSAES-OAEP key protection and RSA certificates of at least 3072 bits. Participants must also support receiving ECDSA-signed and ECDH-encrypted messages and perform regular certificate revocation checks.
Does CipherMail 6.4.0 support ECDSA and ECDH?
Yes. CipherMail 6.4.0 introduces ECDSA signature verification and ECDH decryption, including support for specified Brainpool and NIST elliptic curves. These capabilities were not available in the required form in version 6.3.5.
Which elliptic curves does CipherMail 6.4.0 support?
CipherMail 6.4.0 supports Brainpool P-256, P-384 and P-512, together with NIST P-256, P-384 and P-521. This includes brainpoolP256r1 and NIST P-256, referenced as minimum interoperability curves in BSI TR-03116-4.
Can ECDSA and ECDH be used for outgoing EDI@Energy emails?
Under the cited EDI@Energy rules, market participants must be able to receive messages using ECDSA and ECDH, but these methods are not permitted for outgoing market communication. CipherMail allows administrators to disable outgoing EC signing and encryption while retaining incoming support.
Which CipherMail settings are required for EDI@Energy?
The relevant domains require AES128_GCM, RSAES_OAEP_SHA256 or RSAES_OAEP_SHA512, and SHA256_WITH_RSA_AND_MGF1 or SHA512_WITH_RSA_AND_MGF1.
.png)
.png)