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: 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.




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


Powered by eList eXpress LLC