Re: [ebxml-cppa] Proposal: Application encryption versus MSH encryption

[Tony Weida <rweida@hotmail.com>]

Peter,

 

This is a very good proposal.  Two confidentiality attributes -- one for the application level and another for the messaging level -- would allow parties to agree more clearly and precisely about where encryption / decryption gets done.

 

I think it's fine to allow agreement in any of the cases where the number of encryptions on the sending side is equal to the number of decryptions on the receiving side.  It's also important for both parties to understand what they're agreeing on, so helpful CPA authoring software might well warn and seek confirmation in cases where the sender encrypts only at the application (messaging) level and the receiver decrypts only at the messaging (application) level.

 

Tony 

----- Original Message -----

From: Peter Ogden

To: 'ebXML-CPPA'

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