> However canonicalization is merely related to minor syntax changes. The
>other two are trying to protect against some types of semantic changes (but
>not others.)
>
>
Header copying also removes potential ambiguity about which are the
signed headers, when one of the headers to be signed can occur more than
once. Depending on header ordering for this is unreliable.
I'm probably misunderstanding something basic, here. This is what I think you
are saying:
The signer creates an ambiguity, by having multiple headers of the same
name, although this is not recommended, for most headers,. And the way to deal
with this for signing is to duplicate content so the recipient will know which
header of the set is signed? That is, the sender creates an ambiguity and the
way to solve this is by duplicating some of the data?
Perhaps it would be simpler for the signer not to create multiple
headers. And if the signer and creator are different entities, such as
outbound gateway vs. MUA, then the signer should include ALL the headers of the
same name.
> Iim is 'guessing' that it will cover a useful set of semantic changes to
>the message. That is the techniques are thenselves heuristics.
....
OTOH, the specifiers of IIM (me, anyway) may have been 'guessing' what
is useful. :-)
well, yes, that's actually what I mean, albeit without the personal aspect.
These features in the specification represent heuristic techniques seeking
robustness against semantic modification of the message by an intermediary that
is re-posting the message.
>By the way, the semantics of this distinction is much clearer if the
>signing is done by the 822.sender and not the 822.from.
>
How about that idea about making the signature independent of the
headers? Then the signer is the signer, period. This seems like a good
simplification.
I agree. I quite like that compromise also.
I think we're just going to have to agree to disagree on the other
issues regarding whether helping signatures to survive mailing lists is
a good or bad idea, and seek wider consensus.
looks that way.
On Mon, 29 Nov 2004 16:25:11 -0800, Michael Thomas wrote:
> However canonicalization is merely related to minor syntax changes. The
> other two are trying to protect against some types of semantic changes
(but
> not others.)
I'll bite: what's the bright line distinction?
format vs. meaning.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
www.brandenburg.com