On Feb 10, 2009, at 3:20 AM, <Pasi(_dot_)Eronen(_at_)nokia(_dot_)com>
<Pasi(_dot_)Eronen(_at_)nokia(_dot_)com
wrote:
Douglas Otis wrote:
Statements that imply the i= value is always OPAQUE prevents its
utilization for highlighting purposes with respect to identity
assurances, even when there is an exact match and this value could
be said to not be opaque. This also seems to conflict with the
defined use of the i= value as representing on whose behalf the
signature was added. There should be an exception spelled out for
exact matches.
Such as:
Hence, DKIM delivers to receive-side Identity Assessors responsible
Identifiers that are individual, where unless the AUID exactly
matches a signed header's email-address, is to be considered an
opaque value. Being opaque means the AUID sub-structures, and
particular semantics, are not publicly defined and, therefore,
cannot be assumed by an Identity Assessor.
Note that the text in rfc4871-errata currently says that the local-
part of UAID may or may not be in the same namespace as email
address local-parts.
You seem to assume that they're in the same namespace -- because if
they're not, comparing them does not make sense (exact match or
anything else).
The i= value is intended to convey the identity on whose behalf the
signature was applied as indicated in RFC 4871. When this identity
exactly matches an email-address found in a signed header field, where
this email-address IS within a valid email-address namespace, it is
NOT reasonable to assume the i= value represents a separate namespace
that collides with the domain's valid email-address namespace! Only
when the i= value does NOT match with any signed header field, could
it be reasonable to consider that the i= value might represent a token
for on whose behalf the signature had been applied.
(US passport numbers are 9 digits. US Social Security Numbers are
also 9 digits. But since they're not in the same namespace, an exact
match between passport 123456789 and SSN 123456789 does not provide
useful information -- the numbers could refer to the same person (in
theory, although unlikely) or to different persons.)
So, even exact match with some email header is useless to the
recipient (unless it somehow knows that the Signer is using same
namespaces for these two fields).
Why require an additional semaphore before a recipient can trust that
the i= namespace will not collide with the domain's valid email-
addresses as conveyed within the same message? DKIM makes it easy for
collisions to be avoided. Otherwise, one must assume the i= value
misrepresents on whose behalf the signature was applied. The
misrepresentation issue will have been _created_ by an errata that
explicitly allows i= values to represent a namespace that collides
with valid email-addresses! It should not.
Allowing the i= value namespace to collide with valid email-addresses
within the domain gives those implementing DKIM a license to be
deceptive. This license to lie undermines DKIM's value and imposes an
unnecessary change to the protocol that will then require a new
semaphore to indicate the use of non-colliding i= namespace. :^(
Rather than offering permission to be deceptive, it would be much more
forthright and reasonable to add a strong admonishment regarding any
extremely ill considered practice where i= values collide with the
domain's own valid email namespace!
Is there any domain currently issuing i= values that collide with
valid email-addresses within the same message? If so, it seems one
would be well advised not to trust their DKIM signatures, since not
being deceptive should not require explicit instruction.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html