In my view, DKIM is establishing an "implied" trust relationship between
domains by the very nature of making any attempt to support or adopt the
protocol. It is going to be difficult to keep the concept of "protocol
trust" out of any discussions of SSP.
Hm, interesting approach. The way I look at it, DKIM is providing information
that could be used to define a trust relationship, but is not defining any
trust relationship itself. The recipient decides whether to validate the
signature, and what to do with the results of the validation. I believe this
is true with or without SSP, which is why I don't think that SSP is transferring
responsibility to the recipient: DKIM is giving information, the recipient
domain
is using that information however it chooses, and the DKIM spec does not tell it
what to do with that.
In other words, I don't think I read if 2821 integrated issues is out of
scope or naturally part of the process.
I'd have to say that updating RFC 2821 is out of scope, and anyone who
participated in DRUMS will understand why. We want to finish the DKIM work in
2006, not in 2016.
I'd certainly think it'd be fine to have a non-normative section (or a section
in a non-normative document, such as the overview) that recommends changes to
the existing standards or infrastructure.
I also think it's not necessary to list everything that's not in scope, so I
don't think we need to declare "updating RFC 2821" to be out of scope,
explicitly.
Barry
--
Barry Leiba, Pervasive Computing Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
ietf-dkim mailing list
http://dkim.org