...
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
- Define a way how to support SHA2 algorithms in PEPPOL AS2 profile
- Based on "eDelivery Capability extension work group" result document, chapter 3.2 (see file at the bottom of this page).
- 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:
- 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)
- Decide on a point in time where only the new algorithm names (with '-') will be supported (see 4-7 below)
- Suggestion on how to proceed (2018-04-27)
- Define a
- date X where receiving APs must be able to support both versions of the algorithm names (with '-' and without '-')
- By default the message should be send with : "sha1", "sha-1", "sha256", "sha-256" algorithm
- If that fails, the sender must fall back to "sha1" algorithm
- Question: is there a standardized error message to indicate "unsupported MIC algorithm"?
- The implications are: each sending AP must be able to fallback (at a certain point in time)
- Starting on X 1st, senders and receivers MAY start using "sha-256", receivers may start supporting "sha-256"
- Starting on Y 1st, all receivers MUST support "sha-256" in parallel to "sha1"
- Starting on Z 1st, all sender MUST only send "sha-256"; therefore receivers can drop support for "sha1"
- From date "X+1 day", sending APs should switch MDN MIC algorithms
- from "sha1" [...]
- to "sha-256", "sha256", "sha-1", "sha1" (in that order)
- By date Y (after X)
- receiving APs may drop support for "sha-1", "sha1" and "sha256". Only "sha-256" is mandatory
- sending AP must use "sha-256" only
- From date "X+1 day", sending APs should switch MDN MIC algorithms
If the above proposal is approved by MC and eDelivery CMB, next steps are:
- Proposed date for X=2018-10-31, Y=2019-01-31.
- Update PEPPOL AS2 specification document, make
- Make a eDelivery CMB decision and then publish
- Publish it A.S.A.P
- Verify that existing AP implementations can support "sha-256" according to RFC 5751 (S/MIME 3.2)
- Find values (year and month) for X , and Y and Z (see 4-7 bullet point 3 above)
- Evaluate other changes from RFC 5751 compared to RFC 3851 for "show stoppers" concerning interoperability
- Maintain a Confluence page that gathers all the information as well as known tool support
...
- 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)
- What are the differences in HTTP headers in the 3 phases:
-- EoD
Attachments
Attachments |
---|