Subject: [ietf-dkim] what I said about i= at the DKIM meeting

From: Tony Hansen <[email-masked]>
Date: Fri, 27 Mar 2009 13:26:05 -0400

I was asked to post what I said at the DKIM meeting about opacity and
the AUID (i=) value. Take it as input into your thought processes as you
consider the issues around the Errata. The following is only slightly
expanded over what I said on Tuesday.

======
Part 1

The definition of i= contains several parts to it. The semantic
description is

	Identity of the user or agent (e.g., a mailing list manager) on
	behalf of which this message is signed

The syntax description is

	(dkim-quoted-printable; ...) The syntax is a standard email
	address where the Local-part MAY be omitted.

The constraints are:
	(OPTIONAL, default is an empty Local-part followed by an "@"
	followed by the domain from the "d=" tag).
	The domain part of the address MUST be the same as or a
	subdomain of the value of the "d=" tag.

The semantics constrain the AUID to be an identifier for the agent/user.
This MAY be the email address of the agent/user of the message, or it
may be some other value that also represents the identity of the
agent/user but is not an email address of the agent/user. If it is the
latter, it is still required by the semantics to be an identity for the
user and must LOOK like an email address. But otherwise the localpart
and subdomain portion of the value are totally opaque in sense to DKIM
or users of DKIM. There is nothing else that tells us how we can look
into it and figure out what pieces of it means.

I also noted that some vendors that are signing messages today ARE using
i= values with the actual email address of the authenticated user (if
available), some are putting different values into i=, and others are
not using i= at all.

Which one is most useful is subject to debate. (For the record, I prefer
using the actual email address of the authenticated user if it's available.)

======
Part 2

I also made comments about the different fields found in the DKIM
signature. This was a reminder to folks about various aspects of those
fields.

Some of the fields in the DKIM signature (v=, t=, x=, z=) are
supportive, ancillary information for the signature.

Some of the fields (bh=, c=, h=, l=) provide information on calculating
the hash to be compared with b=.

Some of the fields (a=, q=) provide information on how to access the
public key.

The actual authentication that occurs is performed using three fields:
the value of the hash (b=) is verified using the public key found using
the selector and domain (s=, d=) and the hash calculated on the message.
When this authentication is finished, you've verified that the d= domain
signed the message.

And then there's i=, the AUID.

The value of i= is an assertion by the signing domain as to an identity
of the agent/user. There is nothing that can be tested to
cryptographically verify it. It's a simple claim; it's by definition the
identity that's been purported and alleged by the signing domain.

How much you believe that i= value will necessarily be related to how
much you trust the verified d= value.

As Doug Otis noted, if you find that identity in the From: header or
Sender: header, you have a high certainty that the i= value is the email
address of the agent/user instead of some other representation of the
identity of the agent/user. This is a positive confirmation test that an
implementation may choose to do. But all you've shown is that they are
the same; how much you trust the From: value is also necessarily related
to how much you trust the verified d= value.

But that's the only thing you really get to say from comparing the From:
value with the i= value. You cannot make the obverse statement that the
From: address is necessarily representing the same user as the
agent/user identified by the i= value -- the sending domain isn't
required to ensure that the From: value matches the i= value and nothing
we say can force it to do so.

	Tony Hansen
	[email-masked]
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 27 Mar 2009 16:28:16 -0600

> into it and figure out what pieces of it means.
  [ . . . ]
 > much you trust the verified d= value.

To put it another way:

'...DKIM itself includes an additional identifier, the "i=" value, which 
looks like (but isn't) an email address. The signer can set i= to whatever 
they want, as long as the part after the @ is the same as the d= domain. 
Cisco uses this to identify individual users: i=[email-masked]. More 
common, I'd expect, will be use of i= to denote distinct mailstreams or 
internal divisions: i=[email-masked], i=[email-masked], 
i=[email-masked].

Thing is, i= is an opaque identifier. There's simply no way for anyone 
outside of the signing domain to know whether [email-masked] is a 
mailstream, a department, a individual email address, or simply a string of 
randomly generated characters. DKIM does not tell you what it means, or if 
it'll mean the same thing in the signature of another message. DKIM does not 
tell you if i= is truth....'

http://www.returnpath.net/blog/2009/03/searching-for-truth-in-dkim-pa-3.php
(which is actually part 4.)

Is anyone actually disagreeing with this?  If not, what are we arguing about?

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html