RE: Scope of MSH and CPPA RE: S/MIME <CPPA Security Team>

[David Fischer <david@drummondgroup.com>]

Thanks Dale,

I like the idea of a "helper app" to the MSH.  That is how I envision it.  The
MSH would call the decrypt module and then receive the Payload back (or an
error).

The problem with the Manifest is that after decryption there will/could be many
bodyparts (in DBs example of a 747 CAD there would be 1000s) and in order for
the MSH to properly pass those bodyparts to the application it will need to
build a set of eb:Manifest compliant References.  Even better, this new Manifest
might be provided in a (1st)bodypart included as part of the SMIME payload.

How much good is encryption if a snooper can tell what kind of a message this is
based upon Service/Action which is not encrypted?  Someone could go through and
pick out all the encrypted POs for example and not have to mess with the noise.
We could put the real Service/Action in the bodypart with the real Manifest?
OTOH,  I suppose maybe today's encryption is strong enough not to worry about
this?

Thanks,

David Fischer
Drummond Group.

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Friday, August 17, 2001 12:50 PM
To: David Fischer; Dan Weinreb
Cc: ebxml-msg@lists.oasis-open.org; ebxml-cppa@lists.oasis-open.org
Subject: Scope of MSH and CPPA RE: S/MIME <CPPA Security Team>




<DavidFischer says="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?
" />

David,

I think it is up to MSG to decide on its scope of requirements
and its selected implmentation mechansism(s) to attain them.
I suspect the selected mechanisms will be a subset of the
available mechanisms, so CPPA will be stuck with dealing with
those collaborators who want something in addition to or instead
of what is in the spec...

Now, I seem to remember that the reason for your point 3 was
that there was a skirmish about PGP and SMIME and XMLDsig at one
point, and a cease fire was declared in which XMLDsig was
anointed as the signature method of choice. Because XML Encryption
was not ready, data confidentiality via a digital enveloping
technique was left to the future.

<DavidFischer says=" 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?"/>

I did not mean to make that implication.
I envision the situation to be like this:
_Some_ applications -- we had direct requirements
from the financial verticals--
would like to both sign and envelope data and
supply that packet to the MSH layer.
_Other_ applications might want to "outsource"
that functionality to a MSH or other
willing chunk of code. A MSH
(containing a superset of ebXML functionality)
could have the capability (advertized in its CPP )
to provide that service for the app.
You could even think of this part of the
MSH as a "helper app" for the real app
(or even think of it as
just some other piece of middleware)

The ambiguity here is the familiar one:
Absent a BSI interface, we do not have a sharp
line that allows clean modular
component-style separation of MSH and Application.
MSH fades into a mushy middleware
ecosystem of various middleware flora and
fauna, and then somewhere the app starts.
I think the component lines here will eventually
need to be drawn, but at present
they are shifting daily.

I am not sure I follow why the manifest will be a problem though. If the
payload comes in as application/pkcs7-mime, then that is its manifest
relevant identity as far as the ebxml MSH needs to know, right?
Need to elaborate this problem a bit more for me to see your concern.

Dale Mober

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