Subject: [openpgp] Deprecate legacy hash algorithms

From: Werner Koch <[email-masked]>
Date: Fri, 17 Mar 2017 10:00:10 +0100

Hi,

Here is my suggestion on how to deprecate hash algorithms.  The new text
is:

  Implementations MUST implement SHA-256.  Implementations MAY implement
  other algorithms.  Implementations MUST NOT create messages which
  require the use of SHA-1 with the exception of computing version 4 key
  fingerprints and for purposes of the MDC packet.  Implementations MUST
  NOT use MD5 or RIPE-MD/160.

Rationale below.

Salam-Shalom,

   Werner

--8<---------------cut here---------------start------------->8---
From b03e6b2a2a41a724571c7aa3ad8ef134aec8f348 Mon Sep 17 00:00:00 2001
From: Werner Koch <[email-masked]>
Date: Fri, 17 Mar 2017 09:54:18 +0100
Subject: [PATCH] Deprecate legacy hash algorithms

MD5 has been deprecated for a long time; using MOST NOT implement is
thus due.

SHA-1 is still required to verify existing signature and can't be
deprecated.  However it is not anymore a mandatory algorithm with the
exception of MDC packets which we need to support at least read-only
for the foreseeable future.

Upgrading SHA-256 to a mandatory algorithm should be obvious.

Keeping SHA-512 optional benefits implementations on low end
platforms.
---
 middle.mkd | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/middle.mkd b/middle.mkd
index 874f107..25524b6 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -3078,8 +3078,11 @@ ## {9.4} Hash Algorithms
        11  SHA224 [](#FIPS180)              "SHA224"
  100--110  Private/Experimental algorithm
 
-Implementations MUST implement SHA-1.  Implementations MAY implement
-other algorithms.  MD5 is deprecated.
+Implementations MUST implement SHA-256.  Implementations MAY implement
+other algorithms.  Implementations MUST NOT create messages which
+require the use of SHA-1 with the exception of computing version 4 key
+fingerprints and for purposes of the MDC packet.  Implementations MUST
+NOT use MD5 OR RIPE-MD/160.
 
 # {10} IANA Considerations
 
-- 
2.8.1
--8<---------------cut here---------------end--------------->8---

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Hanno Böck <[email-masked]>
Date: Fri, 17 Mar 2017 16:05:30 +0100

On Fri, 17 Mar 2017 10:00:10 +0100
Werner Koch <[email-masked]> wrote:

>   Implementations MUST implement SHA-256.  Implementations MAY
> implement other algorithms.  Implementations MUST NOT create messages
> which require the use of SHA-1 with the exception of computing
> version 4 key fingerprints and for purposes of the MDC packet.
> Implementations MUST NOT use MD5 or RIPE-MD/160.

I'm wondering: Should there be a clearer distinction that this is for
creation of messages?

Because for verification I feel supporting bad algorithms is still
okay. Like if I want to verify a signature done with md5 it makes sense
that I'm able to do that. Ideally that would include a warning ("This
message was sigend with a weak hash alg"), but not supporting it
doesn't seem right.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: Jon Callas <[email-masked]>
Date: Fri, 17 Mar 2017 11:09:57 -0700

> On Mar 17, 2017, at 2:00 AM, Werner Koch <[email-masked]> wrote:
> 
> Hi,
> 

My only comment is that if you're going to "deprecate" as opposed to "ban" then the term needs to be SHOULD NOT rather than MUST NOT. MUST NOT is a ban, not deprecation.

I prefer deprecation (SHOULD NOT) over banning (MUST NOT)  because a ban leads either to people being silly about a lack of backwards compatibility or they just defiantly ignore the ban. 

	Jon

---

From: Werner Koch <[email-masked]>
Date: Tue, 21 Mar 2017 08:16:48 +0100

On Fri, 17 Mar 2017 19:09, [email-masked] said:

> I prefer deprecation (SHOULD NOT) over banning (MUST NOT) because a
> ban leads either to people being silly about a lack of backwards
> compatibility or they just defiantly ignore the ban.

Good point.  I am also fine with SHOULD NOT.

Salam-Shalom,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Tue, 21 Mar 2017 08:15:38 +0100

> I'm wondering: Should there be a clearer distinction that this is for

IMHO this is more an implementation issue than something which needs to
be done in the standard.

Shalom-Salam,

   Werner