On Feb 5, 2009, at 8:08 AM, Jon Callas 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.
Forgive me for this short rant and applying a riding crop to this
horse, but when you say:
"Statements that imply the i= value is always OPAQUE prevents..."
You are correct.
However, the fact that you do not wish it to be opaque does not make
it transparent. It is opaque. It is not in "... conflict with the
defined use..." because it *IS* the defined use. It is not your
*desired* use, but it is the defined use.
Disagree.
Per RFC 4871:
.---
i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty Local-part followed by an "@" followed
by the domain from the "d=" tag). The syntax is a standard email
address where the Local-part MAY be omitted. The domain part of the
address MUST be the same as or a subdomain of the value of the "d=" tag.
'---
When an i= value does not match with any identity within the message,
only then should the i= value be considered opaque.
However, when the i= and the d= values _exactly_ match against an
email-address within a _signed_ header, there is _no_ basis to assume
a signing domain uses two separate and colliding namespaces within
their messages. Where is this occurring? If it is, there should be a
warning against such ill considered use of colliding namespace. Why
add extra knobs where none are reasonably required?
Why is it so hard for you to just write a followon RFC to DKIM that
has an Identity Accessor or whatever you want, that you stick in
some header and sign *that*, rather than continuing to insist that
i= is what it is not?
Why would such an effort be required? RFC 4871 has already made
provisions for this use. This Errata draft is not really an errata
since it dramatically changes RFC 4871 definitions that appear correct
as written.
It is not clear what problem is addressed by the assertions that there
might be two separate and colliding namespaces used by a signing domain.
In addition, since the goal of the DKIM was to establish the domain,
why describe the domain within the d= value as being opaque???
When a message is purportedly from an address within "example.com",
why would it be reasonable to assume a signature added to this message
where "example.com" provided public keys verifying the message is
somehow to be viewed as opaque. These definitions require an
exception. When it is not possible to associate domains, especially
the _same_ domain within their signed message, the value of DKIM will
have been seriously undermined. When is it reasonable to assume there
are separate and colliding domain namespaces?
For all the effort we keep spending declaring that the sky is green,
we can just go get some nice tinted lenses.
What problem do you see this over-extended opaque assertion solving,
especially when it creates a problem where none had existed.
I *support* creating a header that is what you want, but really,
that's not what is in DKIM-base. Just write up an I-D defining the
header you want!
On the other hand, by not changing these RFC 4871 definitions, there
would not be a need to add new headers or additional signature tags.
Don't change these RFC 4871 definitions.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html