> > discussions of multiple signatures, multiple *linked* signatures,
> > which could work TOGETHER to convey information, and the protocol
> > doesn't allow that sort of thing.
> We have certainly beaten to death the issue of whether signatures can
> or should survive mailing lists, an aspect of the underlying argument
> about whether a list is an endpoint or a forwarder. I think we can
> all agree this is not an argument we're going to resolve any time
> soon.
> I don't understand what the security model of linked signatures would
> be, and I doubt anyone else does, either.
Considerable time was spent on the nested/linked/multiple signature issue
during the work that led up to the specification of security multiparts and
MOSS. We never got a handle on it either and it wasn't for lack of trying.
> Since DKIM allows multiple
> signatures now, and allows you to put private fields in the signature
> header, there's plenty of tools available for people to experiment,
> and if the experiments pan out, add linking in DKIM N+1. But it
> strikes me as a poor idea to make a change this basic on short notice
> at this late date..
I emphatically agree. I will also note that a comparable set of tools are
provided by multipart/signed to MOSS (not that anyone cares about MOSS any
more), PGP, and S/MIME, and pretty much nothing has come of it. Maybe DKIM will
be different, but while I'm optimistic that DKIM will see better deployment,
that optimism doesn't extend to tricky stuff in this area.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
