Versions Compared

Old Version 13

changes.mady.by.user Hans Berg

Saved on

compared with

New Version 14

changes.mady.by.user Philip Helger

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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 1st and Z 1st, 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 1st
    1. senders and receivers MAY start using "sha-256"
    2. receivers may start supporting "sha-256"
  5. Starting on Y 1st
    1. all receivers MUST support "sha-256" in parallel to "sha1"
  6. Starting on Z 1st
    1. all sender MUST only send "sha-256"; therefore receivers can drop support for "sha1"
    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. 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 , and Y and Z (see 4-7 bullet point 3 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

...