[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] Re: BPSS/CPPA issue - #21 (old)
David, On looking over the issue and comments, I am inclined to believe that Chris and I are fairly close except when it comes to upgrade/downgrade. Can we consider the following: Define the set of values as both Chris and I stated: "Make the list of possible values be "persistent", "transient", "persistent-and-transient", "none" with the default being "none"." No "implicit" upgrade/downgrade. Upgrade and downgrade of the security requirement can be accomplished by providing for overrides of the values in the CPA. isConfidential and isAuthenticated are already represented in the CPP-CPA Characteristics element (as confidentiality and authenticated). isTamperProof could be added. I suggest changing the CPPA spec Characteristics element such that the attributes that correspond to attributes in the BPSS specification have the same names and the text explicitly mentions that when a BPSS instance document is used, these attributes provide overrides for the attributes of the same names in the BPSS instance document. Also, the CPPA text will have to be changed to match the proposed changes to enumerated values. A related matter is this: Another possible problem is that if some of these attributes are per business transaction activity in the BPSS spec, it may be necessary to use Override delivery channels to allow treating these attributes differently for different business transaction activities. Regarding "how is it actually implemented": The "transient" aspect must be supported by specific security elements and attributes in the delivery channel. This is already stated (though maybe not clearly enough) in the text for the Characteristics element. Implementation of the "persistent" aspect, I think, involves higher level middleware and application function that is outside the scope of the MSG and CPPA specs. 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 01/04/2002 01:14:39 PM To: Martin W Sachs/Watson/IBM@IBMUS, "'Christopher Ferris'" <chris.ferris@sun.com> cc: "Brian Hayes (E-mail)" <Brian.Hayes@Commerceone.com>, "Pallavi Malu (E-mail)" <pallavi.g.malu@intel.com> Subject: BPSS/CPPA issue - #21 (old) Marty and Chris, We seem to have come to a stop in making progress on the resolution of this issue and it was discussed on the BPSS conference call today. Much of this is due to the ignorance of myself and others about the topic. Is there a clear "order of stringency" among these choices? What would the order be? If BPSS specifies it, how and where is it actually implemented? Are the implementation details obvious? Your help and advice are welcome. Thanks David Smiley **** 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). ***** Alternative possibility (Marty Sachs): 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". MWS: If it is possible to agree on order of increasing stringency, the values should probably be enumerated in that order for clarity. The value of the attribute, if other than "none", could be interpreted as "the default <value>". The parties are free to agree on more or less stringent security. Thus, if the value were "persistent" the parties might choose to adopt a persistent-and-transient form of the appropriate countermeasure if they were more paranoid than the authors of the process. A value of "persistent" could be augmented with transient countermeasures (e.g. a digitally signed message carried over a bilaterally authenticated SSL connection. Alternatively, they might agree on a value of "transient" if their security requirements are lower than is stated in the bPSS instance. ***** Issue Comments: 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. (Marty Sachs) Vote: For original proposal - Against original proposal - For alternative proposal - Against alternative proposal - Abstain from all - 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.ebtwg.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC