Date: 2019-02-06

Time: 16:00-17:30 CET

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

Participants and absents

Chair

@Hans Berg (Deactivated) 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)

Guests (without voting right)

• @Magnus Johansson (stand-in for POACC Leader @Sören Pedersen)

Agenda

1. Approval of minutes

   1. TICC CMB 2019-02-01 minutes

2. RFC 7230 vs RFC 2616, https://openpeppol.atlassian.net/browse/TICC-69

3. AS2 specification - is a new transport profile id necessary? (Question from Difi)

4. Plan TICC activities during upcoming 1.5 day face2face meeting (March 26-27 in Brussels).

   1. Prel agenda skeleton created by @Hans Berg (Deactivated), available upon request.

5. OASIS specs for SMPs

6. Remove off boarded SMPs from SML (along with the participants registered).  https://openpeppol.atlassian.net/projects/TICC/issues/TICC-19

7. Info: PKI v.3 migration status

8. Unresolved tasks and tickets in the Action Log

Topics not discussed

• #5, #6, #7 and #8

Information items

• #1 done

• #2 Bard prepared a document outlining the differences

  • https://docs.google.com/document/d/1gixoO1x-rS_iK0E6pT7-981DIavBwiyi-x_ep99PAMw/edit?ts=5c5716f6#

  • TICC CMB to update the AS2 profile accordingly

  • New version will be 1.3 - TIA Annex 4 must be updated

  • The new version was created, reviewed, finalized and published during the meeting

  • Bard copied the content of the analysis to TICC-69

• #3 Is a new transport profile ID for AS2 v.1.3 necessary?

  • TICC CMB does not see the necessity for this because:

    • The existing AS2 RFC allows for the usage of different hashing algorithms, based on a priority list

    • The existing AS2 RFC allows to support both old and new mandatory algorithms together, so that it will be compliant with the old AND the new PEPPOL AS2 profile in parallel (as outlined in the specification document itself).

    • The relevant HTTP header is the one asking for the MDN ("disposition-notification-options"). The relevant part is the "signed-receipt-micalg" subelement, that is currently filled like "required, sha1, md5". For the transition phase it can be "required, sha-256, sha256, sha-1, sha1", meaning

      • First algorithm to use is "sha-256" (RFC 5751 name), followed by "sha256" (RFC 3851 name), followed by "sha-1" (RFC 5751 name) and last "sha1" (RFC 3851 name).

      • APs that already support the new algorithm suite will most likely sign the MDN using "sha-256"

      • Old APs that still only support the old algorithms will most likely sign the MDN using "sha1"

    • Not having a new transport profile heavily simplifies the transition period (less SMP entries, less confusion, less support effort)

• #4 Brussels Face2Face Agenda document was edited inline; cross check with POACC leader is needed

Decisions

1. TICC CMB 2019-02-01 minutes were approved

Action items

1. see TICC CMB action log.

Attachments