Date: 2018-04-20

Time: 14:00-15:30 CEST

Type of meeting: Gotomeeting (https://www.gotomeet.me/peppoledelivery)

Participants and absents

Chair

Berg, Hans <hans.berg@tickstar.com> as eDelivery Community Leader

Elected members (with voting right)

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

Collanus, Risto <risto.collanus@visma.com>

Helger, Philip <philip.helger@brz.gv.at>

Langøy, Bård <bard.langoy@pagero.com>

Agenda

1. Define a way how to support SHA2 algorithms in PEPPOL AS2 profile
   1. Based on "eDelivery Capability extension work group" result document, chapter 3.2 (see file at the bottom of this page).
   2. Migration plan is needed

Background

PEPPOL AS2 profile mandates the use of "SHA 1" as the message digest algorithm for the non-repudiation of receipt.

SHA1 is considered an insecure hashing algorithm (see e.g. https://security.googleblog.com/2016/11/sha-1-certificates-in-chrome.html) and should be replaced a.s.a.p.

Abandoning SHA1 has implications on all PEPPOL AS2 AccessPoints.

SMPs, the SML and the the PEPPOL AS4 profile are not impacted by this issue.

The only other area affected by SHA1 is the PKI but the PKI v.2 ==> v.3 upgrade project (including an update of the hashing algorithm to SHA 256) will take care of this.

The original documents created by the eDelivery Capability Extension work group are attached at the bottom of this page for reference.

Discussion

• Current PEPPOL AS2 specification 1.01 references RFC 3851 - S/MIME 3.1 Message Specification
  • RFC 3851 (dated July 2004) allows for SHA2 algorithms, but only on a voluntary basis
  • https://www.ietf.org/rfc/rfc3851.txt
• RFC 5751 (dated Jan 2010) obsoletes RFC 3851 - S/MIME 3.2 Message Specification:
  • https://tools.ietf.org/html/rfc5751
  • It mandates the use of SHA 256 and makes the support for SHA1 and MD5 optional
  • The names of the MIC algorithms changes (RFC 3851: "sha256"; RFC 5751: "sha-256"), so it's easy to identify what version is used
  • All changes from RFC 3851 are documented in chapter 1.6 - https://tools.ietf.org/html/rfc5751#section-1.6

Proposal

To change the usage of SHA1 to SHA 256 in the PEPPOL AS2 profile the following steps are suggested:

1. Create a new version of the PEPPOL AS2 specification (e.g. v.1.2 - and not v.1.1 to avoid confusion since current version is 1.0.1) that references RFC 5751 instead of RFC 3851; also to add a note what the implications are (SHA-256 mandatory)
2. Decide on a point in time where only the new algorithm names (with '-') will be supported (see 4-7 below)
3. Suggestion on how to proceed (2018-04-27)
   1. Define a date X where receiving APs must be able to support both versions of the algorithm names (with '-' and without '-'): "sha1", "sha-1", "sha256", "sha-256"
   2. From date "X+1 day", sending APs should switch MDN MIC algorithms
      
      1. from "sha1" [...]
      2. to "sha-256", "sha256", "sha-1", "sha1" (in that order)
   3. By date Y (after X)
      
      1. receiving APs may drop support for "sha-1", "sha1" and "sha256". Only "sha-256" is mandatory
      2. sending AP must use "sha-256" only

If the above proposal is approved by MC and eDelivery CMB, next steps are:

1. Proposed date for X=2018-10-31, Y=2019-01-31.
2. Update PEPPOL AS2 specification document
3. Make a eDelivery CMB decision
4. Publish it A.S.A.P
5. Verify that existing AP implementations can support "sha-256" according to RFC 5751 (S/MIME 3.2)
6. Find values (year and month) for X and Y (see bullet point 3 above)
7. Evaluate other changes from RFC 5751 compared to RFC 3851 for "show stoppers" concerning interoperability
8. Maintain a Confluence page that gathers all the information as well as known tool support

The following things were discussed:

1. The usage of a separate transport profile (like "busdox-tansport-as2-ver1p0r1") is not favoured, because it would have implications not only on all APs but also on all SMPs.

Update 2019-01-29

• The specification document v.1.2 is finished and agreed upon
• Open issue is the migration support document, which should contain the following information
  • What are the differences in HTTP headers in the 3 phases:
    • Old AS2 specifcation
    • During the migration to AS2 v.1.2
    • After the migration when only AS2 v.1.2 is in effect
  • Outline the differences in all 3 phases for
    • Senders
    • Receivers creating an MDN
  • Migration period start: 2019-02-01 (first of February)
  • Migration period end: 2019-06-01 (first of June)

-- EoD

Attachments