Hector, does your proposal allow for constrained delegation? I think we have a problem if this type of third-party signing allows any account at the list domain to impersonate any account in any participating domain.
DF On Sat, Apr 8, 2023, 2:01 PM Hector Santos <hsantos= 40isdg....@dmarc.ietf.org> wrote: > 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: > > > [image: SSP Overview] > > 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: > > [image: v3_slide0022_image050.gif (392×199)] > > 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, > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
