I am trying to keep this discussion at the level of the charter, so
starting at the bottom of your message:
Are these requirements? I suppose so, but they all seem pretty
obvious in context.
I agree on both points: they are requirements and they are obvious in
context. Your points were:
what does the signature protect
granularity of the signature
My point is that both the S/MIME and PGP technologies (there is a third,
RFC1848-MOSS, which I only mention I believe is applicable because we're
not talking about solutions) are agnostic on all three points. This
means that the specifications as written describe a profile that may not
work directly but the core technology is just fine.
All are designed to work with email. More precisely, all work with MIME
objects, which is really all that is needed.
So, the charter could say we're looking to meet the requirements you
mention (which it does) and include as a non-goal creating a new
protocol for generating a signature in email (which it does not).
By way of example, consider the use of security multiparts (RFC1847).
All it needs to be part of a solution to this problem is a secure email
protocol and a bit of a profile for the use of the protocol, where the
profile covers the three points you mention. MTA Signatures is most of
what I'm talking about.
All I'm trying to avoid is this group creating the sixth email signature
protocol. I agree that everything else mentioned is work to be done.