From: "Jim Schaad (Exchange)" <jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com>
I can provide an even better example of this:
Lets assume that I, being a normally nasty person, places two different
signatures on a message. The first signature is a DSS signature which
contains an unclasified label on it. The second signature is an RSA
signature and contains a classified label on it.
Jim,
First and most importantly, I withdraw the proposal to allow signatures
with different labels in the same SignedData. Not because I'm convinced
that a restriction on label equality is useful, but because further
discussion seems counterproductive at this time.
However, in your scenario, the message had better be unclassified, or
the user is in trouble. There are probably criminal penalties for
the unauthorized release of {classified/company proprietary} information.
If there are penalties at all for putting a classified/proprietary
label on unrestricted information, they are probably much less severe.
You, being a normally nasty person :-), nonetheless probably aren't a
masochist seeking to be fired or fined, so your message probably doesn't
contain any labels with your signature on them which could get you in
trouble. If it does, you asked for it. This has nothing to do with
the label equality question - you'd be in just as much trouble if you
put an RSA signature and a DSA signature with identical unclassified
labels on a message which was classified.
I assume a threat model where:
1) the message originator operates "correctly" (in accordance with the
protocol specification and applicable security policy), and
2) attackers are active (are able to modify messages in transit) but
do not possess unauthorized private keys.
The attacker's goal is to convince the recipient, or anyone else, that
the originator said something other than what the originator actually
said.
I contend that in the assumed environment, the restriction that labels
in a single SignedData be identical accomplishes nothing. If originator
"x" creates a SignerInfo with label "X", and entity "y" creates a
SignerInfo with label "Y", then there is no important* cryptographic
distinction between putting those two SignerInfos in a single SignedData
or in encapsulated SignedData's. In either case, one or both signatures
can be stripped from the message by an adversary, and one or more signatures
may be created using the adversary's private key(s).
-----
* The cryptographic distinction is that with encapsulated SignedDatas,
"y" binds signature "x" to the original message. This would be important
if there were a requirement that "a message signed by x is not recognized
as valid unless it is wrapped by y". Since there is no such requirement,
there is no reason to force SignerInfos with labels X and Y to be in
different SignedDatas.
Again, I withdraw the suggestion to remove the label equality restriction,
despite my belief that the restriction adds no security value to S/MIME.