[ietf-dkim] Charter bashing...

[Stephen Farrell]

Hallam-Baker, Phillip wrote:
>  
> 
>>>    ?? delegation of signing capabilities
>>>
>>>Disagree
>>>
>>>This is actually a show-stopper must have for the ESTG 
>>
>>group. Most of 
>>
>>>the commercial participants in the group use outsourced 
>>
>>email senders 
>>
>>>for at least some marketting campaigns. Third party signature 
>>>capability is actually a differentiator against SPF.
>>
>>Well, in that case I want to see some charter text which 
>>stops us from defining a full-blown authorization 
>>infrastructure. My intent was to stop us from defining such a 
>>protocol to allow one to authorize delegation, but that 
>>verifiers could of course recognize a delegation if they so 
>>choose - its just that the protocol which informs the 
>>verifier about the delegation wouldn't be part of dkim.
> 
> 
> OK this sounds more like saying we are not going to support the
> provisioning protocols for delegation. I agree here.

Good. So we'll rule creation of a new general authorization
infrastructure as out of scope.

> What people do consider necessary is a policy tag on a key record that
> specifies something like 'this key can only sign email from
> marketing at example.com so that the bulk mailer hired to do a promo can't
> then impersonate the CEO.
> 
> More generally I think that instead of enumerating what we won't do we
> should enumerate what we will do explicitly and say we will not do
> anything else.

Its still tricky though since it allows me to make bogus assertions.

However, I do understand the application requirement, but do we have
to meet that via creating key/(dis)allowed-domain bindings in a
dkim protocol? Perhaps we do, but then the threat analysis has to
go into a good bit of detail here since that assertion structure
will be used as the basis of attacks. Or would that be a feature
that'd be ok were it only to be available when some "advanced"
key distribution (e.g. xkms to name your fav:-) is being used?

So for the moment we should not rule supporting that applicaiton
reqiurement as out of scope (does it need specific mention in the
charter as being in-scope? if so, send text) but try to avoid
saying to much otherwise, other than that we're not in the
buisness of developing a generic authorization infrastructure or
something with that capability.

Stephen.