Date: 2019-02-12

Time: part 1 10:00-10:40 and part 2 11.30 to 12.30 CET

Type of meeting: Gotomeeting (https://global.gotomeeting.com/join/704521469)

Participants and absents

Chair

Hans Berg (Unlicensed) as eDelivery Community Leader

Elected members (with voting right)

Kristiansen, Olav Astad <Olav.AstadKristiansen@difi.no>

Risto Collanus (Maventa)

Philip Helger (BRZ Austria)

Bård Langöy (Pagero) (not present part 1, 10.00-10.40)

Guests (without voting right)

• Jerry Dimitriou (OpenPEPPOL Operating Office)

Agenda

1. Discussion regarding AS2 v.1.3 and the input from Jerry Dimitriou regarding wether to introduce a new transport profile id or not.

Information items

Input from Jerry Dimitrou:

Regarding the use of a new identifier for the new AS2 spec and the current proposed migration process, the problem is on the original signed document which is submitted (the change to RFC 5652).  The described migration process without the change of the identifier might be feasible if the only thing changed was the mic algorithm of the MDN. However, it does not take into account that the submitted message MUST be signed with using SHA-256 algorithms following RFC 5652.

Assuming that we are in the transition period using the same identifier for the new specification and using the headers as it was described in TICC, the following will happen:

1. C2 now supports SHA-256 signing, and sends the AS2 message signed with SHA-256.
2. C3 is not supporting yet SHA-256, and thus rejects the message, although the correct identifier is used.

A more explicit transition process including new transport profile identifier (such as 'busdox-transport-as2-ver2p0') for the new AS2 profile could work smoother:

1. C3, not supporting yet SHA-256, is publishing only the old AS2 Protocol identifier
2. C2, supporting SHA-256, first checks the SMP if C3 supports SHA-256. It gets a negative response and makes second query using the original, mandatory during the transition period, AS2 protocol identifier. No message is rejected.

Alternatively:

1. C3, is now ready to support SHA-256 and is making a new registration entry in the SMP.
2. C2, supporting only SHA-1, first checks the SMP if C3 supports SHA-1 and gets  the original, mandatory during the transition period, AS2 protocol identifier. No message is rejected.

After the transition period, the submission APs will only check for the new identifier, so any stalled APs will not be discoverable any more (Less error rejections also after the transition).

Also, from an organizational perspective, since the new AS2 protocol spec is backwards incompatible with current AS2 spec, a different protocol version will clearly denote that. As a side effect, we will also have the DEPRECATED flag on the codelist, making it clear that this is no longer used and that a new incompatible specification now is in use.

Summary

SMP providers should

1. Remove old transport profile id at a certain date/time
2. Assign new Transport Profile ID to all endpoints/participants after previous step has been performed.

To-do’s

1. Include the new transport profile id 'busdox-transport-as2-ver2p0'
2. Include http/1.1 (as in v.1.3) (see  TICC-69 - Getting issue details... STATUS )
3. Member review (until March 10)
4. Comment resolution (until ≈ March 17)
5. Release PEPPOL AS2 profile v.2.0 specification
6. Decide a migration start date / end date for service providers
7. Propose the above steps to the MC for approval

Decisions

1. TICC CMB will draft a v.2 of the AS2 profile that is based on 1.3 but adding a new transport profile id (busdox-transport-as2-ver2p0)

Action items

1. Philip Helger to draft a v.2 of the AS2 profile as suggested above.

Attachments