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