Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

"Mark Delany" <sx6un-fcsr7@qmda.emu.st> Thu, 08 February 2018 17:21 UTC

Return-Path: <ietf-dkim-bounces@mipassoc.org>
X-Original-To: ietfarch-ietf-dkim-archive@ietfa.amsl.com
Delivered-To: ietfarch-ietf-dkim-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660C212700F for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Thu, 8 Feb 2018 09:21:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.789
X-Spam-Level:
X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emu.st
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 9ZTWzuqbriE3 for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Thu, 8 Feb 2018 09:21:46 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 13ADD126D73 for <ietf-dkim-archive@ietf.org>; Thu, 8 Feb 2018 09:21:46 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [127.0.0.1]) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w18HKgCo004525; Thu, 8 Feb 2018 09:20:43 -0800
Authentication-Results: simon.songbird.com; dkim=fail reason="verification failed; unprotected key" header.d=emu.st header.i=@emu.st header.b=HvSuCBhQ; dkim-adsp=none (unprotected policy); dkim-atps=neutral
Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w18HKcT7004519 for <ietf-dkim@mipassoc.org>; Thu, 8 Feb 2018 09:20:40 -0800
Received: by f3.bushwire.net (Postfix, from userid 1001) id D539E34AA1C; Fri, 9 Feb 2018 03:19:41 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2017; t=1518110381; bh=W5Rni3l+DodDNDZ7/au+/4wsLjw=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=HvSuCBhQJEA8WRyYQVIvQ/F1TUrYojWOdLIbapOQNKdw4N+Oi4eHwL4xx8mJ36qSg sIZl/euYAIJ/ICMc8rGiMObLfz5PXULK2fYCSF6RK2VFzF/6J7dYhT1djWf03MdUw6 6JLAbPP/GlSfpd7jaWpda4LyWtDaE2obJg8itDe4=itDe4=
Comments: QMDA 0.3a
Received: (qmail 25534 invoked by uid 1001); 8 Feb 2018 17:19:41 -0000
Date: Thu, 08 Feb 2018 17:19:41 +0000
Message-ID: <20180208171941.25533.qmail@f3-external.bushwire.net>
From: Mark Delany <sx6un-fcsr7@qmda.emu.st>
To: ietf-dkim@mipassoc.org
References: <9e7d6a29-cbef-e032-4af9-eb5395071b4d@tana.it> <alpine.OSX.2.21.1802080808160.51311@ary.qy> <CAL0qLwYZPRdrg-J5KMreS==SUcnAU1pZXwgFURs5T3=XaX4HOg@mail.gmail.com> <20180208161754.25028.qmail@f3-external.bushwire.net> <alpine.OSX.2.21.1802081148580.52386@ary.qy>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.OSX.2.21.1802081148580.52386@ary.qy>
Subject: Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.16
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/options/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim/>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: ietf-dkim-bounces@mipassoc.org
Sender: ietf-dkim <ietf-dkim-bounces@mipassoc.org>

On 08Feb18, John R. Levine allegedly wrote:
> On Thu, 8 Feb 2018, Mark Delany wrote:
> > Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - apart
> > from exposing brittle parsers which mistakenly expect it to show up as the first
> > tag.
> 
> I had a draft that invented v=2, for headers with a tag syntax that is not 
> quite backward compatible with the current spec.  I realize that we could 
> change the header to DKIM-Improved-Signature but the change was small and 
> it smelled to me like the same header.

Yes, one can certainly contrive a situation in which they prefer a v=2 solution,
but as you say, the requirement can be just as easily satisfied in a number of
other ways too.

A new header is one as is the presence of a new tag and v= is a third. There are
other ways as well.

Given we're talking about standards, it's de rigueur that we end up with at
least three competing ways of achieving the same outcome without any guidance
whatsoever as to which mechanism to choose when and why.

Underlying all this of course is the assumption that programmers intuit the
possibility of change inherent in these non-essential mechanisms and code and
test accordingly. Now that's a goodun.


Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html