...

Guests (without voting right)

• magnus.johansson@digg.se Magnus Johansson (stand-in for POACC Leader Sören Pedersen (Unlicensed))

Agenda

1. Approval of minutes
   1. TICC CMB 2019-01-18 minutesTICC CMB 201902-01 -28 minutes
2. RFC 7230 vs RFC 2616, 

   Jira Legacy
   server System JIRA serverId b5b0ccd0-0a1a-35a3-9e9e-6e3b9531d004 key TICC-69

   OASIS specs for SMPs
3. AS2 specification - is a new transport profile identifier 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, #9 and #10

Information items

1. Status on #1
   1. Minutes of TICC CMB 2019-01-18 minutes were approved unanimously
   2. Minutes of TICC CMB 2019-01-28 minutes were approved unanimously
2. Status on #2
   1. AS2 profile:
      1. v1.2 was finalized and published on GitHib, news item was sent out
      2. Open issue: migration policy document (Jerry to provide it until 2019-02-08)
      3. Impact of RFC 7230 as proposed by TICC-69 need to be evaluated (see below)?
      4. Difi on new transport profile identifier - see agenda item #6
   2. Policy for use of identifiers:
      1. v4 was published on GitHub and is in effect for new BIS documents, news item was sent out, the specification is "in use"
   3. Transport Security Policy:
      1. v1 was published on GitHub, it will be in production when the new TIA Annex 4 becomes mandatory
   4. Directory Specification:
      1. No action needed
   5. Envelope Specification:
      1. Draft provided by Jerry and Philip, see Agenda item #4 - tbd
3. #3 - AS2 RFC update for HTTP/1.1
   1. Differences RFC 7230 vs RFC 2616: https://tools.ietf.org/html/rfc7230#appendix-A.2
   2. Bård to check the differences - see action log
4. #4
   1. The document was reviewed and published on GitHub
5. The latest specification documents in https://github.com/OpenPEPPOL/documentation/tree/master/TransportInfrastructure where renamed to follow the new scheme "PEPPOL-EDN-<specname>-<version>-<date>.<extension>". This holds true for AS2 1.2, Directory 1.2, Transport Security 1.0 and Policy for use of Identifiers 4.0
6. AS4 specification needs update on Policy for use of identifiers reference (http://docs.peppol.eu/edelivery/as4/specification/#_configuration_of_transport_level_security_tls)
7. Next meeting on Wednesday 2019-02-06, 16:00 to 17:30 CET

...

• #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

...