Sounds good to me. It seems to me that on the requirements side, IF people are OK with my statement of the problem then there are three main responses that people might have:
1) The requirement is an absolute necessity 2) It is something that may be necessary but falls short of being essential 3) There is no case in which satisfying the requirement is useful to any party So far I see people stating that (3) is the case but only providing arguments which support (2). Rather than doing a binary strawpoll I would like to see a distinction made between these cases. > -----Original Message----- > From: Stephen Farrell [mailto:[EMAIL PROTECTED] > Sent: Friday, March 02, 2007 12:45 PM > To: Hallam-Baker, Phillip > Cc: DKIM > Subject: Re: [ietf-dkim] Proposed 1368 wording draft 1 > > > Thanks Phill, > > Since Mike has to get -03 out by Monday I've asked him to > include (some version of) your text in that and we can do a > strawpoll on its inclusion/exclusion later on. (There isn't > time before the cutoff now.) > > Once -03 has issued I'll start that strawpoll so we should > have a reasonable picture of the WG opinion before Prague > unless there's a major backlog with the I-Ds, > > Cheers, > Stephen. > > Hallam-Baker, Phillip wrote: > > Since we are drafting a requirement here we do not need to > give the explanation in the detail given on the list. > > > > 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 > > > > Rationale: 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
