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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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

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

My general remark was more of a concern that the MSH team would add
functionality that we "should" support in our CPPA, but don't get around to
dealing with until a later version.  Case in point, I wonder what the impact
of the MSH supporting multicast has on the specification of security.  In
the multicast case, who is responsible for authentication, authorization,
..., what role does the application play?  Is it invisible to the app that
multicast is being used?  Is multicast just a network optimization?  Even
outside of security, who would be responsible for managing the multicast
subscribers?  Does that need to be described in the CPPA?

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Tuesday, August 28, 2001 9:08 AM
To: Collier, Timothy R; ebxml-cppa@lists.oasis-open.org
Subject: RE: Security - coordination with MSH issues (1 general remark
and 1 on transport encryption )

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

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

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

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

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

Issue-  Define how encryption works.

One factor in using SSL/TLS I have noticed can cause interoperability
is the insistence of one side on high security (128 bits), and a refusal
negotiate down in the handshake. For some of the other parameters you
for many of these, negotiation in real implementations seems to be
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
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
to permit interoperability (at the transport security level). We can
that to embrace parameters that need to be agreed upon because of policy
restrictions. But we would not document values for parameters that are
really enduser configurable...

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

Powered by eList eXpress LLC