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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: RE: S/MIME


I wonder about this split where signatures are in but encryption is out?  How
can we dispatch the payload to the appropriate application until after we
decrypt and find out what the payload is?  This information may not be in the
Manifest.  I'm thinking this won't work.  Encryption/decryption needs to be
within the scope of the MSH.

1.  XMLdsig signing and verification are within the scope of the MSH.
2.  XMLencryption will be within the scope of the MSH.
3.  S/MIME payload encryption is not within the scope of the MSH?

I'm not sure we want to say encryption will be in our scope in the future but it
isn't now.  Is there something between the MSH and the Application which handles
security?  I'm not comfortable with the idea that each Application has to
include an encryption/decryption module.  Maybe you mean the security module
would be the application?

	MSH ==> Security Module ==> Dispatcher ==> Application Module

This could be messy if there are multiple parts in the Payload Container.  In
that case, the Manifest would have only a single Reference yet there might be
many (10s, 100s, 1000s) of attachments.

This is why I requested a more recursive approach where the Manifest was
correct, then encrypt the payload with SOAP:Envelope and put the result in a new
ebXML Payload.  The result of decryption would then be a new ebXML message, with
a correct Manifest, which could be resubmitted to the ebXML parser.


David Fischer
Drummond Group.

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Wednesday, August 15, 2001 12:36 PM
To: chris.ferris@east.sun.com; dmoberg@cyclonecommerce.com
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: S/MIME

   Date: Wed, 15 Aug 2001 09:09:57 -0400
   From: christopher ferris <chris.ferris@east.sun.com>

   The reference to S/MIME means that the payload, not the overall "envelope"
   can be S/MIME encrypted.

Oh, the payload.  I see.  Thanks.

   From: Dale Moberg <dmoberg@cyclonecommerce.com>:

   Until then, a MSH that embodies a superset of ebxml MSH functionality
   can follow the directives of a CPA (in its virtual form) which tells
   it how to securely package up its SOAP with attachments message.

Indeed, now that you mention it, the CPP/A Spec, at line 1807 in
section 7.7.4 in the description of the Encapsulation element,
explicitly mentions S/MIME as an example of what Encapsulation can
describe.  Great.

-- Dan

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