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 12 Next »

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. Define a grace period, where sender must be able to support both versions of the algorithm names (with '-' and without '-')
    1. By default the message should be send with "sha-256" algorithm
    2. If that fails, the sender must fall back to "sha1" algorithm
      1. Question: is there a standardized error message to indicate "unsupported MIC algorithm"?
    3. The implications are: each sending AP must be able to fallback (at a certain point in time)
  4. Starting on X 1st, senders and receivers MAY start using "sha-256", receivers may start supporting "sha-256"
  5. Starting on Y 1st, all receivers MUST support "sha-256" in parallel to "sha1"
  6. Starting on Z 1st, all sender MUST only send "sha-256"; therefore receivers can drop support for "sha1"
  7. ==> Between X 1st and Z 1st, AP clients must be able to fallback from "sha-256" to "sha1"

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

  1. Update PEPPOL AS2 specification document, make a eDelivery CMB decision and then publish it A.S.A.P
  2. Verify that existing AP implementations can support "sha-256" according to RFC 5751 (S/MIME 3.2)
  3. Find values (year and month) for X, Y and Z (see 4-7 above)
  4. Evaluate other changes from RFC 5751 compared to RFC 3851 for "show stoppers" concerning interoperability
  5. 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