OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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



Arvola,

I agree with your second paragraph.  Leave isConfidential for the business
process attributes and add a new one with a different name in the messaging
attributes.

We already changed confidentiality to isConfidential.

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
*************************************************************************************



"Arvola Chan" <arvola@tibco.com> on 01/27/2002 12:13:17 PM

To:    Martin W Sachs/Watson/IBM@IBMUS, <pogden@cyclonecommerce.com>
cc:    "'ebXML-CPPA'" <ebxml-cppa@lists.oasis-open.org>
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