[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa] **VOTE** BPSS/CPPA issue - #21 (old)
I think this terminology adjustment makes the BPSS options align better with the security policy distinctions in Ralph B's Appendix in ebMS. Also the distinctions seem to be ones that reflect typical business concerns with security, and leave the mechanisms whereby these business policies are obtained open to implementation agreement, working within the capabilities of the systems that will interoperate. I still think we have a ways to go before we have a fully adequate way to represent security policy components, and ordering of their strengths, that would permit automated reasoning about security policy acceptability. Maybe 2.0. In practice, those capabilities may force a downgrade in what is actually agreed to-- for example, maybe data confidentiality can only be interorperably realized on the transient SSL basis. Nevertheless, since these values are to indicate what is strongly recommended for a BP, the Ferris semantic of saying "at least as strong as" seems reasonable to me. Whether the spec mentions it or not, people will still implement the best they can do, even if it falls short of the mandated policy. And this may even be reasonable, based on their threat and potential harm assessments. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Thursday, December 13, 2001 8:53 PM To: David Smiley Cc: ebTWG-BPS; ebXML-CPPA Subject: Re: [ebxml-cppa] **VOTE** BPSS/CPPA issue - #21 (old) I abstain on this proposal. Reason for abstention: I would prefer a proposal that allows the pair of partners to downgrade or turn off security as well as to update the level of security. 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 ************************************************************************ ************* David Smiley <dsmiley@mercator.com> on 12/13/2001 10:26:04 AM To: ebTWG-BPS <ebtwg-bps@lists.ebtwg.org>, ebXML-CPPA <ebxml-cppa@lists.oasis-open.org> cc: Subject: [ebxml-cppa] **VOTE** BPSS/CPPA issue - #21 (old) No substantive responses have been received that require modifying the proposed change to the specification. Your vote is needed. **Do you agree with the proposed change?** FYI, Once approved, the resolution goes into the BPSS Issues Log (Pallavi). Then, an editor will be assigned to make the changes to the spec prescribed by the resolution. *************************************************************Old/New issue: Old Re-numbered for V1.1: 21 Number: 57 Date: 4/4 Originator: Christopher Ferris Line: Lines 1081-1100 Issue: I am still quite uncomfortable with this scheme. It does not permit a degree of flexibility that allows for a combination of persistent and transient security mechanisms. For instance, use of a persistent digital signature over the contents of the message (or on selected parts) to provide for authentication as well as integrity combined with a transient encryption of the message on the wire. Having "isSecureTransport" qualify the security characteristics of the Document Flow is IMHO, a poor design. I would much prefer that isConfidential, isAuthenticated and isTamperProof have the enumeration of "persistent", "transient" and "none" (default) such that valid combinations of security mechanisms might be applied. Suggestion for Change to BPSS Spec: For isConfidential, isAuthenticated and isTamperProof, change the type from boolean to enumerated value. Make the list of possible values be "persistent", "transient", "persistent-and-transient", "none" with the default being "none". The value of the attribute, if other than "none" could be interpreted as "at least <value>". Thus, if the value were "transient" it would be interpreted as "at least transient" which could mean that the parties might choose to adopt a persistent form of the appropriate countermeasure if they were more paranoid than the authors of the process. A value of "persistent" would be interpreted as "at least persistent" which could be augmented with transient countermeasures (e.g. a digitally signed message carried over a bilaterally authenticated SSL connection). Issue Comments: Background material: Some comments were posted against V0.99 http://www.ebxml.org/project_teams/jdt/ts/SpecificationSchemaV0.99.pdf. The current draft being revised is V1.01 http://www.ebxml.org/specs/ebBPSS.pdf or http://www.ebxml.org/specs/ebBPSS.doc. David Smiley Director of Standards Mercator Software 540.338.3355 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC