[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: (long) RE: [ebxml-cppa] Purpose of CertificateRef inCollaborationRole
Hi
Arvola,
Rather than doing away with the
DefaultSigningCertificateRef in CollaborationRole, why don't we rename it
something like "ApplicationCertificateRef", or "BusinessProcessCertificateRef" -
that way, it is available to negotiated and agreed upon (even though it won't be
used by the MSH, which my comments in the text will reflect).
Regarding the cert refs in DocExchange: the 04 draft
schema has a single EncryptionCertificateRef under DigitalEnvelope. Are planning
to add another, much like you did for NonRepudiation?
Also,
I gather from your last paragraph below that you intend for the
initiatorCertifcateRef to be used for signing requests and asynchronous
responses, and that the responderCertificateRef would be used for signing
synchronous responses. Would it work just as well to suggest that the
initiatorCertificateRef be used for requests and
the responderCertificateRef be used for all responses (both synch and
asynch)? It just seems more logical to tie the use of the cert to its role
in the message exchange rather than to the "synchronicity" of the protocol.
Finally (and this is a nit), would you mind
initial-casing the NR certifcate ref names (InitiatorCertificateRef and
ResponderCertificateRef)? Just to be consistent with the others
...
Respectfully,
Peter
-----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.
I think many implementations will want the MSH to sign on
behalf of the applications. 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?
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."
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.
-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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC