Option 5 MUST
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Stephen
Farrell
Sent: Wednesday, March 21, 2007 1:45 PM
To: ietf-dkim
Subject: [ietf-dkim] Strawpoll on SSP requirement 5.3.10
Hi All,
At today's DKIM meeting (notes to follow) we discussed the
in/exclusion of requirement 5.3.10 in ssp-reqs [1] (the
current text is below). We didn't have a clear consensus at
the meeting despite an extended discussion and a lot of
previous list traffic.
We need to decide this now in order to finish the ssp-reqs
work and to start the ssp work, so Barry and I will collate
the responses to this in a week and we'll then make the call
about what to do.
Wordsmithing is another thing, but we've discussed this
enough to decide now. So, *please* just pick an option and
don't lets divert this to discussing a different question.
This is also Issue #1386 in the tracker [2].
Your choices:-
1) Exclude this requirement (don't mention it)
2) Include this requirement as a MUST NOT
3) Include this requirement as a MAY
4) Inlcude this requirement as a SHOULD
5) Inlcude this requirement as a MUST
The MUST/SHOULD etc. here refer to whether or not the SSP
protocol MUST/SHOULD etc. meet the requirement.
Stephen.
[1]
http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-requir
ements-03.txt
[2] https://rt.psg.com/Ticket/Display.html?id=1386
[PROVISIONAL] The signing policy statement MUST be capable of
fully describing a signing practice in which
multiple signatures
are always provided such that the policy is of utility to any
verifier is capable of verifying any of the
signatures that are
always provided. Such a mechanism MUST NOT:
* Require the verifier to perform any additional DNS lookups
* Require duplication of configuration data
* In particular not require the policy record to provide for
the description of any cryptographic or cannonicalization
algorithm
INFORMATIVE NOTE: The ability to specify multiple
signatures
is necessary in order to permit orderly transitions to new
cryptographic and canonicalization algorithms. Unless the
policy language is not sufficiently expressive to
allow the
signer to describe the actual signature practice
in this case
there is an opportunity for an attacker to
exploit the fact
that there are verifiers that do not yet support the new
algorithm.
_______________________________________________
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