On 5/5/11 9:40 PM, Hector Santos wrote:
Dave CROCKER wrote:
I don't think this is correct. The signer creates and signs the i= value,
so it's not "garbage",
....
By "garbage", I mean "not guaranteed to have any useful meaning".
....
So, I believe, it's essentially meaningless as far as the protocol can
stipulate. Assertions of its semantics thus fall outside of the base DKIM
spec.
It's worth noting that Murray said 'could be'.
But Murray's final paragraph has the essential points: within the scope of
the
DKIM Signing specification, the receive-side has no way to determine what the
semantics of i= are, as we discussed at great length when formulating the
Update
RFC.
But, then, folks on the list already know that.
"We have here is a failure to communicate." - Cool Hand Luke
Dave,
This approach you have is an implementation conclusion. It is not
part of the protocol. The protocol clearly says in 3.11:
Upon successfully verifying the signature, a receive-side DKIM
verifier MUST communicate the Signing Domain Identifier (d=) to a
consuming Identity Assessor module and MAY communicate the Agent or
User Identifier (i=) if present.
Therefore with no subjective consideration, no assertions, no
philosophies, the protocol defines a process model of:
trust = TrustIdentityAssessor(SDID [,AUID])
There is NO opinion about this! That is your DKIM Trust Protocol Model
with a Mandatory SDID input and an optional AUID input.
In order for this to work, your 3.9 Output Requirement MUST expose
those two parameters at the very least. There is no assertions or
opinions - thats the protocol you defined.
Now, when you begin to exclude it, then you mixing up implementation
desires with subjective conclusion that really is not part of the
protocol defined. There is some subjective information notes about
the value, but that has nothing to do with the protocol you defined.
To be consistent you have three protocol design tech writing choices:
1) Remove the second clause in that 3.11 3rd paragraph - problem fixed.
2) Add AUID to 3.9 as an optional output
3) Remove section 3.9
This is what happens when you add something in the last minute without
any consensus. It was just added - no consensus.
I must agree with Hector on this point. It seems the motivation to
"simplify" DKIM has wrongly included removal of output information
intended to be bound with the signature. It would be like SMTP later
deciding not to include trace information intended to be bound with the
message.
While the "i=" may contain the email address of the author or the
postmaster of the domain or simply an opaque tag, the meaning is NOT
undefined. Its meaning IS defined by the signing domain. The whole
point of DKIM was to establish a context for such information,
especially information intended to be closely bound with the signature.
Deprecating that aspect of DKIM overlooks many security aspects, and the
valid and intended use of this information. What this parameter had
been defined should ensure against any interoperability issues, but
perhaps deserves a warning that it NOT be used by third parties who are
unaware of the signing domains definition of this field. It would still
be extremely useful within enterprise applications, for example.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html