RE: Security - coordination with MSH issues (1 general remark and 1 ontransport encryption )

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Tim>>  Please add to the list and when we get close to
the Oct F2F, and it is filled in, I would like to send it to the MSH
team.

OK, that sounds like a good plan. I will start with some additions
below.

Tim>>	One of the biggest things, I think, is to make sure that what
gets
worked on in V1.1 in both MSH and CPPA is consistent.  It would be bad
if
one adds something that is not supported by the other.

I believe that there is a little asymmetry here. The MSH may be
normatively
neutral on, for example, digital enveloping. However, we may wish to
explain
how two collaboration participants can agree upon using some known form
of
digital enveloping (for example, using application/pkcs7-mime and so
forth).

While we want to be certain that we cover CPAs that reflect
all ebXML MSG normative features (mandatory or endorsed or mentioned as
options)
we also want to start laying the groundwork for interoperable extensions
or 
restrictions or modifications of the MSG spec. This reflects the very
high
probability that ebXML MSG functionality could be only part of the total
functionality of deployed software modules providing secure transport
for
b2b data, and that actual CPAs may blend MSG features with other
mutually agreed
upon features. 

Under:
Issue-  Define how encryption works.

One factor in using SSL/TLS I have noticed can cause interoperability
problems
is the insistence of one side on high security (128 bits), and a refusal
to
negotiate down in the handshake. For some of the other parameters you
mention,
for many of these, negotiation in real implementations seems to be
fairly
automatic. I guess one question I have in this area is whether and why
we need to
include agreements on parameters that the SSL handshake process should
itself
negotiate? Is this for some site that has very restrictive policies over
what SSL/TLS options are negotiated? Our working assumption has been
that we
would need to document all those parameters that would need to be agreed
upon
to permit interoperability (at the transport security level). We can
extend
that to embrace parameters that need to be agreed upon because of policy
restrictions. But we would not document values for parameters that are
not
really enduser configurable...