[ietf-dkim] Strawpoll on SSP requirement 5.3.10

[Hallam-Baker, Phillip]

Option 5 MUST 

> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org 
> [mailto:ietf-dkim-bounces at mipassoc.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
>