Re: (long) RE: [ebxml-cppa] Purpose of CertificateRef inCollaborationRole

[Martin W Sachs <mwsachs@us.ibm.com>]

Arvola,

You said:

"Normally, a DeliveryChannel and its referenced  DocExchange represent a
party's receive parameters with the exception that the  certificate
reference under NonRepudiation really represents the sender's  signing
certificate."

MWS:  (suggestion for words in the specification):  Instead of " the
sender's  signing certificate", it should say "the party's signing
certificate as a sender" (to make it clear that it is the same party).

"When a DeliveryChannel's BusinessProcessCharacteristics  indicates that
sync reply is in use, the same HTTP connection is also used to  return the
response message. The response message may have to signed and/or
encrypted. I have been assuming that the certificates used by the receiver
as  a responder should also be obtainable from the NonRepudiation and
DigitalEnvelope elements associated with the DeliveryChannel that is used
by  the receiver to receive the (request) message in the first  place."

MWS:  The certificates obtainable from the NonRepudiation and
DigitalEnvelope elements are the certificates that the same party uses to
sign outgoing messages or for the digital envelope key exchange for
outgoing messages. It has nothing to do with received messages. To me,
these are the same certificates that would be used for signing or
encrypting outgoing asynchronous responses.

MWS:  Note: I have been assuming that for incoming messages, the receiving
party decrypts using its private key corresponding to the certificate that
the other party used to encrypt the message.  I assume that the same is
true for signing.

Regards,
Marty
</ac>


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

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 12/18/2001 03:42:47 PM

To:    Dale Moberg <dmoberg@cyclonecommerce.com>, "ebXML-CPPA (E-mail)"
       <ebxml-cppa@lists.oasis-open.org>
cc:    Peter Ogden <pogden@cyclonecommerce.com>
Subject:    Re: (long) RE: [ebxml-cppa] Purpose of CertificateRef in
       CollaborationRole




Dale:

Please see my embedded comments.

-Arvola
-----Original Message-----
From:  Dale Moberg <dmoberg@cyclonecommerce.com>
To:  Arvola Chan <arvola@tibco.com>; ebXML-CPPA (E-mail)  <
ebxml-cppa@lists.oasis-open.org>
Cc:  Peter Ogden <pogden@cyclonecommerce.com>
Date:  Tuesday, December 18, 2001 11:53 AM
Subject: RE: (long) RE:  [ebxml-cppa] Purpose of CertificateRef in
CollaborationRole



-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent:  Tuesday, December 18, 2001 12:11 PM
To: Dale Moberg; ebXML-CPPA  (E-mail)
Cc: Peter Ogden
Subject: Re: (long) RE:  [ebxml-cppa] Purpose of CertificateRef in
CollaborationRole


Dale:

I was assuming that if certificate references are missing  from the
NonRepudiation element, then perhaps the certificate reference  included in
the CollaborationRole element may be used as the default. I agree  that
this is a confusing optimization and that we should do away with the
defaultSigningCertificateRef attribute.

OK.  What should the element name be to indicate it is for use by a layer
above the  MSH?

<ac>
I guess you  want to reserve the certificate reference within
CollaborationRole for use by  a layer above the MSH. I like Peter's
suggestion of naming this as  ApplicateCertificateRef .
</ac>

I think many implementations will want the MSH to sign on  behalf of the
applications.

Dale >> Yes, I think  this is more typical than the financial use case.

 Therefore, the  certificate references in the NonRepudiation element
should be usable by the  MSH for signing purposes. Otherwise, where are we
recording the signing  certificate that the MSH will be using?

Yes,  I agree that if nonrepudiation is handled by MSH (either origin or
receipt)  then it goes under these elements.

In the 1.0 spec, section 7.6.5 NonRepudiation element, it is  stated:

"If the NonRepudiation element is omitted, the Messages are  not digitally
signed."

 Right, where Message signing is over both payload and SOAP envelope  as in
ebMS.

The NonRepudiation and DigitalEnvelope elements under  DocExchange may be
referenced by a DeliveryChannel that is used synchronously.  Therefore,
each of NonRepudation and DigitalEnvelope should contain two  certificate
references, one is required for the normal case, the other is  optionally
used for signing or encrypting responses that must be returned
synchronously.

Can you elaborate why you think synchronous requires a  different
CertificateRef approach?
I  guess I have not have expected that transport distinction
to  make a difference in terms of what keypairs
get  used in signing or enveloping....

<ac>
Normally, a DeliveryChannel and its referenced  DocExchange represent a
party's receive parameters with the exception that the  certificate
reference under NonRepudiation really represents the sender's  signing
certificate. When a DeliveryChannel's BusinessProcessCharacteristics
indicates that sync reply is in use, the same HTTP connection is also used
to  return the response message. The response message may have to signed
and/or  encrypted. I have been assuming that the certificates used by the
receiver as  a responder should also be obtainable from the NonRepudiation
and  DigitalEnvelope elements associated with the DeliveryChannel that is
used by  the receiver to receive the (request) message in the first  place.
</ac>

Dale


-Arvola

-----Original Message-----
From:  Dale Moberg <dmoberg@cyclonecommerce.com>
To:  ebXML-CPPA (E-mail) <ebxml-cppa@lists.oasis-open.org>
Cc:  Peter Ogden <pogden@cyclonecommerce.com>;  Arvola Chan <
arvola@tibco.com>
Date:  Tuesday, December 18, 2001 10:15 AM
Subject: (long) RE:  [ebxml-cppa] Purpose of CertificateRef in
CollaborationRole