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: [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