[dmarc-ietf] DSAP "DKIM Sender Authorization Protocol" for DMARC

[Hector Santos <[e-mail]>]

Summary:

I would like to reintroduce the DSAP (DKIM Sender Authorization Protocol) as a DMARC extended tag extension -dsap. The original DSAP draft covered nine 1st vs 3rd party signature policies from a verifier viewpoint, which addressed boundary conditions for DKIM signatures. The reintroduction aims to address concerns regarding 3rd party resigners.

Key changes proposed for DMARC integration:

o Introduce -dsap tag for DSAP support, covering a complete range of possible policies.

o Use -asl tag for inline list of authorized signer support.

o Implement -atps tag for ATPS support.

o Formalize the From rewrite logic with a -rewrite tag.

o Introduce -target tag to assist mail forwarders with authorized redirection of exclusive policies.

The proposal seeks to offer better integration with today's wide range of mail applications, building on the existing DMARC protocol and improving 3rd party authorization and reporting.


Background:

In 2006, I submitted an I-D DSAP “DKIM Sender Authorization Protocol” that covers the boundary conditions for 1st vs 3rd party signature expectations.  There are nine 1st vs 3rd party signature policies in DSAP from a verifier viewpoint:

Original 1st Party Signature (OPS)
	Not expected (-)
	Expected (+)
	Optional (~)

Third Party Signature (3PS)
	Not expected (-)
	Expected (+)
	Optional (~)

Using these expectations, DSAP can cover most if not all possible Boundary Conditions for DKIM signatures.

I would like to re-propose DSAP but this time as a DMARC extended tag extension `-dsap` as I believe it can address our concerns regarding 3rd party resigners.

Here is the 2006 DSAP proposal I plan on updating to support DMARC and ATPS:

https://datatracker.ietf.org/doc/html/draft-santos-dkim-dsap-00

History:

The DKIM Policy Model began with SSP “Sender Signature Practices/Policy.” This image illustrates the overall process:




Many today do not realize the original DKIM included Signature Policy protocol called SSP.   It was spit into DKIM-BASE and DKIM-SSP to help speed up the process. DKIM was well defined but SSP was not.  SSP covered various signing scenarios, however, there were 3 policies missing which DSAP covered:



The DMARC protocol offers an exclusive only policy with p=reject|quarantine. This would be a -dsa=OP+,3P- policy With DMARC p=none, no other policy possible in terms of expectation other than an unhandled failed exclusive policy.  So DMARC is very limited making it a very to integrate with today’s wide range of mail applications.

DMARC also introduced two more takes that I would like use replaced with DMARC and ATPS.

For Reporting, DSAP provides tags for failure reports. This is now well-defined with DMARC. [DSAP only considered failure reports].

For 3rd party authorization, DSAP provided the -asl tag. The asl tag was an inline small domain list tag.  But it can also signify a check using ATPS for higher scale applications.  

Everything would be the same with DMARC and DMARCbis.   The change would be:

-dsap tag for DSAP support for the complete range of possible policies.

-asl for inline list of authorize signer support

-atps for ATPS support

I would also like to formalize the From rewrite logic with a tag:

-rewrite 

Which tells a resigner it may rewrite the From under certain conditions.  

-target is a new tag to help mail forwarders.

DMARC has considerations for SPF results with a strong alignment requirement. One scenario where a -dsap=op+,3p- is with SPF hard failure during mail forwarding.   The -target will allow a forwarder to resign as a 3rd party without -asl or -atps requirements. 

—
Hector Santos, CEO/CTO
Santronics Software, Inc,