FW: Security - question about nonrepudiation

["Collier, Timothy R" <timothy.r.collier@intel.com>]

Forgot to copy the list.

-----Original Message-----
From: Collier, Timothy R 
Sent: Wednesday, August 01, 2001 1:01 PM
To: 'Martin W Sachs'
Subject: RE: Security - question about nonrepudiation


Marty,

	I am mostly trying to come up to speed and understand the intent of
the existing structures so, I apologize if I am being overly dense.  In your
new work doc one of the items to be looked at is the nonrepudiation element,
so I thought I would start trying to understand the issues and start a
discussion around that topic.  So hence, the thread.  The specific issue,
for me at the start is where each security detail applies.  When I look at
the BPSS+CPP security definitions I get the following hierarchy

Abstract security indicators (or process requirements)


BPSS
	isAuthenticated (Document envelope or attachment attribute) -
		 a digital certificate is associated with the document
entity
	isConfidential (Document envelope or attachment attribute) - 
		is encrypted
	isTamperProof (Document envelope or attachment attribute)- 
		encrypted message digest and senders digital certificate

	isLegallyBinding (BusinessTransactionActivity attribute) - 
		the business transaction is/is not legally binding
	isNonRepudiationRequired (businessActivity attribute) -
		must save audit trail
	isNonrepudiationOfReceiptRequired (businessActivity attribute)-
		must digitally sign receiptAcknowledgements (assumes a
receipt ack)
	isAuthorizationRequired (businessActivity attribute) - 
		must validate identity of the originator

Given that my business analyst has provided me, the implementer, with a BP
that has the above fields set, I then try to map them into how I am going to
implement them.  

Abstractly I map my requirements (possibly overriding them with my own)

	BPSS 					CPP Delivery Channel
characteristics
	
isAuthenticated				authenticated + secureTransport
isConfidential				confidentiality
isTamperProof				authenticated and confidentiality

isLegallyBinding				?
isNonRepudiationRequired		nonrepudiationOfOrigin
isNonrepudiaitonOfReceiptRequired	nonrepudiationOfReceipt
isAuthorizationRequired			authorized
	?					secureTransport
	?					syncReplyMode




Concretely I implement my requirements. (Here is where I seem to not
understand the uniqueness of the nonrepudiation)


	Delivery Ch.			Implementation Details
authenticated				TransportSecurity (Transport -
ReceivingProtocol)
						+ NonRepudiation
(DocExchange)

secureTransport				TransportSecurity 
confidentiality				DigitalEnvelope (DocExchange)
authorized					?

nonrepudiationOfOrigin			NonRepudiation (DocExchange)
						 + TransportSecurity

nonrepudiationOfReceipt			NonRepudiation (DocExchange)on an
assumed
acknowledgement	
						 + TransportSecurity	
			
	
My misunderstanding seems to center on the line between authenticated and
nonrepudiation.  The BP seems to indicate that isAuthenticated implies that
a signature is associated with the document, I assume that is an application
level signature.  So CPP's "authenticated", in trying to meet the BPs
"isAuthenticated", would require the use of the nonrepudiation element.
Likewise, the "nonrepudiationOfXX" implies an application level signature,
so I don't see how the two are different.  My basic thinking is, if I can,
as an implementer, describe 

	document security details 
		encryption, and signature
	transport security details
		encryption and endpoint authentication 
	business transaction security details
		like authorization and entity authentication
( and maybe some way to describe the ordering of the processing)


haven't I covered all of the bases?  Nonrepudiation is then covered by the
document signature.  Whether I keep a log is entirely an internal issue and
my trading partner should neither need to know nor care.

Thanks for your help,

		Tim
 




	

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, August 01, 2001 8:27 AM
To: Collier, Timothy R
Subject: RE: Security - question about nonrepudiation



Tim,

As I said in the reply that you appended to your posting, what the
nonrepudiation element defines is the variables that have to be agreed to
between two parties in performing XML DSIG - hash function, signature
algorithm and certificate reference.  These details are not defined in the
BPSS instance document.  It only says "thou shalt sign".  My earlier reply
appended below points out other open matters and loose ends that have to be
dealt with under message security.

The authenticated attribute of the Characteristics element does not spell
out the details of how to authenticate. It only says whether authentication
is or isn't required.  The "how to" details that have to be agreed to
between the parties belong in the document-exchange section.

The attributes of Characteristics are simply counterparts of the same
attributes in the BPSS instance document.  There purpose is to possibly
override the values in the BPSS instance document.  The document-exchange
section has to spell out the "how to" details.

If I didn't understand your question, please try again.

****************************************************************************
*********

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 06:58:38
PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   ebxml-cppa@lists.oasis-open.org
Subject:  RE: Security - question about nonrepudiation



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