RE: [ebxml-cppa] isConfidential

[Dale Moberg <dmoberg@cyclonecommerce.com>]

MSG TC currently has little 
specified about digital enveloping,
which is what we are discussing
under persistent confidentiality.
Mostly digital enveloping specs were
deferred until XML Encryption
became a standard (now a canditate
rec, btw.) So _anything_ we specify
in the area of digital
enveloping is beyond 
ebXML 2.0 MSH behavior, IMO.

I do not disagree with your opinion
about the peculiarity of the
analysis of "isConfidential"
as involving "saving a copy"
of the message.

However, we have so far made some effort
to retain both the terminology and
the semantics (as far as we can discern it)
of the BPSS and its underlying UMM. 

There does not seem at present a way
to arbitrate disputes about content of
the UMM. I think this is unfortunate.

At present, we either try to straighten
this analysis out, ignore it, or try
to maintain some degree of alignment with it.

We have already spent portions of two
recent conference calls trying to arrive
at some compromise language. 

I prefer language that emphasizes the clause:

 "made available to the
 application in accordance 
 with local security policies
 implemented to preserve confidentiality."

I personally would be happy to stop there;
and if that local policy included 
storing it to disk-- fine, it is covered
under the above clause.  

Comments?

Dale

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Monday, March 11, 2002 2:01 PM
To: Dale Moberg
Cc: Tony Weida; CPPA
Subject: Re: [ebxml-cppa] isConfidential


Dale,

Involving storage media as a requirement to satisfy
'isConfidential='persistent' would complicate matters
greatly with regards to an implementation. It would
effectively amount to a change of the required behavior of
an MSH beyond what the MSG TC has currently specified
in v2.0c.

*IF* the message is written to persistent storage media,
then clearly, it is true that it MUST be done in such a
way that the confidentiality is preserved.

I would think that the analysis is flawed (no offense
intended!). I can easily conceive of a requirement that
NO persistent storage be used (this message will self-destruct
in five seconds) so as to further ensure that confidentiality is not
compromised after-the-fact.

Cheers,

Chris

Dale Moberg wrote:

> We just added the part about persisted locally
> because Brian Hayes and Pallavi Malu (who
> are on BPSS and CPPA) advised us that this
> language was to be in their new BPSS document,
> and that it was there because of the UMM analsis.
> 
> Does anyone know the chapter and verse
> from the UMM for this "analysis" of
> isConfidential? 
> 
> We have been relying
> on Brian and Pallavi since they are
> involved in both sides. 
> 
> We are aware that Messaging
> had been the source of the "transient" vs
> "persistent" distinctions. 
> 
> The current issue has been one
> where we have ended up saying
> something definite, albeit vague, about the
> local programmatic behavior. We did
> not say what kind of hard drive you
> had to use, however:-)
> 
> 
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: Monday, March 11, 2002 1:32 PM
> To: Dale Moberg
> Cc: Tony Weida; CPPA
> Subject: Re: [ebxml-cppa] isConfidential
> 
> 
> Hmmm... then you'd better get some clarification.
> That wasn't what I was given to understand. Basically,
> the notions of persistent vs transient confidentiality, etc.
> were raised by me, not originating from BPSS. They
> had originally had just a boolean which could have
> been interpreted sixteen ways to sunday. Before that,
> they were implying specific technology solutions in
> their characterization which was also felt to be
> inappropriate as this is the realm not of the model, but
> of the agreement between parties and the common capabilities
> of their respective solutions.
> 
> Cheers,
> 
> Chris
> 
> Dale Moberg wrote:
> 
> 
>>Also, persistence, or the idea that "a copy was to be
>>saved," was part of
>>the BPSS clarification 
>>of what isConfidential was to
>>mean. 
>>
>>Probably from the UMM, somewhere.
>>
>>Dale
>>
>>-----Original Message-----
>>From: Tony Weida [mailto:rweida@hotmail.com]
>>Sent: Monday, March 11, 2002 12:20 PM
>>To: Christopher Ferris
>>Cc: CPPA
>>Subject: Re: [ebxml-cppa] isConfidential
>>
>>
>>The isConfidential attribute has four potential values: "none",
>>"transient",
>>"persistent", and "transient-and-persistent".  The cited text applies
>>
> to
> 
>>the
>>persistent cases.  Sorry for omitting the qualification.  THe
>>
> motivation
> 
>>is
>>to address the case of confidential exchange between applications, not
>>merely MSHs.
>>
>>----- Original Message -----
>>From: "Christopher Ferris" <chris.ferris@sun.com>
>>To: "Tony Weida" <rweida@hotmail.com>
>>Cc: "CPPA" <ebxml-cppa@lists.oasis-open.org>
>>Sent: Monday, March 11, 2002 2:09 PM
>>Subject: Re: [ebxml-cppa] isConfidential
>>
>>
>>
>>
>>>Why would persistence (I assume on some media) be a
>>>consideration? True, the confidentiality is "persistent",
>>>but persistent only to the degree that the feature is
>>>not a function of the transfer or transport mechanism
>>>but of the message itself.
>>>
>>>Tony Weida wrote:
>>>
>>>
>>>
>>>>Here's the text we arrived at during the last call to characterize
>>>>isConfidential:
>>>>
>>>>
>>>>
>>>>   "...persisted locally in encrypted form, and made available to
>>>>
>>>>
>>the
>>
>>
>>>>   application in accordance with local security policies
>>>>
>>>>
>>implemented
>>
>>
>>>>   to preserve confidentiality."
>>>>
>>>>
>>>>
>>>>Tony
>>>>
>>>>
>>>>
>>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
> 
> 
>