TICC CMB 2019-02-06 minutes


 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 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)

Agenda

  1. Approval of minutes
    1. TICC CMB 2019-02-01 minutes
  2. RFC 7230 vs RFC 2616,  TICC-69 - Getting issue details... STATUS
  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, 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
  • #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

  File Modified
No files shared here yet.