[ietf-dkim] #1398

[Hallam-Baker, Phillip]

Are you proposing to put this list in the policy record or the key record?

I am prepared to think about whether it is necessary in the key record or not. It does not in my view belong in the policy record.

The way to express any policy more complex than 'I always sign' is to put all the complexity into the key record and to provide a means of specifying a restriction set on the key records as in the proposed 1368 mechanism.

Otherwise you would end up with complexity in both the key record and the policy record. You have to have the information in the key record as well because a key record is implicitly a statement 'this is one way in which I might sign'. 

> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org 
> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Michael Thomas
> Sent: Thursday, March 01, 2007 4:56 PM
> To: Frank Ellermann
> Cc: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] #1398
> 
> Frank Ellermann wrote:
> >
> >> nothing prevents you from doing an SSP lookup on any address or 
> >> domain that you desire, so at some level you are accommodated.
> >>     
> >
> > No, it's not obvious what it means if the 2822-From domain 
> claims to 
> > sign all mails, and the Resent-From domain makes no statement.
> >   
> 
> In my implementation I can (and do) sign for a configurable 
> set of addresses including From, Sender, Listid, etc. SSP has 
> the concept of "I sign everything" which right now is 
> implicitly the From address.
> What I'm wondering is whether we should make that binding 
> more explicit even if we ultimately only choose From, and 
> make it an extensible list sort of like:
> 
> p=sign-complete:From;
> 
> Perhaps now, perhaps in the future we could extent that to be 
> something like:
> 
> p=sign-complete:From:Sender:Listid;
> 
> Which I'm pretty sure addresses your issue directly.
> 
> 
>        Mike
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>