The CMS signedData signerInfo signature value is calculated based on a
digest of the authenticatedAttributes included in the signerInfo (assuming
that authenticatedAttributes are present, which they will be in your example
because of the presence of an eSSSecurityLabel authenticatedAttribute). The
only way that the original signer's signature value will be preserved
through a gateway translation is if the recipient end-user software can
calaulate the digest of the identical data that was digested by the signer.
In other words, the end user software would need to be able to hash the
identical authenticatedAttributes SEQUENCE included in the original CMS
signedData signerInfo. It would be a significant modification to your
legacy software to support this requirement. Instead, you may want to
consider converting your applications to use CMS:)
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
At 06:08 PM 3/27/98 -0000, Darren Harter wrote:
I understand and respect your point.
My memory could be failing me here, but I believe that the consensus of
opinion following Tim Dean's
interoperability presentation (I think Jim Schaad expressed it quite well)
in the WG meeting in December was that the issue of allowing Signatures to
remain intact when going through gateways to other security protocols was
important - though not directly under the charter for the group.
As you are aware there are implementations out there that employ signatures
over X.411 labels - primarily using MSP (and soon PCT). To allow signatures
over labels to pass through such gateways does require a bits-on-the-wire
compatibility, and I believe that anything that ESS does to prevent this
will delay acceptance of the protocol for my customers. For my customers,
interoperability with other security protocols through gateways is a primary
I appreciate that some of this is outside the scope of this group.
See you all in LA - perhaps we can discuss further then.