[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] Proposal: Application encryption versus MSH encryption
Peter: In the BPSS 1.02 draft, isConfidential is no longer a boolean attribute. Instead, it now accepts the enumerated values "none", "persistent", "transient", "persistent-and-transient". Wherease persistent encryption can be applied either at the application level or at the MSH level. Transient encryption can only be achieved at the MSH level (through the use of secure transport). Since we have agreed that we should be aligned with the BPSS spec with respect to the naming of attributes, we should rename "confidentiality" as "isConfidential". I would prefer not to have two "isConfidential" attribute both under BusinessProcessCharacteristics and MessagingCharacteristics each allowing the above four enumerated values. Would it make sense to leave the "isConfidential" attribute under BusinessProcessCharacteristics and perhaps add another sibling boolean attribute "applicationLevelEncryption" to indicate if encryption must be performed at the application (as opposed to the MSH) level, to avoid the awkward possibility of encryption occuring both at the application and at the MSH level. Anyway, the SenderDigitalEnvelope and ReceiverDigitalEnvelope element can carry only one set of key/algorithm/security details information. It doesn't make too much sense to me to use the same parameters to perform both application and MSH level encryption for the same message. In general, I agree with both you and Marty that it would be simpler to require that the confidentiality settings of both parties must match exactly. Regards, -Arvola ----- Original Message ----- From: "Martin W Sachs" <mwsachs@us.ibm.com> To: <pogden@cyclonecommerce.com> Cc: "'ebXML-CPPA'" <ebxml-cppa@lists.oasis-open.org> Sent: Sunday, January 27, 2002 1:04 AM Subject: Re: [ebxml-cppa] Proposal: Application encryption versus MSH encryption Peter, Some responses below. Regards, Marty **************************************************************************** ********* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com **************************************************************************** ********* Peter Ogden <pogden@cyclonecommerce.com> on 01/25/2002 06:57:05 PM Please respond to pogden@cyclonecommerce.com To: "'ebXML-CPPA'" <ebxml-cppa@lists.oasis-open.org> cc: 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." MWS: Let's be careful. isConfidential refers to application-level encryption/decryption. Any encryption functionality possessed by an MSH is for message-level encryption/decryption. The MSH code load might include a capability of performing encryption on behalf of the application for application-level encryption/decryption but that functionality is outside the scope of the defined MSH. 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)? MWS: If the two parties' confidenools and should be detected. The CPA composition appendix points out that some mismatches are allowable (a "good enough" CPA) and that's fine but the condition should be detected and flagged. 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. MWS: If the receiving MSH decrypts, it violates the intent of the sender encrypting ata the application level. 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? MWS: I totally agree. Peter ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC