Re: nonrepudiation (signing messages)

[Himagiri Mukkamala <himagiri@sybase.com>]

I could be wrong, but is'nt this already supported
by the ability of CPA to specify an overriding
"DeliveryChannel" for an "Action".

This would allow different messages
to be sent with different actions if they need
different "Signature" parameters.

-hima

Christopher Ferris wrote:

> Hima,
> This is true, which suggests that a specific binding
> on a per-message basis may be what is needed, not just
> a per-channel basis as currently provided.
>
> >
> > -hima
> >
> > christopher ferris wrote:
> >
> > > Marty,
> > >
> > > My take on this is that this element could take the form
> > > of a Signature "template" which effectively provided
> > > all of the requisite binding information including
> > > reference URI(s) with only the Digest and actual
> > > signature omitted. The IBM Alphaworks XSS4J DSig
> > > implementation provides for use of a template
> > > to drive the signing behavior, which is a nice
> > > feature of the tool (IMHO).
> > >
> > > I have successfully used the SignatureAlgorithm, HashFunction
> > > and Protocol. I haven't used Certificate yet mostly
> > > for implementation reasons.
> > >
> > > Presently, the ebXML MS specification prescribes the
> > > Transform algorithm(s) that MUST be used, as well as
> > > the Reference URIs necessary for the header, but not the
> > > payload item(s) since that would depend upon the Content-ID
> > > or Content-Location URI which might vary from message to
> > > message even of the same type. Thus, presently this is
> > > not an issue. However, to make this more flexible, it might
> > > be useful to have the ability to fully describe the Transform
> > > as well.
> > >
> > > Another approach would be to leverage the Reference element
> > > from the DSig specification, omitting the DigestValue (like the
> > > Signature "template" but without describing the full Signature.
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > > Martin W Sachs wrote:
> > > >
> > > > The NonRepudiation element specifies signing of the messages using XMLDSIG.
> > > > Its child elements are Protocol, HashFunction,  SignatureAlgorithm, and
> > > > Certificate.  I have recently been asked whether NonRepudiation also has to
> > > > have a Transform(s) element. If XMLDSIG provides a choice of Transform,
> > > > then the choice should probably be expressed under NonRepudiation.
> > > > Alternatively, we might prescribe a particular answer in the text and not
> > > > need an element.
> > > >
> > > > If something about transforms is needed in the specification, let's put it
> > > > on the list for the maintenance release.
> > > >
> > > > Regards,
> > > > Marty
> > > >
> > > > *************************************************************************************
> > > >
> > > > Martin W. Sachs
> > > > IBM T. J. Watson Research Center
> > > > P. O. B. 704
> > > > Yorktown Hts, NY 10598
> > > > 914-784-7287;  IBM tie line 863-7287
> > > > Notes address:  Martin W Sachs/Watson/IBM
> > > > Internet address:  mwsachs @ us.ibm.com
> > > > *************************************************************************************