Murray S. Kucherawy wrote:
With that in mind, I propose this as a new Section 4.9, moving
the others down:
4.9. Output Requirements
The output of the verifier MUST embody:
- A result code that indicates whether or not the signature was
validated (PERMFAIL or TEMPFAIL as described in Section 7.1, or a success
result code)
- If the signature did validate, the value of the "d=" tag, i.e.,
the signing domain
The verifier MAY include other outputs, but this is implementation-dependent
and not mandatory. The verifier MAY also include as secondary data some
information indicating the specific cause of a failure.
Comments?
Once again we are limiting DKIM Mail Integration designs. This is
more than minor. Its keeps with the presumption Failure Detection is
not going to be considered regardless of what the DKIM-BASE documents
continues to try to mandate or hide. If people don't believe in it, it
won't be followed. If they find it lacking, they will compensate.
Just consider the two items in your proposed 4.9 are in conflict; the
1st item considers failure, the 2nd item says don't consider failure.
The 2nd item is not going to hold across the board with verifiers;
SDID can be returned. Its not like SDID will be returned as a NULL or
blank string for failed signatures.
IMO, to be completely DKIM Mail Integration ready, this new proposed
section SHOULD also include policy-related or AUID output semantics as
well, but since thats a hot iron, so.......
I think the Identity Assessor section is sufficient.
If you are in the mood to add such a section, I propose to cover the
I/O and called it:
4.9 DKIM Mail Integration I/O
(summary itemization)
Minimum INPUT for Signing
- RFC5322 compliant message
- SDID signer domain for d=
- SELECTOR s=
- PVTKEY (Private Key)
Process model
RFC4871 DKIMSIGNER(RFC5322,SDID,SELECTOR, PVTKEY)
Minimum INPUT for Verification
- RFC4871 DKIM Signed compliant message
? PUBKEY (Public Key)
Process model
RESULT DKIMVERIFY(RFC4871 [, PUBKEY?])
? = the function has all the info from RFC4871 namespace
to obtain public key.
Where RESULT is the minimum output namespace:
- RCODE (Verification Result Code)
- AUID
- SDID
Assessment Modules
TRUST DKIMTRUST(RCODE, SDID)
POLICY DKIMADSP(RCODE, AUID, SDID)
Where TRUST is the output from Trust Assessment
POLICY is the output from Policy Assessment
Its a little closer to what we have now implementations and where
things are headed. But if you want to take out the POLICY semantics,
well, I can understand.
--
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