Re: [openpgp] incomplete/confusing guidance around "Hash" Armor header for cleartext signing framework

Werner Koch <wk@gnupg.org> Fri, 19 March 2021 06:50 UTC

Return-Path: <wk@gnupg.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D8A3A145C for <openpgp@ietfa.amsl.com>; Thu, 18 Mar 2021 23:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiP9QICYdHOn for <openpgp@ietfa.amsl.com>; Thu, 18 Mar 2021 23:50:12 -0700 (PDT)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D053A145A for <openpgp@ietf.org>; Thu, 18 Mar 2021 23:50:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eCCPHH8TstTaU+1M3WIDZ5rB735nRM9bz+CAvgraB64=; b=hVss+CnvyklWl6pdQ/04nycLos fo7SlEa2YlxJf2s3CjJYQqEK53FX8gWEeCWOxxMz57PFtIFT4Itt2m/Y4XCAfSzsNmyYydhnBenK2 gKGcjnIi8+0l62+aKBHS2oFIck6knrqXzx9m8OH7zEHEiKk7gXfi+oRDPR4waSS+sycs=;
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1lN8xU-0002eF-23 for <openpgp@ietf.org>; Fri, 19 Mar 2021 07:50:08 +0100
Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1lN8wC-0002ql-IP; Fri, 19 Mar 2021 07:48:48 +0100
From: Werner Koch <wk@gnupg.org>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: openpgp@ietf.org
References: <875z1p7vva.fsf@fifthhorseman.net> <YFPbW9BLDdCn4E7I@camp.crustytoothpaste.net>
Organisation: GnuPG e.V.
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: "brian m. carlson" <sandals@crustytoothpaste.net>, openpgp@ietf.org
Date: Fri, 19 Mar 2021 07:48:48 +0100
In-Reply-To: <YFPbW9BLDdCn4E7I@camp.crustytoothpaste.net> (brian m. carlson's message of "Thu, 18 Mar 2021 22:59:39 +0000")
Message-ID: <87im5nprjj.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=CBOT_Bin_Laden_Spammer_SASP_Gang_Power_lines_Verisign_insurgency_dat"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/mEEnOOxmRwm0My5lSB2aHLj1gFU>
Subject: Re: [openpgp] incomplete/confusing guidance around "Hash" Armor header for cleartext signing framework
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Mar 2021 06:50:15 -0000

On Thu, 18 Mar 2021 22:59, brian m. carlson said:

> I agree that MD5 is right out.  If we expect implementations to need
> this to process a message correctly, then it should be mandatory, since
> if someone really wants to use MD5, they should be fine declaring that
> up front.  Practically, though, nobody will want to use MD5 for that

You can't do that for existisng data and thus we need to allow such a
default.  New messages should of course not be created using MD5 and
thus for all practical reasons SHA256 will show up there.  In any case
this is mostly irrelevant because what we have here is basically a
one-pass signature packet.  It needs to be matched against the signature
anyway and for the signature we have rules what algorithm may be used
(for new messages).

> interesting about the integrity of the message, so everyone will need to
> declare a hash.

Right.

> computational power.  I don't have a strong preference as to what we do,
> but I would like to leave the former possibility open because it
> drastically simplifies fast one-pass streaming implementations,
> especially if the clearsigned data is large.

Ack.


Salam-Shalom,

   Werner

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