[ietf-dkim] Strawpoll on SSP requirement 5.3.10
hsantos at santronics.com
Wed Mar 21 11:12:04 PST 2007
I prefer to vote #1.
sorry for the "comments." I'll won't debate but my reasoning is as follows:
Some of the text as written doesn't make sense. A MUST NOT for the
these itemize points?
* Require the verifier to perform any additional DNS lookups
* Require duplication of configuration data
The first one seems to be a compromise to appease those who might want,
no, require a 2nd lookup in their implementation, but the author seem
dead set to control this from happening. Good luck! And Its none of
anyone's business (they have will not have any control or say in this
process) how one who would implement configuration data. Seems totally
In any case, there are many things in the requirements that doesn't make
sense and its not worth the time. But you're polling for this one, so I
vote to leave it out.
Stephen Farrell wrote:
> Hi All,
> At today's DKIM meeting (notes to follow) we discussed
> the in/exclusion of requirement 5.3.10 in ssp-reqs 
> (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 .
> 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.
>  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
> 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
> NOTE WELL: This list operates according to
More information about the ietf-dkim