OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Problem with Non Repudiation over a Synchronous Delivery Channel



Arvola,

You seem to have spotted a serious inconsistency.  The delivery channel
describes receive properties.  So putting the certificate reference under
NonRepudiation makes no sense at all since the sender has to sign.  This is
another case that cries out for send properties in the CPP and CPA.
Another one is SendingProtocol, which describes the protocol that the owner
of the CPP expects a business partner to use but is currently in a (receive
properties) delivery channel.  There may well be other requirements that a
CPP could express about a business partner.  One example might be to state
which certificates are acceptable, i.e. what CA the owner of the CPP
trusts. Another might be send capabilities under DocExchange (the signing
certificate is actually on example of this).

The CPPA team should give serious consideration to establishing a separate
element under which would be requirements the CPP and CPA state about
business partners.  This might be a reusable element that could be
referenced from delivery channels.

For the signing certificate, the signing certificate would be indicated in
a separate element in the CPP and the CPA composition tool would place it
under a business partner properties element in the CPA.

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



Arvola Chan <arvola@tibco.com> on 08/21/2001 04:57:48 PM

To:   Dale Moberg <dmoberg@cyclonecommerce.com>, christopher ferris
      <chris.ferris@east.sun.com>
cc:   ebxml-cppa@lists.oasis-open.org
Subject:  Problem with Non Repudiation over a Synchronous Delivery Channel



Dale and Chris:

The CertificateRef under NonRepudiation is presumably the
certificate used by the sender for signing.

What happens if syncReplyMode is set to something other
than None? In that case, the receiver (responder) has to
deliver the response document over the same channel. Where
is the CertificateRef for signing by the responder?

Cheers,
-Arvola

-----Original Message-----
From: Dale Moberg <dmoberg@cyclonecommerce.com>
To: christopher ferris <chris.ferris@east.sun.com>; Arvola Chan
<arvola@tibco.com>
Cc: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Tuesday, August 21, 2001 1:31 PM
Subject: RE: Does CPA support SSL mutual authentication?



> There is no explicit CertificateRef for signing. Presumably, it has to
> be stored at the CollaborationRole level.

Yes there is. The certificateRef under NonRepudiation is for signing.

Dale>> Oops, I remember this now being added. Thanks Chris.


I would agree though that bilateral exchange of certs in SSL
is probably not addressed in the 1.0 spec. A CPA would need
to identify the sender and receiver certs such that both parties
know which certs will be used to authenticate the SSL connection.
A CPP on the other hand should identify only the certificate that
it will use for a given connection, leaving a blank to be
filled in during cpp->cpa negotiation.

Dale>> Need to decide if this is a 1.1 issue soon.

I think that the CPP/A addresses the ability to use as many
keys for the various functions as deemed necessary. The certificate
which identifies the public/private key pair that is used for
SSL need not be the same as that used for NR or for some other manner
of authentication because the CPP/A does not limit the number of
certificates
that may be listed in a CPP/A.

It might be useful to provide (possibly in 1.1 but more likely in
2.0) for each certificate to be accompanied by a purpose or description
that made it clear as to what it represented. This may deserve some
consideration.

Dale>> Agree, it might make it easier to understand which cert goes
with which security function.



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC