Page Comparison

...

Abandoning SHA1 has implications on all PEPPOL AS2 AccessPpointsAccessPoints.

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.

...

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, than 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 1^st, senders and receivers MAY start using "sha-256", receivers may start supporting "sha-256"
5. Starting on Y 1^st, all receivers MUST support "sha-256" in parallel to "sha1"
6. Starting on Z 1^st, all sender MUST only send "sha-256"; therefore receivers can drop support for "sha1"
7. ==> Between X 1^st and Z 1^st, AP clients must be able to fallback from "sha-256" to "sha1"

...