ebxml-cppa message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [ebxml-cppa] Proposal: Application encryption versus MSH encryption
- From: Peter Ogden <pogden@cyclonecommerce.com>
- To: 'ebXML-CPPA' <ebxml-cppa@lists.oasis-open.org>
- Date: Fri, 25 Jan 2002 16:57:05 -0700
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC