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

["Himagiri(Hima) Mukkamala" <himagiri@sybase.com>]

Peter and all,

Application and MSH might perform encryption in different formats.
We should clearly convey who's performing the encryption and what's being
used to do it.

Right now we have SenderDigitalEnvelope and ReceiverDigitalEnvelope.
If the assumption is that, if the new flag you are proposing for MSH level
encryption is set, the information under these elements may be used
to MSH level encryption, what would be used to perform application
level encryption?

We only have a top level applicationcertRef and is over the whole PartyInfo.
This would mean that all the Applications would have to use this certificate
for encryption at application level.

Right now packaging is the place where each of the mime-parts are listed
out individually. Application level encryption has to be dealt at this level
cause
it may or maynot happen with all the parts being sent as part of the message

-hima

Arvola Chan wrote:

> 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>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>