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
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html