[openpgp] Deprecate legacy hash algorithms

[Werner Koch]

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 <***@gnupg.org>
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

[Hanno Böck]

On Fri, 17 Mar 2017 10:00:10 +0100

Post by Werner Koch
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.

[Werner Koch]

Post by Hanno Böck
I'm wondering: Should there be a clearer distinction that this is for
creation of messages?

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


Shalom-Salam,

Werner

[Jon Callas]

Post by Werner Koch
Hi,
Here is my suggestion on how to deprecate hash algorithms. The new text
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.

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

[Werner Koch]

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