Your requirements can be met be the gateway encapsulating the CMS object in
an outer signedData object in which the gateway can include its
eSSSecuritylabel. This preserves the originator's signature and
eSSSecurityLabel end-to-end. This strategy makes it much simpler for the
receiving gateway (that you mention) to strip off the outer signedData
applied by the gateway that previously processed the CMS object. It also
makes it simpler for the recipient to distinguish between the signedData
constructed by the original signer (inner) and that constructed by the
gateway (outer) (in the event that the GW's outer signedData was not
stripped by the receiving GW). In summary, I believe that the
ESSSecurityLabel strategy should remain as is.
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
At 09:16 AM 4/9/98 +0100, William Ottaway wrote:
Here is my two penneths worth.
I agree that signatures are end-to-end and therfore the originator
signature must not be removed. A gateway may put its own signature on,
which may contain a label which maps to the originators label.
The signature applied by the gateway could be stripped off by a receiving
gateway. In the case of no receiving gateway the end recipient then has the
choice as to which signature to use. This could be none, one or more. In
which case the recipient would need to be able to identify which signature
is the originators and which, if any, belongs to a third party.