It is my understanding that even when the wrapping technique is used
the S/MIME specification request that all the labels be identical.
Or have I got that wrong and they may be different in the wrapping case?
Also, as the ESS text is now, my understanding is that the originators
is mandated and must be part of the recipients access control
rules even it the label has no semantics in the receiving domain.
Those are the two issue I am arguing against.
From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
To: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
Date: Tuesday, April 14, 1998 11:45 AM
Subject: The big picture in eSSSecurityLabels
I think the current debate about where a second signer on a message can put
their security label may be missing the point. The reason for allowing a
security label at all is so that the originator of a message can specify a
desired (but not required) security policy for the recipient. There are
lots of other things we can do with the labels, but they must not interfere
with the original purpose of helping the recipient. Security labels do help
the sender, but they are really there for the recipient who cares about how
to process the message.
A signer other than the originator might want the recipient to use an
additional security policy when processing the message. That's fine, but it
must not negate the policy desires of any other signer, and it must not
prevent the recipient from knowing the original signer's desires. When
there are two or more signerInfos in a SignedData block, the recipient has
no idea who the original signer was. Therefore, the rule we came up with
for eSSSecurityLabels said "if there's already a label there, you cannot
put a different one". With this rule, the recipient still doesn't know
which of the signers was the original, but the recipient does know what the
original signer's policy intent was.
This is not to say that later signers should not be able to add different
policies: they should. However, to do so in a fashion that lets the
recipient still know what the originator's policy desires are, the later
signers use wrapping. To a recipient, this format of message is
unambiguous: they know the policy desires of the original signer even if
there are many signatures on the inside SignedData, and they know what
different policies were added by someone else.
Using this mechanism allows recipients to have policies that say either
"act on all policies" or "ignore policies on signatures other than the
originator". Both of these are perfectly reasonable choices for a receipt
policy. If we don't give the recipient that choice, we've taken away a very
important feature for no reason other than smaller message size.
Even if we had a "signature purpose" attribute that said "I'm the
originator", or even a bit in the eSSSecurityLabel that says "this is the
originator's label", we can't allow arbitrary signerInfos to have different
labels. Imagine the case of three signers with three different policies.
Even if there is a rule that "if an earlier signer has called themselves
the originator, you can't say you are", the recipient won't know which of
the other two signed second, but this information could be important to
them when deciding whether or not to act on a particular policy. We'd still
be taking away information from them.
In short, the current draft allows every feature that we want the recipient
and any signer to have. The only downside of the current draft is the size
of the message for multiple signers who want different policies, but that
is much less important than having the recipient know exactly what policies
were applied at different times during the signing of the message.
--Paul Hoffman, Director
--Internet Mail Consortium