Just to clarify the proposal I have has three independent parts, I believe that
each represents a simplification of the current SSP and removes net complexity.
1) Discovery
Discovery of policy records is effected as at present by means of
prefixed TXT records. If no prefixed TXT record is found the verifier looks for
a new record PRPTR standing for Prefixed record pointer. This gives a new
location at which to look for a PTR.
2) Policy
The policy record has a meta-syntax of a sequence of tag, value pairs,
the value slot is optional. The policy contraints of each and every tag
specified must each be met. Defined tags are:
NULL
NOMAIL
DKIM [=selector-constraint]
The DKIM policy is all or nothing. If present then every message sent
has a DKIM header with a selector value that meets the specified selector
constraint.
The selector constraints are simply a suffix that the selector must
have. No regular expressions, matching rules or anything. This allows the
sender to create the effect 'must have a sig of type A and a sig of type B'.
3) Null Key Record
To assist in transitioning from an unsigned to a signed zone it may be
useful to state 'every message is signed except for these'. In order to express
this constraint we introduce null key records. These specify the null signature
algorithm and have no key value. They do however have constraints on the sender
value.
The sender can thus create exceptions to their 'I sign everything'
policy by adding a fixed header referencing the null key record.
Null key records do not authenticate the message, their only purpose is
to claim an exemption from a blanket signature policy.
In aggregate this proposal has half the number of moving parts as the current
SSP proposal and it meets the full set of specified requirements plus the
additional requirements that should be stated if we ever want to change the
specification such as deploy a new canonicalization algorithm.
-----Original Message-----
From: Stephen Farrell
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
Sent: Monday, October 23, 2006 5:07 PM
To: Hallam-Baker, Phillip
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Comments on
draft-ietf-dkim-ssp-requirements-02.txt
Hi Phill,
Before we get into the wording of the latest ssp-reqs, can we
try to figure out whether this is really different from the
set of similar *closed* issues on base?
I am not at all clear why such flags are useful in SSP, given
that we have rough consensus that they are not needed for base.
As I see it:
1. The current WG consensus for base is that its up to each
recipient to decide for itself which algorithms it considers
acceptable.
2. The current WG consensus (I think) is that SSP need not be
used when a signature that the recipient considers "good" is
present. (I.e.
I see no consensus for a position that SSP MUST be used even
if what the verifier thinks is a good signature is present.)
Given 1 & 2 above, I just don't see the point of algorithm
transition information in SSP since no-one will read it who
might act on it.
Please also expliticly explain why this is not simply
revisiting some *closed* issues on base.
Thanks,
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html