G'day.
Looking for a community determination, here: The DKIM spec's examples
in A.2 and A.3 do not explicitly claim to be related to each other.
However they do contain the same message, so that assuming a
relationship seems pretty reasonable.
As such, calling the point raised in this Errata report an actual error
is certainly not silly. But I'm not sure it's correct, either.
Thoughts?
d/
-------- Forwarded Message --------
Subject: [Technical Errata Reported] RFC6376 (4926)
Date: Tue, 7 Feb 2017 07:17:12 -0800 (PST)
From: RFC Errata System <rfc-edi...@rfc-editor.org>
To: dcroc...@bbiw.net, tony+dki...@maillennium.att.com,
m...@cloudmark.com, stephen.farr...@cs.tcd.ie,
kathleen.moriarty.i...@gmail.com, barryle...@computer.org
CC: simon....@emersion.fr, ietf-dkim@mipassoc.org,
text/pl...@rfc-editor.org, charset=ut...@rfc-editor.org
The following errata report has been submitted for RFC6376,
"DomainKeys Identified Mail (DKIM) Signatures".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6376&eid=4926
--------------------------------------
Type: Technical
Reported by: Simon Ser <simon....@emersion.fr>
Section: A.2, A.3
Original Text
-------------
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
c=simple/simple; q=dns/txt; i=j...@football.example.com;
h=Received : From : To : Subject : Date : Message-ID;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=;
Received: from client1.football.example.com [192.0.2.1]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <j...@football.example.com>
To: Suzie Q <su...@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5...@football.example.com>
Corrected Text
--------------
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
c=simple/simple; q=dns/txt; i=j...@football.example.com;
h=Received : From : To : Subject : Date : Message-ID;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=;
Received: from client1.football.example.com [192.0.2.1]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <j...@football.example.com>
To: Suzie Q <su...@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5...@football.example.com>
Notes
-----
The "simple" header canonicalization doesn't change the header fields in
any way.
Folded header fields are missing one space of indentation (they have 5
spaces instead of 6), which makes the verification fail. Note that the
plain text version of the RFC adds a prefix of three spaces before each
line of text, which must be ignored.
In section A.3, the indentation is changed again (5 spaces instead of 6
+ the "b=" tag has 2 additional spaces of indentation).
Test cases:
- opendkim:
https://github.com/cyrusimap/opendkim/blob/ab2934e131cbe670b49f11db9daf8cd1223e3839/libopendkim/tests/t-testdata.h#L74
- go-dkim: https://github.com/emersion/go-dkim/blob/master/verify_test.go#L9
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party can log in to
change the status and edit the report, if necessary.
--------------------------------------
RFC6376 (draft-ietf-dkim-rfc4871bis-15)
--------------------------------------
Title : DomainKeys Identified Mail (DKIM) Signatures
Publication Date : September 2011
Author(s) : D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed.
Category : DRAFT STANDARD
Source : Domain Keys Identified Mail
Area : Security
Stream : IETF
Verifying Party : IESG
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
