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