On Feb 10, 2009, at 3:20 AM, <[email protected]> <[email protected] > 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
