Re: nonrepudiation (signing messages)

[christopher ferris <chris.ferris@east.sun.com>]

Correct, however, what I am suggesting is that maybe the
DocExchange binding is the wrong level of granularity
for this sort of thing.

Cheers,

Chris

Martin W Sachs wrote:
> 
> Yes, if Chris meant "per message definition", then the override element
> provides the "per message definition" binding.
> 
> 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
> *************************************************************************************
> 
> Himagiri Mukkamala <himagiri@sybase.com> on 06/13/2001 01:15:26 PM
> 
> To:   Christopher Ferris <chris.ferris@east.sun.com>
> cc:   Himagiri Mukkamala <himagiri@sybase.com>, Martin W
>       Sachs/Watson/IBM@IBMUS, ebxml-cppa@lists.oasis-open.org,
>       ebxml-tp@lists.ebxml.org
> Subject:  Re: nonrepudiation (signing messages)
> 
> 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
> > > > >
> *************************************************************************************