Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Current »

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 5751 (dated Jan 2010) obsoletes RFC 3851 - S/MIME 3.2 Message Specification:

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.


-- EoD

Attachments

  File Modified
No files shared here yet.





  • No labels