RE: [ebxml-msg] Encryption/Encapsulation

[David Fischer <david@drummondgroup.com>]

Arvola,

Why would an decryption key be tied to a service?  It could be tied to the
From/CPAId I suppose  The same service might be used by many parties.  In any
case, when I encrypt something for you then I use your Public-key which means it
is YOUR key which does the decryption.

Which headers are used should be implementation specific.  This is just another
message to be constructed by the MSH.  I would think you MUST have a
MessageHeader (From/To/MessageData/CPAId etc.) and a Manifest (with a single
reference).  You could have other headers like AckRequested.  I think we should
not dictate which headers.  This message should be constructed as any other.  I
only point out that it is not necessary to recraft all the headers since many
(especially MessageHeader) can simply be copied from the original with a change
in Service/Action.  In the case of encryption, even the MessageId could remain
the same -- although maybe/maybe-not in other cases like adding a payload.  We
would need to think about the possibilities?

Regards,

David Fischer.

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Monday, November 12, 2001 10:59 AM
To: David Fischer; ebXML Msg
Subject: Re: [ebxml-msg] Encryption/Encapsulation


David:

Can you please clarify what header elements, if present in the message being
encapsulated, need to be copied to the encapsulating message?

Also, if the purpose of the encapsulation is to have both the header
container and the payload container(s) of the original message encrypted,
are you assuming that all such encrypted messages destined for one PartyId
would be encrypted using the same encryption key and algorithm? Otherwise,
how can the encapsulated messages be properly decrypted by the same Service
(uri:www.oasis-open.org/messageService/)?

If the purpose of encapsulation is to send fragments of a large message as
multiple encapsulated messages, then the Receiving MSH must recombine the
fragments into the original message before "reprocessing it as a new
message".

Regards,
-Arvola
  -----Original Message-----
  From: David Fischer <david@drummondgroup.com>
  To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
  Date: Sunday, November 11, 2001 9:03 AM
  Subject: [ebxml-msg] Encryption/Encapsulation


  We put off items 16, 50, & 97 because of backward compatibility.  Since
that is no longer an issue, I would like to propose the following section
addition.

  Regards,

  David Fischer
  Drummond Group

  ------------------------------------
  12                  Encapsulation
  Some implementations may require that ebXML messages be Encapsulated into
the payload of another ebXML message in a recursive fashion.  This might be
needed for encrypting a message where the headers need to be included in the
encryption with the payloads.  This might be useful when an intermediary
node needs to add a payload to an existing message without disturbing a
signature.  This might also be used to break very large messages, or
messages with large numbers of payloads, into smaller pieces for
transmission (how this is done is outside the scope of this specification).
These examples highlight some possible uses for Encapsulation but do not
encompass all possible uses.

  When the Encapsulation process is applied, the MSH shall put the original
message with the normal Multipart/Related content-type, as the payload of
another ebXML message.  If required, this Multipart/Related MIME structure
may be encrypted using an approved encryption process (XMLEncryption,
S/MIME, etc.).  A minimal set of headers shall be constructed, or copied
from the original message, for this message with:

  ·      a Service element set to uri:www.oasis-open.org/messageService/

  ·      an Action element set to Encapsulate

  These settings are NOT REQUIRED if the Receiving MSH can understand other
settings and correctly process the Encapsulated message.

  When the Receiving MSH parses this message, the Encapsulated payload
should be reprocessed as a new message, after decryption as necessary.



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