You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This page is currently a copy of the previous consultation page, restricted to SMCO and profile specialists and will need to be updated!

Public Consultation

Status

CLOSED

Consulted Expert Group / StakeholdereDelivery community
OutcomeComments for input
Launch date

 

Due date

 

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

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.


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.


  • No labels