RE: Security - summary of issues and allocation to versions

["Collier, Timothy R" <timothy.r.collier@intel.com>]

Thanks for your speedy comments.  Replies inline.<tc> </tc>

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Monday, August 27, 2001 11:09 AM
To: Collier, Timothy R
Cc: ebxml-cppa@lists.oasis-open.org
Subject: Re: Security - summary of issues and allocation to versions



Tim,

In general I agree with your list of things we need to decide about.

I have a few comments:

V 1.1 Work Items

2. Clarification of namespace supported:  Regarding independence of the
specs, the CPP-CPA spec should contain what is needed to configure  the MSH
when the CPA is used.  In other words, the CPP/CPA should be consistent
with MSG in all elements and attributes. For the case where the CPA is not
used, it is the MSG team's responsibility to specify the choices for items
that are normally specified in the CPA.

<tc> I thought the last email in this thread seemed to indicate that
changing the example to use S/MIME instead of DSig would be useful.  </tc>

6. Lack of processing rules:  It isn't clear whether this topic is
suggesting things needed in the CPA or calling attention to MS Spec
deficiencies.

<tc> Yes this came from the MSH section of the security analysis doc, and
relates MSH and SOAP.  I thought it was relevant to CPP/A because, we have a
similar problem with the specification of signing and encryption ordering
and if the application is to do it, or if the application expects something
beneath it, in the run time stack, to do it for it.  If we develop a means
for expressing the ordering and responsibility of the layers, it could be
useful for both MSH+SOAP and CPP+MSH.</tc> 

7. Key Management:  I believe that key management is too large an issue for
V. 1.1.

<tc> I thought this might be closely related to the processing rules.  If I
require the MSH to apply the signature instead of the application, then we
need to provide a means for the MSH to get to the keys to be used.  There
are probably many more key management issues, but for this one I thought
that if we have processing order in v1.1, we need to have answer for this
piece.  I don't know if this is doable in v1.1 or not </tc>

8. "Encouragement" of selected protocols:  Is it your intention to add all
these points to the CPP-CPA spec as non-normative recommendations?

<tc> This is from the security analysis doc, and yes I was thinking some
non-normative recommendation would be included.</tc>


V 2.0 Issues

4.2 Super schema for CPP+CPA:  We already have a single schema that defines
both CPP and CPA.  Therefore I don't understand what you are proposing.

<tc> This is from the analysis.  Maybe it has been addressed already, I was
not sure of what was asked for myself, so I included it.</tc>


Regards,
Marty

****************************************************************************
*********

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
****************************************************************************
*********



"Collier, Timothy R" <timothy.r.collier@intel.com> on 08/27/2001 02:29:36
AM

To:   ebxml-cppa@lists.oasis-open.org
cc:
Subject:  Security - summary of issues and allocation to versions



All,

     I have attempted to consolidate Martys' changes doc, the security
analysis doc, and issues raised in emails from Arvola.  The text is cut
from
the corresponding source doc.  It also suggests my thoughts on where they
might go in the upcoming versions.  How these were allocated- if it "fixes"
something that was in v1.0, then I put it into v1.1; if it was clearly
"new"
functionality, then I put it into v2.0; if it wasn't neither of the above,
then it is in v???.  A couple of the big issues, for v1.1, we need to agree
to -

1) Are profiles and policies something for v1.1?
2) Can we resolve with MSH and BPSS the issue of message "nonrepudiation"?


Please take the attached document as a starting point for discussion.


     Tim







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