[ietf-dkim] Delegation semantics

[Hector Santos]

Philip,

Off the top of my head, this looks like it will work.  This will provide
also for an optimal single lookup for the low to mid tier market where 1st
party delegation is all that is required.

However, the question remains if what is the policy _association_ with the
legacy x822 headers, in particular when and where there is no signature?

If the verifiers sees just this:

    From: alice at example.com
    To:  someuser at sometarget.com
    Date: ....
    Subject: .....

or even include the sender:

    Sender: MailRoom at remailer.com
    From: alice at example.com
    To:  someuser at sometarget.com
    Date: ....
    Subject: .....

Are we going to ignore addressing the highly detectable and thus highly
possible protection in legacy facsimiles of the unsigned message?

Remember, if this remains to be an ignored condition, then bad actors simply
will just avoid mail with signatures good or bad, 1st or 3rd party, what
have you.  All they need to do is simply just broadcast old standard
unsigned mail as they do now.   In this case, we lost a major opportunity to
protect the 1st party domain, the abuse on the receiver system, and also
lost the opportunity to force bad actors to adapt in our direction.

If we conclude there is a value here to extract policy from default legacy
headers, I believe we are in the right direction with your proposal.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com







----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker at verisign.com>
To: <ietf-dkim at mipassoc.org>

> Lets have some parties:
>
> Party claiming responsibility for content:   alice at example.com
> Party that has the signature key:            remailer.com
>
> ...
>
> remailerkey._domainkey.example.com  TXT
>    "sender=alice at example.com"
>    "delegate=**.remailer.com"
>
> examplecomkey._domainkey.remailer.com TXT
>    "authority=remailerkey._domainkey.example.com"
>    "key=423249671234986u3hf89713ty49y=="
>
> ...
>
> We have successfully achieved both types of delegation
> semantics without recourse to any additional DNS feature and
> without doing damage to the DNS semantics. We are much less
> likely to face unexpected interactions.