Section 4.2: Port numbers are not mentioned at all in CEF AS4 Profile. The limitation to port 443 should be removed. But avoid opening all ports for outgoing traffic, it was decided to limit the port to be 443 or in the range 44300 (incklusive) to 44399 (inclusive) so that a) outgoing ports can be limited and b) non-standard ports can be used.

Comment #5: Section 4.5 Party identification: Martin Forsberg has requested if "PMode.Initiator.Role and Responder. Role could be assigned more generic identifiers". It was decided that Martin Forsberg should be contacted to elaborate on this.

Martin Forsberg has explained this on Oct 19: "If it would be possible that CEF defines the 4 corner AP role so we don't have to reconfigure when the AP is used in another SML zone, such as in domestic eDelivery"

Input needed

Further clarification is needed on the following issues: ID 5, ID 14 and ID 16. Further, issue #1 (port numbers) should be discussed with CEF.

A better policy for the TLS certificates is urgently needed - the current statement that SSL certs should be supported "Oracle" and "Microsoft" is too vague. There is a recent case with a CA which is included in Mozilla's truststore since 9 years so they should be considered trustworthy (https://partnergate.sonera.com/javaohje_en.html)

Decisions

Issue #2: Version 0.9.2: remove the section
ID #1: 4.2. Configuration of Transport Level Security (TLS): Allow port 443 and port range 44300-44399.
ID #3: 4.7. Use of PEPPOL PKI: Add the sentence "AS4 message level encryption MUST be used even though TLS is used."
Section 4.4 Feedback when receiver is not serviced: Explain what MSH means and that the meaning of "Payload" is the SBDH. Maybe find a better term for "custom validations" as it might be misinterpreted.
ID #4: Section 4.4 Feedback when receiver is not serviced: Sentence number 2, change it to "If a MSH is able to validate the SBDH payload inside the AS4 User Message during the ebMS message processing, it is RECOMMENDED that the Access Point includes the check on the addressee."
ID #5: Section 4.5 Party Identification: Ask Martin Forsberg to Elaborate on why he has requested if "PMode.Initiator.Role and Responder. Role could be assigned more generic identifiers". We will reach out to Jerry Dimitriou to provide more input on this section.
ID #6: Section 4.6 Service, action and role: Replace "PEPPOL BIS" with "business documents"
ID #7: see decision on ID #3
ID #8: Section 4.10 Message packaging: Add sentence stating "compress first, then encrypt"
ID #9: Section 4.2 Configuration of Transport Level Security (TLS): Add sentence "TLS v1.2 MUST be supported. Older versions (SSL v2, SSL v3, TLS 1.0 and TLS 1.1) MUST NOT be used. Versions newer than TLS v1.2 might be used upon mutual agreement via the TLS handshake."
ID #10: Chapter 4.1 Exchange patterns: See decision to ID #9.
ID #11: Chapter 4.4 Feedback when receiver is not serviced: rejected
ID #12: Chapter 6.2 SMP transport profile identifier: Split chapter 6.2 into 2 separate ones: a) SMP transport profile identifier Stating only the transportProfileIdentifier (please note the typo in the current version - it should be peppol-transport-as4-v2_0) b) AS4 and dynamic discovery Outline that new P-Modes may need to be created per document exchange and outline what SMP response values fit where in a PMode. Also a note that this feature is non-standard AS4 might be worthwhile.
ID #13: Chapter 6.2 SMP transport profile identifier: See decision to ID #12.
ID #14: Chapter 5 P-Mode parameters: Align chapter 4.5 with Table 7 - the inconsistencies need to be resolved.
ID #15: Chapter 4.9 Use of SBDH: Issue: https://issues.oasis-open.org/projects/EBXMLMSG/issues/EBXMLMSG-2. Include in the discussion with Martin Forsberg on ID #5; suggestion to remove the attribute "type" under the precondition that it is otherwise possible to clearly identify that the role is "PEPPOL AccessPoint"
ID #16: No decision was made. Will be handled via e-mail between TICC CMB members before Oct 19 (when the next AS4 work meeting is scheduled).
ID #17: Please add the sentence from PEPPOL AS4 profile V1: As the eb:ConversationId element is required it MUST always have a value. If no value is included in the submission of the business document to the Access Point, the Access Point MUST set the value of eb:ConversationId to “1” as specified in section 4.3 of [ebMS3CORE].
ID #18: See response to ID#12.

Next Step

TICC CMB will ask Jerry Dimitriou and CEF for advice on comments #1, #5, #14, #16 and then pass the decisions on to the AS4 workgroup (Erlend Klakegg Bergheim (Deactivated), Bård Langöy, Philip Helger, Even Østvold, Rune Kjørlaug (Unlicensed), Jerry Dimitriou) to:

evaluate if the PEPPOL AS4 profile is still aligned with the CEF AS4 profile
implement the decisions into the PEPPOL AS4 specification document

TLS Requirements

Validity check on date: MUST
CLR/OCSP check: SHOULD
Server hostname check: NO
Self-signed: NO
Check of trust chain: ???
- „Microsoft and Oracle“ or
- Trust any or
- PEPPOL maintains trusted ROOT CAs

-- EoD

Attachments

	File	Modified

No files shared here yet.

eDelivery Network (TICC) Coordinating Community

TICC work meeting 2018-10-11,12,19,31

Participants and absents

Agenda

Background

Discussion

Input needed

Decisions

Next Step

Attachments