[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] Another comment on the **VOTE** BPSS/CPPA issue - #21(old)
I am not certain that a vote on an amended
version is possible, but Marty prepared
the following amended version for #21
that I would prefer over
the current version.
Dale
====sent with permission=========================
Dale,
I assume you are wondering about how to change Chris' proposed language.
Chris proposal:
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:
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.
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
************************************************************************
*************
"Dale Moberg" <dmoberg@cyclonecommerce.com> on 12/14/2001 01:12:18 PM
To: Martin W Sachs/Watson/IBM@IBMUS
cc:
Subject: RE: [ebxml-cppa] **VOTE** BPSS/CPPA issue - #21 (old)
If BPSS has a normative statement on what they intend,
I still think in practice they will reach CPAs
with downgrades. So I agree with you. I guess
I just want them to realize that BPSS can specify
normatively as much as they want that it is upgrade
only, but CPAs will be formed that downgrade in practice.
I am not certain how to work all this in the
right normative language, though. That was my
dilemma. Maybe I should add something more?
Dale
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Friday, December 14, 2001 10:43 AM
To: Dale Moberg
Subject: RE: [ebxml-cppa] **VOTE** BPSS/CPPA issue - #21 (old)
PRIVATE
Dale,
You seem to agree with me that partners may agree to degrade security
relative to what the BPSS instance says (if that's the best they can do)
but you still seem to approve a normative statement that says that the
partners my upgrade security but not downgrade it. My preference would
be
for a normative statement that permits altering security in either
direction along with a non-normative recommendation that upgrading
should
always be preferred.
I realize that the time for argument is past and all that is expected
now
is a vote. However I am curious whether I read you right today.
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
************************************************************************
*************
"Dale Moberg" <dmoberg@cyclonecommerce.com> on 12/14/2001 11:45:39 AM
To: Martin W Sachs/Watson/IBM@IBMUS, "David Smiley"
<dsmiley@mercator.com>
cc: "ebTWG-BPS" <ebtwg-bps@lists.ebtwg.org>, "ebXML-CPPA"
<ebxml-cppa@lists.oasis-open.org>
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