Murray S. Kucherawy wrote:
The only utility in revealing failed signature information is forensics.
That sort of debugging function doesn't need to go in a protocol
specification.
-1. It is not a debugging function.
It is about security (RFC4686) and deployments considerations
(RFC5863, see Section 7.3).
Neither of those citations give any value to a failed signature.
Sure it does. DKIM explicits states that a failed signature is too be
promoted (or demoted depending on your perspective) to a unsigned
message. Policy security covers that.
But I also agreed that this becomes a flaw in DKIM as there is
forensic value to failure, especially when there is no policy. The
difference is the strong deterministic nature for the existence of
policy - "I declared it, don't question it." Thats the premise of an
explicitly declared policy.
See RFC5585 Figure 1 DKIM Service Architecture. The AUID is needed for
the major CSP (Checking Signing Practice) black box flow in the DKIM
design.
Since ADSP is predicated on the SDID, the AUID is not useful
here. Moreover, the AUID in a failed signature is not useful as
it could have been modified.
Thats a different issue altogether.
And, once again, DKIM delivers those values but does not use them.
You're talking about making a filtering decision based on them.
Those happen in different layers. It's fine to have other layers
do other amazing things, but we're trying to stay focused on this one.
I am not speaking of filtering and I understand the focus is output
isolated to a limited DKIM strict set.
The question is where that summary section is DKIM correct and/or
sufficient for proper DKIM Mail Integration implementation?
Limited to the two outputs (status and SDID), I believe it is not.
Rolf asked the question I have pointed out many times about the
inconsistence.
So again from a "strict dkim" standpoint, I lean towards AUID being a
mandatory input and output. This is reinforces with the Security,
Overview and Deployment documents.
And optionally from more DKIM mail integration standpoint, if we want
to prepare for A-R, semantics about those "extended" output might be
considered.
I just think that for the sake of completing RFC4871bis, we have too
many WG-man-years of deployment and experience and limited it to a
strict DKIM definition is outdated.
So I suggest to find some WGLC compromise that finishes the job and
still makes RFC4871bis useful for today's DKIM deployment requirements.
Can that be done? I don't know.
--
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