Since the semantics of this signature are different from any of the
others (this is really a signature from the domain owner, or his/her
proxy, indicating permission to use an address in their domain), another
type of signature is required anyway.
Given that specifications exist for how to use S/MIME at the domain level, this
appears to be false.
Mind you, I happen to think another type of signture is indeed required here,
but not because the domain owner is the one signing things.
Even if you do this as a
multipart/signed MIME part, the signature needs to be different from
S/MIME, PGP, etc. for that reason (in addition to the need to bind with
some subset of the message headers).
Protecting outer headers is indeed a reason not to use any of the existing
schemes. (I do note that encapsulation can be applied to reuse existing schems,
but IMO this is a really bad approach.)
Given that it does need to be different, a lot of us have looked at how
to encapsulate the signature, and have decided that the easiest way to
be compatible with existing stuff is to create a new header. Perhaps
that's a different discussion, though.
Once again, this isn't necessarily an end-to-end scheme.
Actually, the draft charter sort of says this. At one point it refers to
"transit time use", at another it refers to "short term protection". The
problem is that this still leaves end-to-end mechanisms in scope, and people on
the list have been pushing for things that are closer to end to end and further
away from long hop.
Intermediaries
that modify the message SHOULD re-sign it.
Change that to a MUST (for compliant intermediaries) and recognize the fact
that such intermediaries are currently the rule, not the exception, and we'd
pretty much be in agreement. But I see no consensus behind this approach on
the list.
Ned