On 4/30/2014 11:54 AM, Pete Resnick wrote:
If there are others who have a handle on what I'm thinking about and
want to work on this, I'm happy to spin up a WG to work this out.
There's no way I'm going to be able to hold the pen on this, but I
think I hear sufficient motivation to get this done.
If you are talking about a resigner kludge that could bypass policy,
then I am against that. Any solution must be permission based. I
believe that may have been your first design assumption.
I suggest spinning up a DKIM POLICY working group to begin updating:
RFC5016 Requirements for a DKIM Signing Practices Protocol
http://tools.ietf.org/html/rfc5016
We need to revisit and reconfirm what are the possible policies.
What predictably started this mess was the last minute inclusion of
section 5.3, item 10:
5.3. Practice and Expectation Requirements
10. SSP MUST NOT provide a mechanism that impugns the existence of
non-first party signatures in a message. A corollary of this
requirement is that the protocol MUST NOT link practices of first
party signers with the practices of third party signers.
INFORMATIVE NOTE: the main thrust of this requirement is that
practices should only be published for that which the publisher
has control, and should not meddle in what is ultimately the
local policy of the receiver.
Refs: Deployment Consideration, Section 4.3.
That can not be anymore. Policy must be honored if this is to work,
but the current 'method' of choice (DMARC) needs to be fixed. If
DMARC is going to be selected as a DKIM policy protocol, then to help
accelerate and lower the barrier to wide adoption, then it should
split into two:
DMARC-REPORTING
DMARC-POLICY
As as right now, correct me if I am wrong, I don't think reporting is
even an option.
Thanks
--
HLS
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822