Re: Security - question about nonrepudiation

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

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