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

[Dale Moberg <dmoberg@cyclonecommerce.com>]

<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