bdxr — archive

[Pim van der Eijk]

Hello, This email contains some comments on AS4 Profile for Four-Corner Networks Version 1.0 , https://www.oasis-open.org/committees/document.php?document_id=68261&wg_abbrev=bdxr . It is based on experience in creating and using the CEF eDelivery AS4 profile, a set of implementation guidelines for using AS4 maintained by the European Commission, https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+AS4 . eDelivery is widely used in both the public and private sector internationally. So before giving my comments, here is some background information on eDelivery. This is FYI only, and is all based on publicly available information. The original version of eDelivery AS4 was based on a four corner profile of AS4 developed in the EU eSENS project, which in turn inherited its base profiling from work done in the energy sector by ENTSOG. In recent versions, the eDelivery AS4 has been restructured and modularized into a Common Profile and a set of optional Profile Enhancements and eight separate conformance clauses. The Common Profile covers general aspects such as profiling of security and compression features, and required support for Push. It is compatible and can be used with any of the Profile Enhancements. One of the optional Profile Enhancements is a four corner topology enhancement. This Profile Enhancement provides a mechanism based on AS4 message properties originalSender and finalRecipient for C1 and C4 to account for the fact that a message in a four corner topology relates to four parties rather than just two (C2 and C3) as in point-to-point exchanges. Two other and separate enhancements, Dynamic Receiver and Dynamic Sender, address two aspects of messaging involving dynamic discovery . This modular structure has many advantages: It is easier to claim and test conformance, as the notion of conformance reflects the modular structure. Vendors can implement only those enhancements that are of relevance to their users. Features (Pull, Split/Join) have been added using enhancements as they are only of interest to some users. Some existing user communities of the Four Corner topology do not use dynamic discovery at all. Some existing communities are star topologies and use the Dynamic Receiver feature at the center node and static configuration at the outer nodes. There is a key dependency from the Enhancement on the Common Profile. If that changes (and incompatible changes are very much expected in the security section within the next few years), it impacts all implementations and all users. However, since the details of the Common Profile are not relevant, the enhancements do not need to change and can evolve independently. The eDelivery Dynamic Sender enhancement uses the language Discovery Infrastructure and defines requirements on functionality it should provide. This decouples the eDelivery AS4 profile from specific versions of SMP. SMP profiling, including version selection, is done in a separate guideline, https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+SMP . In fact, stating requirements on discovery infrastructure instead of a specific specification even allows eDelivery AS4 to be used with protocols other than SMP that provide the same requirement functionality. The eDelivery AS4 profile leaves implementation options for parameters such as party role and party identifier type open. The reason is that most user communities have their own conventions. For party identifier type, eDelivery recommends the ebCore Party Identifier Type, https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+ebCore+Party+ID , which allows reuse of existing identifier schemes. eDelivery AS4 requires support for Push but it has an optional Profile Enhancement for Pull. With this introduction and based on this experience, some comments on the draft: This draft covers common profiling aspects that have nothing to do with four corner networks, but are more general AS4 profiling issues. Examples: It sets the signature algorithm to http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 . Many user communities are likely to migrate away from this algorithm as cryptographic consensus is that this is a legacy algorithm. So hard-wiring this algorithm in this four-corner specification almost makes it obsolescent from the start. More generally, information security agencies have their own guidelines on security algorithms, which differ between various geographies. A fixed value is provided for party role. User communities tend to have their existing role role code schemes that they want to reuse. A fixed value is provided for party identifier type. As noted, user communities have their existing identifier type schemes that they want to reuse. It mandates One Way Push. Some four corner user communities may prefer to use Pull or Two Way exchanges. There is no equivalent to the eDelivery AS4 Four Corner Profile enhancement. It is the one feature I would expect to find in this document. How is this aspect handled? There is an informative reference to XHE, maybe you want to encode C1 and C2 in XHE or some other internal payload. However, XHE is not referenced anywhere in the text. It seems dynamic discovery is considered a mandatory feature. There are only informative references to SMP 1.0 and SMP 2.0, but other parts of the spec seem to require support for at least one of them. In the eDelivery experience, some users of AS4 in four corner networks do not use dynamic discovery at all. Some only use Dynamic Receiver . The specification requires the value of CN field of the signing certificate to exactly match the value of the party identifier. This is problematic with certificates obtained from commonly used Certification Authorities. Sometimes the organizationIdentifier field is a better option, and this is also more in line with ETSI ESI norms. There is no conformance section. Apart from it being a mandatory part of an OASIS specification, it could be used to define variants based on different SMP versions. So in summary, this draft does not seem to be a specification for using AS4 in a four corner topology. It is a more general profile that also hardwires other unrelated aspects to specific values that other existing users of AS4 in four corner topologies do not necessarily agree to. By restricting these other aspects, this draft unfortunately is incompatible with any other profile or implementation guideline for AS4 that makes different choices. That includes eDelivery AS4 or ETSI EN 319 522. The draft also lacks the single four-corner specific functionality I would expect to be defined here. Thanks for sharing the draft, and hope you find this feedback useful. Also, apologies for not sending it more in advance of the TC meeting. I can't attend the TC meeting due to other commitments. Kind Regards, Pim