[ebxml-cppa] **VOTE** BPSS/CPPA issue - #21 (old)

[David Smiley <dsmiley@mercator.com>]

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