Re: Security - question about nonrepudiation

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

Tim,

"Collier, Timothy R" wrote:
> 
> Chris,
> 
>         Thanks.  Hum... I think the nonrepudiation element seems to need

most likely;-) As I think Marty already indicated, it is on the list of 
things to do.

> some work ;)  Ok, the authenticated element is a transport characteristic,
> makes sense. But still, the only method supported, right now, for
> nonrepudiation is digital signatures, which is already defined (in the
> docExchange).  Just seems like the nonrepudiation element is like pushing an
> elevator button that is already lit, it might make you feel good, but it
> doesn't really do anything.

Not certain that I necessarily agree. Digital signatures can employ
a wide variety of algorithms. Getting to agreement on which of these are
supported (from a CPP perspective) and which shall be used (in the CPA
perspective) for a given exchange is relatively important. This might vary
either from agreement to agreement and possibly from message to message.

> 
>         We should sync the MS signature methodology with the CPP/A
> definitions for the application of signatures.

I'm not sure what you're suggesting. I authored both;-) What is it that
you feel is inconsistent between the two?

> 
>         Regards,
> 
>         Tim
> 
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Tuesday, July 31, 2001 4:24 PM
> To: Collier, Timothy R; ebxml-cppa@lists.oasis-open.org
> Subject: Re: Security - question about nonrepudiation
> 
> Tim,
> 
> The MS spec clearly defines how to sign a message (SOAP envelope
> and its contents plus any attachments listed in the Manifest).
> I will grant that this may be overkill in certain situations
> (e.g. if one of the attachments is an image that would require
> excessive overhead to sign and no benefit would be derived from having
> it signed).
> 
> As to authenticated, the mechanism used to authenticate the source
> of a message MAY be orthogonal to the mechanism used to provide
> non-repudiation. A message exchange that does not require NR might
> still require authentication at the transport level, which is what
> the Authentication element is intended to provide at that level
> (granted, it may need some work as well).
> 
> The fact is that there are many layers at play, each can add
> something to the next or not as the case may be. The "authentication"
> provided at the transport layer might not be bi-lateral. In fact,
> it may only be transient (to prevent m-i-m attack on a network
> connection) in which case the certificate that generates the keys
> to be used is not verified, it is just used to establish the keys
> to be used to encrypt/decrypt the packets sent on the wire.
> 
> The signature itself may not be the entity that is authenticated,
> but merely a mechanism that ensures that that entity (such as a
> SAML assertion) is authentic and hasn't been tampered with in-transit.
> 
> Great discussion!
> 
> Cheers,
> 
> Chris
> 
> "Collier, Timothy R" wrote:
> >
> > Marty,
> >
> > I was reading the risk assessment and that is what started this.  I do
> think
> > we need to address, in the CPP/A, how to indicate what the signature is
> > applied to - header, body, attachment, entire thing - but I don't see how
> > the nonrepudiation elements adds something new.
> >
> > What I was wondering is if we define the document exchange details, like
> > nonrepudiation (digital signature) and digital envelope (encryption) don't
> > they cover all of the requirements already?  Even the existing delivery
> > channel definition does not need the nonrepudiation element as it covers
> the
> > signature requirement via the authenticated element.  In the delivery
> > channel definition, IMHO, the authenticated and nonrepudiation elements
> are
> > redundant.
> >
> > I was mostly trying to get some discussion started on some of these areas
> > within security.
> >
> >         Tim
> >
> > -----Original Message-----
> > From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> > Sent: Tuesday, July 31, 2001 3:41 PM
> > To: Collier, Timothy R
> > Subject: Re: Security - question about nonrepudiation
> >
> > Tim,
> >
> > The attributes in the BPSS instance document don't say anything about how
> > to actually do nonrepudiation.  The CPP/CPA is precisely where the two
> > partners agree on what standard to use (actually XML DSIG is the only one
> > we support) and various details of XML DSIG such as certificates,
> signature
> > algorithm, transforms, etc.
> >
> > There are some questions as to whether what is in the CPP/CPA is correct
> > and whether it is comprehensive enough to, for example, cover the
> > application-level response, signing of payload vs signing of the entire
> > message,  and the signals that may need to be signed.  Some of these
> > questions are covered in my new.work document and the previous Changes
> > document.  Others may be called out in the ebXML Risk Assessment document.
> > It does need a thorough going over.
> >
> > 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
> >
> ****************************************************************************
> > *********
> >
> > "Collier, Timothy R" <timothy.r.collier@intel.com> on 07/31/2001 05:25:40
> > PM
> >
> > To:   ebxml-cppa@lists.oasis-open.org
> > cc:
> > Subject:  Security -  question about nonrepudiation
> >
> > All,
> >
> >      If two parties agree on complimentary roles within a process
> > specification, and agree on the document properties (in particular
> signing)
> > don't the nonrepudiation elements in the delivery channel characteristics
> > become superfluous?  After all, the parties have agreed on a process
> > specification that includes acknowledgement of receipt, and they have
> > agreed
> > on which documents have signatures attached (in the document exchange).
> To
> > me NRR sounds like a requirement on the BP, and NRO is a document
> > requirement for digital signature.
> >      I have heard that the delivery channel is an implementation
> > convenience, which is ok, but it seems even for that the authenticated tag
> > covers the digital signature requirement. And the implementation already
> is
> > monitoring the runtime process according to the BPSS.
> >      Do you think the nonrepudiation tags in the delivery channel express
> > unique requirements that are not already covered?
> >
> >      Tim
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org