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:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
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