On Mon, 08 Nov 2010 09:20:19 -0000, Barry Leiba
<barryleiba(_at_)computer(_dot_)org>
wrote:
I have a chair statement to start with, and then the rest of this
message will be as a participant.
As chair:
We have gone off in the weeds on the "double header" issue, and are
fighting with ourselves. The chairs need everyone to aim at getting
some rough consensus on this, so we're asking this: let's focus, as we
once did, on working together to achieve a result that most of us, at
least, can live with. That means that many people will not get it
just the way they want it, and you might not see a result that you
consider ideal. I think we're close enough, really, on this that we
can still get a result that we consider acceptable.
OK. Here is a suggestion. I think it is broadly in line with your
"proposal", but it includes various almost-orthogonal parameters that can
be tweaked independently of each other to provide a final version.
Word-smithing can come later, and it will also need NOTEs and Security
Considerations to explain the problem(s) and how they are covered. But be
clear that this is an unashamedly Normative proposal.
1. Framework:
o Signers MUST/SHOULD do "something" (see below) in the event that the
message contains multiple "once-only" headers.
PLUS
Verifiers MUST/SHOULD check that "something" had been correctly applied
(else PERMFAIL). Note that this will catch both headers maliciously added
in transit/replay and malicious signers.
o As above, but covering other RFC 5322 violations as well as "once-only"
headers.
2. Normativeness:
o MUST
o SHOULD
3. Definintion of "something"
o Refuse to sign (i.e. reject) if multiple "once-only" found [or other 5322
violations]. I had a wording for this.
o Permit signing of multiple "once-only" (even though violating 5322), but
require ALL those headers to be signed (i.e. included in 'h=' tag).
Hector has a wording for this.
4. Scope of "something"
o Apply the above to ALL multiple "once-only" headers found.
o Apply the above only to those headers actually mentioned in the 'h=' tag.
(e.g. allow multiple Subject:s if Subject entirely absent from 'h='.)
5. Definition of "once-only"
o Just the From: header
o All headers defined as once-only in RFC 5322.
o As above, but include RFC 2045
o As above, but include at least some List-* headers
o Other, please specify
I count the permutations of those as leading to 80 different proposals,
though I suspect some of them are not meaningful. But they cover most of
the normative-style proposals that have been made during the dicussion.
And note that there are no layering violations (since the one protocol
simply introduces a requirement to be applied at one stage and checked at
another).
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html