ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] More Comments on draft-ietf-dkim-ssp-requirements-02.txt

2006-10-25 14:10:59
I would like to return to this point since I think that Doug's comments and my 
own can be accomodated through a fairly simple change to the requirements 
language.

The current language is:

The Protocol MUST NOT invent a different means of allowing affiliated parties 
to sign on a domain's behalf. <extended rationale>

This strikes me as being a major overstatement of the consensus on the list 
which was that an additional delegation mechanism is not required. In the 
standards world there is a huge difference between 'not required' and 'MUST 
NOT'. 

Furthermore this is the only point where an extended rationale is presented. I 
would prefer to omit the point entirely. There are many requirements that are 
reasonably met in base that should not be repeated in policy and the 
requirements document should not be required to state each one.

Instead the correct approach would be to have a section on architectural 
requirements that states something like 'The policy mechanism SHOULD NOT 
duplicate in whole or in part any functionality already supported in base.


Although the proposal I have presented does not support policy delegation at 
the current time I don't want to have to spend time trying to work out if there 
is a way that this could be achieved and then introduce artificial constraints 
in order to prohibit this.

Furthermore I don't agree with the premise that key delegation is the same 
thing as policy delegation and that provision of a mechanism for one makes the 
other unnecessary. If I am configuring my mail to go through an ISP mail server 
the semantics I want from the delegation mechanism are 'let the ISP decide 
everything to do with this'. So in that case the delegation would be policy and 
policy alone. 



-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of 
Hallam-Baker, Phillip
Sent: Monday, October 23, 2006 2:17 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: [ietf-dkim] More Comments on 
draft-ietf-dkim-ssp-requirements-02.txt

Section 6.3 req 7

I don't see what this is driving at at all and at most it 
should be a SHOULD.

I don't know if my proposal allows for a new mechanism for 
delegation or not. Making it impossible to use it in this 
fashion strikes me as special pleading for the existing proposal.

In particular I don't see a single positive reason given for 
the requirement. Instead what I see is an argument that 'you 
can do delegation this way'. That may be so but the mechanism 
proposed is not simple.


What I am proposing is that we jettison the existing proposal 
and replace it with a simple unordered sequence of tag value 
pairs, each of which describes a constraint that is met by 
all mail sent.

The tags being:
      NULL
      NOMAIL
      DKIM [=selectorprefix]

The NULL tag is equivalent to an empty list but may help 
readability (this policy intentionally left blank). The 
NOMAIL tag has the obvious meaning. 

If the DKIM tag has no parameter it means 'there is always a 
DKIM record with a selector corresponding to the email address'.

If a parameter is specified then the selector on the 
signature must match the selector. 


I see no reason to artificially constrain the selector, 
writing the constraint rules is itself a difficult issue.

Nor do I see the logic here. If I am delegating my mail 
service to Fred then I want to write a single DNS record that 
says 'Fred is responsible for everything' and have done with 
it for all time. The requirements draft is misworded, if we 
follow that approach we require the party performing the 
delegation to maintain key records.


This is a bogus requirement, it should be eliminated. What it 
seems to be intended to say is not necessary to say. All 
things being equal people will choose the simpler solution.

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



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

<Prev in Thread] Current Thread [Next in Thread>
  • RE: [ietf-dkim] More Comments on draft-ietf-dkim-ssp-requirements-02.txt, Hallam-Baker, Phillip <=