Re: nonrepudiation (signing messages)

[Martin W Sachs <mwsachs@us.ibm.com>]

Chris,

The main point is that you agree with my (3).  However I do want to ask
what you mean by "Couldn't the CPA provide those parameters to the runtime?
".  What I meant by "message by message" was that the same message defined
in the same business transaction might have different security parameters
each time it is issued.  The CPA can't help with that. Apparently what you
meant by "per message" was "per message definition", which is satisfied by
my (3).

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
*************************************************************************************



christopher ferris <chris.ferris@east.sun.com>@Sun.COM on 06/13/2001
03:06:43 PM

Sent by:  Chris.Ferris@Sun.COM


To:   Martin W Sachs/Watson/IBM@IBMUS, Christopher Ferris
      <chris.ferris@east.sun.com>
cc:
Subject:  Re: nonrepudiation (signing messages)



Marty,

Please see below.

Cheers,

Chris

Martin W Sachs wrote:
>
> OK, avoiding mentioning specific elements in the existing CPA, I can
think
> of only three levels of granularity that are relevant to the CPA.
>
>      Entire CPA
>      Per delivery channel
>      Per business transaction.

Agreed.

>
> The above are covered by the existing DeliveryChannel, ServiceBinding,
and
> Override elements.

Right.

>
> The next finer granularity is per message.  I don't know how to express
> that in the CPA.  That would be up to the sending software or middleware
to
> provide the security parameters to the Message Service on a message by
> message basis.

Couldn't the CPA provide those parameters to the runtime?

>
> Another possibility, which is really at the same level of granularity as
> (3) is to express message security separately from the delivery channel
so
> that we wouldn't have to define multiple delivery channels just to vary
the

Right, that was my thinking. It would also provide a link for the
packaging and possibly the definition (ala WSDL).

> message security.  That MessageSecurity element would have to cover all
> three levels of granularity listed above.  For (2), the delivery channel
> could point to it with an IDREF as it does for certificate.  For (3), the
> message security element would have to point to the Proc Spec document
and
> business transaction within it.

Sounds reasonable.

>
> Regards,
>
> Marty
>
> 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
>
*************************************************************************************

>
> christopher ferris <chris.ferris@east.sun.com>@Sun.COM on 06/13/2001
> 01:41:27 PM
>
> Sent by:  Chris.Ferris@Sun.COM
>
> To:   Martin W Sachs/Watson/IBM@IBMUS
> cc:   Himagiri Mukkamala <himagiri@sybase.com>,
>       ebxml-cppa@lists.oasis-open.org, ebxml-tp@lists.ebxml.org
> Subject:  Re: nonrepudiation (signing messages)
>
> 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
> > > > > >
> >
>
*************************************************************************************