----- Original Message -----
Sent: Friday, January 25, 2002 6:57
PM
Subject: [ebxml-cppa] Proposal:
Application encryption versus MSH encryption
In several recent
CPPA conference calls we have discussed issue #194, which has to do with the
language in the CPPA spec related to the
BusinessProcessCharacteristics/confidentiality attribute in the
DeliveryChannel. The spec currently says:
"If
the value is "true" then it indicates that the delivery channel REQUIRES that
the Message be encrypted in a
persistent manner. It MUST be encrypted above the level of the transport and
delivered, encrypted, to the application".
Marty suggests
that by "delivered, encrypted, to the application" we mean persisted in
an encrypted form for subsequent processing by something other than the MSH
(at least I think that's what he said). The MSG spec allows the MSH to provide
message-level encryption, but does not require it (at least, not until XML
Encryption is available):
"Confidentiality for ebXML Payloads MAY be
provided by functionality possessed by a MSH. However, this specification states
that it is not the responsibility of the MSH to provide security for the ebXML
Payloads."
It seems,
then, that the CPP/CPA need to
support message-level encryption both at the MSH and the application
level. Currently, the confidentiality attribute is in the
BusinessProcessCharacteristics element; I propose that we add another
confidentiality attribute to the MessagingCharacteristics element. The
possible combinations of these two attributes in a DeliveryChannel would
be:
BPC/confidentiality=False,
MC/confidentiality=False: Message encryption will not be used at all. This
would typically be the case if the Delivery Channel uses a secure
transport.
BPC/confidentiality=True,
MC/confidentiality=False: Message encryption
will be provided by the application. On the sending side, this means that the
the MSH will not encrypt. On the receiving side, it means the MSH
will not decrypt.
BPC/confidentiality=False,
MC/confidentiality=True:
Message encryption will be provided by the MSH. On the sending side, this
means that the MSH will encrypt the message. On the receivning side, it
means that the MSH will decrypt the message.
BPC/confidentiality=True,
MC/confidentiality=True: The message will be encrypted by the app and
the MSH. On the sending side, this means that the app will encrypt the
message, and the MSH will encrypt it again. On the receiving side, it means
that the MSH will decrypt the message once, and the app will decrypt it again.
This is sort of a degenerate case that we might want to *advise* against,
though I don't think there's any reason to disallow
it.
Now, what happens
if the parties' confidentiality settings don't match (e.g., sender has
BPC/confidentiality=True, MC/confidentiality=False, and receiver has
BPC/confidentiality=False, MC/confidentiality=True)? I think that as long as
the number of times the message is encrypted by the sender (once, twice, or
not at all) is the same as the number of times it is decrypted by the
receiver, everything should work. I can easily imagine a sender encrypting
with his application and a receiver decrypting with his MSH. To make things
simple, however, maybe we should just say that the confidentiality settings of
both parties must match exactly. Does anyone have any thoughts on
this?
Peter