Re: [art] not an erratum in RFC 6376, was Argh!!!! onto https://www.rfc-editor.org/errata.php

Steffen Nurpmeso <steffen@sdaoden.eu> Thu, 21 March 2024 01:31 UTC

Return-Path: <steffen@sdaoden.eu>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF9EC14F5F9 for <art@ietfa.amsl.com>; Wed, 20 Mar 2024 18:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sdaoden.eu header.b="Sb7BM2U8"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=sdaoden.eu header.b="oulxIguL"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bEq_4X8ycgo for <art@ietfa.amsl.com>; Wed, 20 Mar 2024 18:31:10 -0700 (PDT)
Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7D0C14F61C for <art@ietf.org>; Wed, 20 Mar 2024 18:31:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1710984663; x=1711651329; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding:author:from:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:mime-version:content-type:content-transfer-encoding:message-id: mail-followup-to:openpgp:blahblahblah; bh=siNCAFsnXe0HOV3glKMBViW8rzKU64xO3+qhyYH01tU=; b=Sb7BM2U8qrbOJb1Ro1PPn3glF9SZJMJaLUScvX63jZ8XmFQstfExlnXyXeLhoAEg98Yu8WQ2 dG7azY47UfVGMP26/YeCf2kDoOcc3KFbVqh54kIozaRgf/Q9TD+jlhHqqiPFcjaYzu/QM63SL/ XDps2C1kO0jT47Z0ORYX1Wn/+yUqSAUEA/I6Q+g/kZH9uVKblI7IlJcnaJ3LQTy61cd8KjSj50 ln8gkcFRmj7i41d5QQD+6iCBm+ewuoSkTH6z5A8ruy5vXZBjWUzNfVIqBSg0XXYKwXHAh8xnMp 4c+I6cAL02fjve0mzin9RWTSim0ZjXamyorC9cbyWO/N1Q6w==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1710984663; x=1711651329; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding:author:from:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:mime-version:content-type:content-transfer-encoding:message-id: mail-followup-to:openpgp:blahblahblah; bh=siNCAFsnXe0HOV3glKMBViW8rzKU64xO3+qhyYH01tU=; b=oulxIguLevQE1UltL1HpSeBt6+rStEiF/aFy2oje/KxK1pJFE19HuhBCtjSIGVj5ZF7lQvU7 CJfiQCZ4qglABw==
Date: Thu, 21 Mar 2024 02:31:00 +0100
Author: Steffen Nurpmeso <steffen@sdaoden.eu>
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: art@ietf.org
Message-ID: <20240321013100.njaKjjEY@steffen%sdaoden.eu>
In-Reply-To: <CAL0qLwbR6P4WQUqT9jMNpRWvXbcg5Zow-rybKD3PKB+nsi_GUA@mail.gmail.com>
References: <20240320211242.57E4085CEF48@ary.qy> <20240320223000.GvPm_uV2@steffen%sdaoden.eu> <CAL0qLwbR6P4WQUqT9jMNpRWvXbcg5Zow-rybKD3PKB+nsi_GUA@mail.gmail.com>
Mail-Followup-To: "Murray S. Kucherawy" <superuser@gmail.com>, art@ietf.org
User-Agent: s-nail v14.9.24-612-g7e3bfac540
OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt
BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs.
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/a8Dd_qO8H-4L0xaAmSY59UGB3JA>
Subject: Re: [art] not an erratum in RFC 6376, was Argh!!!! onto https://www.rfc-editor.org/errata.php
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2024 01:31:15 -0000

Murray S. Kucherawy wrote in
 <CAL0qLwbR6P4WQUqT9jMNpRWvXbcg5Zow-rybKD3PKB+nsi_GUA@mail.gmail.com>:
 |On Thu, Mar 21, 2024 at 8:30 AM Steffen Nurpmeso <steffen@sdaoden.eu> \
 |wrote:
 |> But .. that is what happens in real life software?  Maybe one
 |> should even add a paragraph stating that, and mention the Sendmail
 |> milter protocol, which possibly is the culprit of what happens.
 |> (Though _why_ that is, since the other possibilities would have
 |> worked out just equally well?  Ie, literal bytes or simple
 |> stripping.  I cannot tell, i was not around anything email around
 |> 2006-2011 when that seems to have been developed.)
 |>
 |> I did ask on -dkim@ and implemented as written and said, but DKIM
 |> verification fails for such multiline headers from milter
 |> communication if RFC 6376 is followed exactly.  (Thankfully DKIM
 |> has a certificate test mode built-in, otherwise some reputation
 |> downgrade (if at all possible in my case) would surely have kicked
 |> in!  It is a great standard!)
 |>
 |
 |milter provides multiline headers separated by LFs, not CRLFs.  I don't
 |recall why it was done this way, but that's how it's been since the
 |beginning.  This is in the milter API documentation, which is (or used to
 |be) packaged in the sendmail source tarball.  You can find it online too;
 |for example:
 |
 |https://www.ibm.com/docs/en/aix/7.2?topic=functions-xxfi-header-callback\
 |-function

Well i actually had that around all the time, it is in the FreeBSD
source code that i track.  But i myself used the plain text
document  $Id: milter-protocol.txt,v 1.6 2004/08/04 16:27:50 tvierling Exp $
which does not mention this.

But *regardless* of all that.
If you do not treat LF as whitespace, you get failing signatures,
unless i am now totally confused.
Btw i posted OpenDKIM code of a canonicalization function which
does *not* do what you say this very evening, but it uses
isspace(3) on header field body content?!?

Good night from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)