Subject: RE: [ietf-dkim] Re: Additional per user policy requirments

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 6 Sep 2006 08:46:37 -0700

> Only because people insist that it *must* work in every 
> scheme they can make up.
> I believe that we could implement what we have discussed and 
> the fact that it won't work for everybody should be an 
> asterisk. It will work for most systems and I am comfortable 
> with that. Implementation is not a requirement.

I think that we can reduce the complexity of the policy language by 50% and increase the power of the policy statements in the process.

It appears to me that we have to change SSP because the punctuation mark policy descriptions are not sustainable.

Thus far I am not convinced that we need to have per user policy at all. The ability to add per user signatures does not imply the need for per user policy. In fact the only place where I can see a real advantage is the case where there are exceptions to the 'I always sign' scheme.

If we do have per user policy I think that it needs to be defined in such a way that it is clear that it is an extension. So for example if DKIM is the tag describing the domain based DKIM and USER is the per user version of the policy language we would in my scheme have a master policy record of the form:

_policy._SMTP_OUT.example.com          TXT "policy.smtp_out USER"
alice._policy._SMTP_OUT.example.com    TXT "policy.smtp_out DKIM"
keith._policy._SMTP_OUT.example.com    TXT "policy.smtp_out"

These records state that email from [email-masked] always has a DKIM header and that there is no per-user policy for mail from [email-masked].

OK so now that I have demonstrated that we can introduce per-user policy as a DKIM extension we can decide to punt on it if we choose. We can get the domain level policy right first knowing that we can address the second level option later

Furthermore in this scheme it is obvious how the master record would encode for SMIME or PGP

If we are dealling with cases where subdomains exchange mail it is convenient to allow the DKIM-USER tag to take a DNS node specifying the root of the policy distribution as a parameter so that [email-masked] can be wildcarded:

*.example.com                          PTR example.com
_policy._SMTP_OUT.example.com          TXT "policy.smtp_out DKIM-USER=_policy._SMTP_OUT.example.out"

We can even use this scheme to specify policies at the domain level AND the per user level:

AND conjunction:

_policy._SMTP_OUT.example.com          TXT "policy.smtp_out DKIM & USER"
alice._policy._SMTP_OUT.example.com    TXT "policy.smtp_out DKIM=alice._domain.example.com"
bob._policy._SMTP_OUT.example.com      TXT "policy.smtp_out PGP"
carol._policy._SMTP_OUT.example.com    TXT "policy.smtp_out SMIME"

There is always a DKIM signature AND a per user policy MAY be specified. In this case we use the per user policy to specify that email signed by Alice has an additional selector restriction, Bob always uses PGP in addition to the DKIM record and Caro; always uses SMIME in addition.

Alternatively we can have an OR conjunction:

_policy._SMTP_OUT.example.com          TXT "policy.smtp_out DKIM | USER"

With this infrastructure we can solve every one of the use cases I have seen to date. 

I don't see why any authentication policy would require more than four terms, six at the absolute maxiumum. It is not necessary to implement braces, merely specify whether AND or OR has higher precedence.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 6 Sep 2006 09:09:02 -0700 (PDT)

On Wed, 6 Sep 2006, Hallam-Baker, Phillip wrote:

> If we do have per user policy I think that it needs to be defined in 
> such a way that it is clear that it is an extension. So for example if 
> DKIM is the tag describing the domain based DKIM and USER is the per 
> user version of the policy language we would in my scheme have a master 
> policy record of the form:
>

It is not SMTP_OUT policy as the signature is for DATA part and
SMTP implies envelope-level identity. However I'm for having
identity as part of policy dns record locator syntax, something like:

  alice._from._email_policy.example.com

Above though is minor tweak. One thing I do want to point out is
that in case user email address ([email-masked]) is present in the 
signature, dns request can immediately be made to:
  alice._from._email_policy.example.com

If dns provider is smart, they'd have general record:
  *._from._email_policy.example.com IN TXT ...
and if alice had specific record then
  alice._from._email_policy.example.com IN TXT ...

This does remind me of an idea I mentioned long ago (ASRG or MARID?) - 
basicly require domain-wide non-user record to be in
   *._from._email_policy
rather then just
    _from._email_policy

This means everyone has to kind-of use wildcards (kind-of because if
user address is not mentioned in signature then DNS lookup will be
done directly to "*"), but it avoids extra DNS record for wildcard
and non-wildcard entry and avoids extra user DNS lookups since all 
user-level lookups would then succeed.

---
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 06 Sep 2006 09:09:13 -0700

On Wed, 2006-09-06 at 08:46 -0700, Hallam-Baker, Phillip wrote:
> 
> I don't see why any authentication policy would require more than four
> terms, six at the absolute maximum. It is not necessary to implement
> braces, merely specify whether AND or OR has higher precedence.

While I agree that this is solvable using rather simple syntax, it is
yet to be determined whether even determining precedence is needed.
This might be accomplished by their listed order.

-Doug