Murray S. Kucherawy wrote:
-----Original Message-----
Why isn't an authorized signer an identity example?
It is. The question is: Is it harmful not to list it explicitly?
There doesn't seem to be support for that idea so far.
Which makes very strange.
If you think it is, and had proposed it as I think you might have
being a "putting it all together" software engineer, we would get
traction. The question then might be: what is the harm by adding this
natural DKIM identity?
Anyway, overall, it is about continuing and promoting positive
development for Policy and related extensions which is almost
certainly the most active work beyond DKIM-BASE completion. The DKIM
trust model does not deal with the DKIM faults and has yet to prove
itself. It requires the model the SSL Intermediate CA market enjoys
with all industry browsers (our DKIM verifiers) all supporting a
common database. It may even need something like the OCSP (Online
Certificate Status Protocol) used by the Browsers for SSL. This is
going to be very long term.
Finally, I believe having the identity will reduce the need to revisit
the spec when policy becomes more popular. If by chance a IETF policy
standard emerges, unrestricted 3rd party signers will be in violation
of an IETF standard. If the change it becomes a BCP, they will be now
in conflict. At the very least, it helps provide insight to active
and future implementators that 3rd party signers are not entirely
unrestricted. It will give software developers something to think
about. It will give current and future packages the vision to turn on
the ADSP Checking Option which is already most likely supported in
their software.
One last point, section 2.7 Identity Assessor should be the place
where the "independent trust assessment server (module)" idea should
be aptly moved to and in the same manner, adding "Policy Assessor
Module" would be incredible insightful. It leads the way to the next
phase. I don't see any harm in that, only good can come from this.
Thanks
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html