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
