...

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

Participants and absents

Chair

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

...

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.

...

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

...

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