Re: nonrepudiation (signing messages)

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

I think we are in agreement.

Martin W Sachs wrote:
> 
> 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
> > > > > > >
> > >
> >
> *************************************************************************************