Dave,
You stated:
But if your purpose is to identify which signature/label is applied by
the originator and which by a gateway / MTA / etc, then a lightweight,
flexible mechanism which allows parallel signatures should be an
option. That was Chris Bonnatti's original point. One mechanism is
the "Signature Purpose" attribute referred to in the subject line which
would identify one signature as the originator's.
IMHO, the signaturePurpose attribute should not be used for access control
purposes. For example, what happens if every additional signer includes a
signaturePurpose indicating that she is the original signer???
Another mechanism is
for the gateway's certificate to restrict it's signature from being
interpreted as a message originator's.
This is a huge assumption about people agreeing on how to populate
certificates. It is too much detail for inclusion in the S/MIME specs.
This should be a matter of local policy.
The point is that if:
1) you don't have/support a suitable signature purpose mechanism, and
2) your security policy requires you to identify the originator's label
in order to give it special treatment over all other labels,
then you can still use the left message with signature wrapping to
identify the originator. If either of those is false, then you are
able to use either wrapped or parallel signatures. There is no need
for an arbitrary "labels must be identical" restriction which as a side
effect forces you to always use wrapped signatures.
I disagree. There is no need to attach multiple different security labels
to a single content. Please see my previous messages for my supporting logic.
Note: even with the left message, there is no way to determine the
message originator if multiple signatures contain identical labels.
So the Signature Purpose attribute is useful even with the label
restriction.
If all security labels are identical, then it doesn't matter. That is the
point.
- John Pawling