Public Consultation

Status

CLOSED

Consulted Expert Group / StakeholdereDelivery community
OutcomeComments for input
Launch date

 

Due date

 

Disposition of Public Review Comments published

 

Main contact addressEC-EDELIVERY-SUPPORT@EC.EUROPA.EU

Update 13 February 2024

Publication of Disposition of Public Review Comments.

 

Original Communication

The eDelivery team is opening a Public Consultation on a new Draft Specification of the eDelivery AS4 profile 2.0, available here. The proposed specification was designed to work together with the new Draft Specification of the eDelivery SMP profile 2.0, which is equally open for public consultation.

The version of the new draft specification is set to 2.0 to illustrate that this is a backwards-incompatible evolution of the profile in that Access Points configured to operate with profile version 2.0 cannot exchange messages with Access Points configured to operate with profile version 1.x. It is noted that the backward incompatibility at the profile level does not preclude implementations from supporting both profile versions in the same product and allowing through configuration the parallel use of both versions (e.g., version 1.x when interacting with a legacy Access Point and version 2.0 when interacting with a new Access Point).

Compared to the current version, this new draft specification updates the security section by adopting more state-of-the art protocols and algorithms and proposes two new Profile Enhancements.


Updates to security section

The security parameters included in the eDelivery AS4 profile versions 1.x were high-end when they were selected but have only been marginally updated since 2014. The current profile is still secure but is no longer leading edge. New algorithms and key types based on elliptic curve cryptography are commonplace and their use is expected for new applications and protocols. The recently adopted IETF RFC 9231 allows their use in the XML Security, WS-Security and AS4 standards. By aligning the eDelivery AS4 profile with state-of-the-art security we look to provide continuity and investment protection.

Following the consultation of independent cryptography and XML encryption experts, the following changes are proposed:

  • for message signing, mandatory support for signing using Ed25519 (elliptic curve signature algorithm using EdDSA and Curve25519) is proposed in the Common Profile, replacing RSA.
  • for message encryption, mandatory support for encryption using X25519 (Elliptic Curve Diffie-Hellman Key Exchange using Curve25519) is proposed in the Common Profile, replacing RSA-OAEP key transport. The use of ECDH allows two parties to jointly agree on a shared secret using an insecure channel. The Common Profile proposes the use of ECDH in ephemeral-static mode (ECDH-ES), which requires a stable shared recipient public key and a constantly changing sender public key.
  • optionally, the use of ECDH in full ephemeral mode (ECDHE) is available in combination with the new ebCore Agreement Update profile enhancement that can be used to frequently replace the stable shared recipient public key.
  • optionally, support for ECDSA with Brainpool curves is proposed as a profile enhancement for cryptographic agility and/or interoperability with MS schemes.
  • modern TLS cipher suites and support for version 1.3 of Transport Layer Security are introduced and recommended in the Common Profile.


New Profile Enhancement for ebCore Agreement Update

The new version of the profile proposes the introduction of support for ebCore Agreement Update, an OASIS specification for interoperable message-based updating of messaging configurations. The use of ebCore Agreement Update allows the automation of configuration changes for direct trust / mutual exchange networks after the initial configuration, since upcoming certificate and/or endpoint changes can be communicated ahead of time using an existing secure and trusted channel. Communicating parties can then switch to them at the date & time agreed as part of the message exchange. This removes the dependency on central services. Certificate updates can include signing, encryption and key exchange certificates. Endpoint updates can include endpoint URLs, profile versions, algorithms and network security updates (e.g., outgoing/incoming IPs that must be configured in the firewall).

Where security is concerned, ebCore Agreement Update can be used to approximate full ephemeral ECDH since each party can be configured to automatically send a new key to each communication partner with some predefined frequency. The key could be the same for all partners or partner-specific.


New Profile Enhancement for supporting alternative curves and algorithms

In addition to the algorithms and curves proposed for the Common Profile, additional ones may be supported via implementation of this proposed profile enhancement: ECDSA for signing and key agreement based on Brainpool curves.

Important Note

The consultation is launched with the proposed selection (mandatory support for Ed25519 and X25519 and optional support for ECDSA and Brainpool curves). While from a cryptographic perspective this is the recommended approach, during the period of the public consultation, the eDelivery team will further investigate the practical implications of this choice for both AS4 implementers and end users. Based on this investigation and the input received during the consultation, the specification may be revised to mandate support for both options – (1) Ed25519 and X25519 and (2) ECDSA and Brainpool curves – in the Common Profile. You are invited to provide input regarding this matter as well.


Supporting documents

For the preparation of the new Draft Specification, the eDelivery team consulted different security experts. The key documents elaborated by the experts are published below.

  File Modified
PDF File (eDelivery).(eDelivery AS4 Security Profile - Cryptography Related Recommendations).(v1.0).pdf Nov 03, 2023 by Bogdan DUMITRIU
PDF File (eDelivery).(eDelivery AS4 Security Profile - Update Recommendations).(v1.0).pdf Nov 03, 2023 by Bogdan DUMITRIU


Please post your comments on this page or send them to EC-EDELIVERY-SUPPORT@ec.europa.eu with [eDelivery AS4 profile version 2.0] in the title of the email.


1 Comment

  1. Sander Fieten

    Nov 09, 2023

    I'm providing the following feedback on behalf of the OASIS BDXR TC.

    Since the focus of the OASIS BDXR TC is on the 4-Corner network model, the focus of our review was also mainly on the parts related to the use of AS4 in such networks. Please find our comments, which we believe help in improving interoperability when implementing the profile, below:

    • As the SBDH specification is outdated and replaced by the XHE specification, replace the SBDH profile enhancement with an XHE profile enhancement or add an XHE profile enhancement and deprecate the current SBDH one.
    • Require or recommend (depending also on keeping the SBDH enhancement) the usage of the XHE for 4-Corner topologies based on the OASIS AS4 Interoperability Profile for Four-Corner Networks specifications. Also use the EndpointParticipantIdentifier message property defined in the OASIS specification to identify the Access Point that should receive technical response messages as described in section 3 of the OASIS specification.
    • It is unclear what the benefits are of changing from key transport to key agreement taking into account there is no or very limited support for key agreement in implementations. Instead of improving interoperability this changes rather seems to increase risk of incompatibilities. There are also no [known] security risks with key transport and the current cryptographic algorithm advisories from both NIST and BSI still accept its use based on the RSAES-OEP algorithm.
    • Because static keys are still used the introduction of key agreement won't provide forward secrecy. This however could be achieved when the sender would first need to query an SMP server to get the certificate to use as the receiver can then return the ephemeral certificate in the SMP response. The SMP response itself could be signed by the long term certificate of the receiver.