Jim:
I don't believe that this solves a large enough set of problems to be
interesting. I would hardly call items 1 and 2 irrelevant. These are
normal cases which will show up in day to day actvities. I forward a piece
of mail to you which was signed and labeled by the originator --- you can't
open the message because you don't understand the policy involved. This is
exactly the type of thing I though this was suppose to solve.
For simplicity, lets assume that there is not any encryption. I think it
just clouds the issues associated with atributes in SignerInfo.
I think that you are poiting out the difference between one SignedData
being encapsulated in another as opposed to two SignerInfo values that are
part of one SignedData. The two have very differnt properties. And, both
are useful in different conexts.
As you point out, one SignedData encapsualted in another is used in
forwarding. The recipient might be very confused by conflicting security
labels on the two SignedDatas; however, it is clear which content is overed
by any access control decision made based on the label.
Parallel SignerInfos, on the other hand, relate to the same content. The
ESSSecurityLabels must match. If an intermediate system knows that some
recipients cannot handle the security policy within the ESSSecurityLabel,
it provides the equivalent label for those recipients. The recipient ets
to choose which SignerInfo to process. This capability permits the
originator to sign with more than one algorithm, say DSS and RSA. Thus,
the recipient can process the SignerInfo associated with the algorithm it
implements, and the recipient ignores the other SignerInfo. Similarly, the
recipient can choose the SignerInfo that includes the equivalent labels
instead of the one with just the original originator provided
ESSSecurityLabel.
Russ