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