Murray S. Kucherawy wrote:
-----Original Message-----
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.
Actually, using your notation, it's:
trust = TrustIdentityAssessor(SDID[, AUID[, s=[, t=[, l=[, x=[, ...]]]]]])
How far do we really need to go here?
As far are the protocol technical specification says it is. However,
isn't these additional parameters not part of a Trust Assessor
functionality and are part of the validation functionality? In
principle, the RFC4871 process model prototyping using a dyadic FP
(Functional Programming) methodology would be overall:
MAIL.PAYLOAD = MAIL_FEED()
VERIFY.OUTPUT = DKIM_VERIFY(MAIL.PAYLOAD)
ACCESSOR.OUTPUT = DKIM_ACCESSORS(VERIFY.OUTPUT, MAIL.PAYLOAD)
In this summary prototype, MAIL.PAYLOAD provides all the inputs
(RFC5322 message) for both verification and for any inputs required
for any assessors in the process. The only new data would be included
within the VERIFY.OUTPUT and ASSESSOR.OUTPUT namespaces.
With 3.9, VERIFY.OUTPUT is defined to be:
VERIFY.OUTPUT.RESULT
VERIFY.OUTPUT.SDID
Without 3.9, the technical reading extraction would be:
VERIFY.OUTPUT.RESULT
VERIFY.OUTPUT.SDID
VERIFY.OUTPUT.AUID
and IMO, per RFCs 4686, 5016, 5617, 5585, 5863 it would be:
VERIFY.OUTPUT.RESULT
VERIFY.OUTPUT.SDID
VERIFY.OUTPUT.AUID
VERIFY.OUTPUT.ODID
To exclude AUID and/or ODID, it would be a subjective conclusion for a
specific implementation mandate.
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
....or the solution I'm beginning to like:
4) Alter 3.11 to match 3.9.
or take out 3.11 and like it was done for RFC5322.From, you can modify
the two references to the unfortunate technically incorrect sentence
in the abstract and section 1.2:
DKIM separates the question of the identity of the signer of
the message from the purported author of the message.
What "question" are we separating? The association? It would be
technically incorrect given the binding requirement.
In lieu of ADSP, it may be a policy-based association separation but
still an
DKIM-based association of authenticity. As long as "Purported Author"
is a fundamental requirement to be bound to the signature, it will
always be an inherent association between the signer and author that
can not be separated.
Maybe it can be change to a more functionally correct description:
DKIM provides a mechanism which allows for the separation of
the authorized association|relationship of the identity of
the message signer from any other agent or user identity,
including the originating author domain.
Anyway....
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html