Barry Leiba wrote:
Dave Crocker writes to MH Hammer:
With respect, I believe you do /not/ understand the architectural
point at issue here.
The confusion that you are experiencing is between the component of
the system that validates and reports signatures, versus other
components that evaluate additional aspects of signatures, such
as the correlation of the SDID with other identifiers in the message..
Indeed, and we've been back over this many times throughout
discussions, in the last five years. I sometimes think we should have
started with an architecture document.
Not officially, but I believe we did, abeit two competing ones. More
below.
On the other hand, maybe we can make all that clearer in a revision of
the Overview doc... start that document with a section about
architecture. I haven't read it in a while: perhaps it already has
this issue laid out clearly.
As an long time engineer, WG outsider, participant, DKIM Implementor
looking in, the problem has been the inconsistencies. Let me try to
summarize.
These are not exclusively the top three issues of conflict.
- Mixing of Protocol vs Product Designs
- Mixing of exclusion vs inclusion of semantics
- Mixing of Security vs Usefulness
Overall, the two completing architectures is based on long time modeling:
A1) 3rd party signers honoring security controls based on
WG consensus built RFC4686, RFC5016, RFC5617
A2) Unrestricted 3rd party signers with no technical requirement
nor responsibility to honor security controls, even if they
are optional.
And if we can even removed A1 from the picture, the A2 leading WG key
cogs required an out of scope reputation model to resolve the security
concerns continue to perform in ways where the issues of conflict emerges.
In other words, the issues still crop up. Take for example, Dave's
overview document, in Figure 1 DKIM Service Architecture:
http://dkim.org/specs/rfc5585.html#rfc.section.5
There is nothing wrong with that, except for two things:
- Checking Signing Practices is a major component of
the architecture and there is no references to this
in RFC4871bis
- An Optimization consideration (above Verify Signature)
is missing. This was defined in RFC5016.
No fresh eyes reading RFC4871bis would be able to put together the
Figure 1 architectural design. He will design code that that is not
ready for whats described in RFC5585.
So RFC5585 is required and when those same eyes see this software
engineering flow and module about Checking Signing Practices, the more
insightful engineer will see that its in the wrong place - for
optimization reasons.
Yes, its understand that these are all recommendations and
implementors do not need to add optimization. But we continue to
discuss RFC4871bis as if RFC5585 never existed, nor RFC4686, RFC5016,
RFC5617.
Yes, the RFC5585 architectural design exist, and also the RFC5863
deployment guide has an entire section devoted to ADSP, yet we refuse
to say anything regarding an "Checking Signing Practices" Identity
Assessor module or anyt closely resembling a "authorized signer"
concept in general.
Finally, the argument for exclude Signing practices is because it
makes MLM useful is kinda weak because it is still useful if a MLM
supported the architectural. Right now the argument is that it SHOULD
NOT follow the RFC5585 architectural.
Overall, the non-policy advocates makes it too easy for continue
debates because you can't bury a live and highly desirable original
DKIM concept.
--
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