ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

2011-04-06 14:06:26


----- Original Message -----
From: "Steve Atkins" <steve(_at_)wordtothewise(_dot_)com>
To: "DKIM WG" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Thursday, 7 April, 2011 4:29:49 AM
Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
On Apr 6, 2011, at 9:07 AM, Michael Thomas wrote:

On 04/06/2011 08:48 AM, Steve Atkins wrote:
That sounds like a fragile way to extend things - leave a little
used feature
around and hope someone who wants something new hijacks that
field in a non-conflicting way instead. (Which may not be what
you're
suggesting, but it's an implication I've seen in some comments
about i=).

Outside of the information that is needed to validate the DKIM
signature
(v, a, b, bh, c, d, h, l, q, s, t, x) there doesn't seem to be any
real need for
information to be recorded in the DKIM-Signature field at all.
Rather, it can
use the 5322 extensibility to add a header containing the
information
that needs to be included (with an understanding that the receiver
should
require that header be covered by the DKIM signature).


There is something to be said about using tags in the signature
rather than signed headers. Signers don't have to have any
reason -- and none should be inferred -- for signing any given
header. There are no semantics associated with that. Putting
something in the signature on the other hand carries
the exact semantics of what the value means _in the context of
the DKIM signature_.

So unless we want to start making new headers have a presence
of a DKIM semantics requirement -- which would probably be
hopeless -- it's probably better to keep extensibility within
the narrow confines of the DKIM header itself.

Not all new headers. (And the DKIM header doesn't really have
any proper extensibility, and the use of single or two letter names
for fields makes ad-hoc addition of new fields to that header -
without
a registry or version bump - quite a bit riskier than the
"Full-English-Word:"
approach 5322 headers use.)

Rather, if anyone wants to release a specification that "requires"
some sort of data be associated with a dkim signature then they
can equally well release a spec that defines a new 5322 header
that holds the same data.

As a concrete example, if I wanted to include the authenticated
age of each email sender (something the gambling industry might
be interested in) then I can do that within the DKIM signature:

DKIM-Signature: v=1; d=corp.example.com; <blah>; db=19700224

Or I can specify that that should be done with a dedicated 5322
header that both references and is signed by a DKIM signature.

DKIM-Signature: v=1; d=corp.example.com; <blah>;
h=To:Authenticated-Birthdate:<blah>
Authenticated-Birthdate: version=0.1; dkim=corp.example.com;
birthdate=1970-02-24

As long as the Authenticated-Birthdate header is included in the
DKIM signature it references, that's pretty much equivalent as
far as senders and receivers who are both using the same
authenticated birthdate spec are concerned, just more flexible
and less likely to clash with or break other DKIM usage.

Cheers,
Steve


Yes, so far I have been trying to assert:

1) How hard is it to add a new dkim header like st= considering the current 
software implementation of DKIM
2) Can we use i= for a purpose of reputation as a) it's meaning is loosely 
defined, b) it is there already (cf (1) ) c) it has been used by some to 
differentiate different emails in the same domain.
3) Should we better get DKIM to sign a 5322 header because a) any DKIM 
implementation can do it b) for senders it is easy to add a header when the 
email is created and then sign it on the way out, than to figure what type of 
email it is on the way out during signing. c) for receivers a signed header is 
easy to process likewise.
4) Would senders and more important receivers likely to adopt such mechanism to 
mimic IP reputation with dkim, rather than using subdomains.


All of that is not related to the DKIM spec moving a step higher in the IETF 
unless if i= is dropped or not, but it is good to think potential 
implementations now, I think. 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>