From: Clive D.W. Feather (clive@demon.net)
Date: Mon Jun 07 1999 - 10:55:14 CDT
Charles Lindsey said:
> Firstly, our current draft allows additional headers to be added _after_
> the existing ones.
[...]
> in Brad's scheme, you just say that the signature is taken
> from the top (after the variant/locals) down as far as the Signed header
> itself. That way you can add a second Signed header later if you want.
>
> But the _real_ problem, which applies to both your schemes, is the
> presumption that you can tell which headers are local and/or variant.
If headers can not be reordered by relays, the answer is simple: the signed
headers are those lying after the header:
Signed: start <token>
and before the header:
Signed: value <token> <signature-data>
where <token> simply makes it easy to match start and end. [You could omit
it, but then if any Signed: header gets damaged you're in trouble.]
If headers *can* be reordered, then either we have to forbid reordering
within such a Signed: block, or we have to go a different path entirely,
such as:
Signed: <signature-data> <header-name-list>
E.g.
Signed: pgp-md5-294751571471204713 From Subject Newsgroups Date
meaning that only those four headers were included, in that order.
[Haven't I seen this discussion before ?]
-- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8371 1138 Internet Expert | Home: <clive@davros.org> | Fax: +44 20 8371 1037 Demon Internet Ltd. | WWW: http://www.davros.org | Mobile: +44 973 377646