Re: [ebxml-cppa] Persistent/Transient Definitions from BPSS ProjectTeam

[Pete Wenzel <pete@seebeyond.com>]

I think you're right on.  Here are the simple explanations I use:

"Data persistence" has to do with storage; the intent is for the
message to remain even after a system crash.  This comes from
requirements of Reliable Messaging and/or Nonrepudiation.

"Persistent security" means that the security mechanisms remain in
place after the message emerges from transport (and is not necessarily
then persisted to a storage medium, unless required by RM or Nonrep.).

The two definitions are orthogonal, and the relevant CPP/A parameters
correctly maintain this independence.  "isConfidential",
"isAuthenticated" and "isTamperProof" refer only to the latter sense
of persistence.

Therefore, I would like to strike any reference to data storage in the
definitions of these security mechanisms.  Further, I hypothesize that
persistent confidentiality will most often not be a requirement of the
business process, but of the environment.  That is, the use of
persistent confidentiality would be agreed upon when an untrusted
intermediary is involved, or when a party decides that he does not
want the data exposed in his DMZ, or when the transport binding is
SMTP... none of which are situations expressed by the process
definition, but which are covered by the CPP/A.

[Side note: "isTamperProof" is a misnomer; it should really be called
"isTamperEvident".  You cannot absolutely prevent a message from being
tampered with, but you can detect and reject such attempts.]

--Pete

Thus spoke Engkee Kwang (ekwang@vitria.com) on Wed, Mar 13, 2002 at 10:01:11AM -0800:
> I can appreciate the desire to keep the CPPA definitions
> "implementation" neutral pending binding but it is not clear
> how the current definitions will be "implemented"...
> 
> Specifically wrt. the relationship between an implementation
> form, eg. S/MIME and the requirements of "persistent vs. transient
> confidentiality"
> 
> Transient confidentiality seemed clear. when the message is in
> transit, it is protected from unwanted eavesdropping. Once the
> message pops out of the transport layer, it is plain-text.
> 
> To an extent, i would think that "persistent confidentiality"
> is intended to preserve the confidentiality of the message
> such that only the intended party (application, person, etc)
> can see it. That means that the message will remain in encrypted
> form even after it is delivered and will be decrypted by the
> authorized application/service/person as needed. S/MIME can be
> used to provide that functionality, independent of the transport
> or transient confidentiality.
> 
> The current definition...
> 
> * Persistent confidentiality - the receiver shall maintain a
>   copy of the encrypted item (e.g. document)
> 
> sound more like a non-repudiation requirement.
> 
> If we view the protocol stack as something like this...
> 
>         ---> [MSH] ---> [BPI/Middleware] ---> [PrivateProcess]
> 
> then we can map the confidentiality requirements are...
> 
>         ---> [MSH] ---> [BPI/Middleware] ---> [PrivateProcess]
> 
> ---transient-->|
> 
> ---------------persistent----------------->|
> 
> 
> It would seem to me that the "persistent" qualifier on confidentiality
> applies _not_ to any requirements for physical storage but rather to
> the confidentiality of the message in the ether _between_ the transport
> layer and the private process.
> 
> 
> 
> 
> > -----Original Message-----
> > From: Hayes, Brian [mailto:Brian.Hayes@Commerceone.com]
> > Sent: Tuesday, March 12, 2002 4:44 PM
> > To: ebxml-cppa@lists.oasis-open.org
> > Subject: [ebxml-cppa] Persistent/Transient Definitions from 
> > BPSS Project
> > Team
> > 
> > 
> > FYI.
> > 
> > -----Original Message-----
> > From: Buchinski.Ed@tbs-sct.gc.ca [mailto:Buchinski.Ed@tbs-sct.gc.ca]
> > Sent: Thursday, March 07, 2002 11:55 AM
> > To: Brian.Hayes@Commerceone.com; pallavi.g.malu@intel.com
> > Subject: RE: Persistent/Transient Definitions
> > 
> > 
> > Brain & Pallavi,
> > 
> > 	I have reviewed the definitions that you provided and 
> > would suggest
> > that these remain as is.  In addition I spoke with a 
> > collegue, Rick, who
> > lives and breaths "security".  We didn't have enough time to 
> > review the
> > various aspects of the ebXML (i.e. messaging, business 
> > process and CPP).
> > Recognizing the time constraints and the fact that everyone 
> > on my floor is
> > packing their office so that we can be in a new location on 
> > Monday following
> > is some more input.
> > 
> > Rick suggested that we base all definitions on the standards 
> > definitions
> > available out there, we must not have a new version (the ones in the
> > security arena rather than ebXML with which he is 
> > unfamiliar).  Getting back
> > to the need to refine "persistent" and "transient""
> > * "Persistent" services means basically a service from originator to
> > destination and for as long as that business process needs it. 
> > * Any "transitory" service means they are applied as needed 
> > between two
> > points, and not necessarily end-to-end.
> > There is also work in the IETF and ETSI space to look at the 
> > Non-repudiation
> > and persistency of security services.  Rick couldn't come up with a
> > reference on short notice.  It is not clear that these were 
> > referenced in
> > the normative references in ebMSH.
> > 
> > For your information, the persistent aspect relates to 
> > information retention
> > and management.  Attached is a drfat guidance document that 
> > our security
> > folks have just drafted.  If you are so inclined your inputs 
> > would be much
> > appreciated.
> > 	
> > 
> > 
> > 
> >  -----Original Message-----
> > From: 	Hayes, Brian [mailto:Brian.Hayes@Commerceone.com] 
> > Sent:	March 1, 2002 3:37 PM
> > To:	'Malu, Pallavi G'; Ed Buchinski (E-mail)
> > Subject:	RE: Persistent/Transient Definitions
> > 
> > Ed, see emails below.
> > 
> > Pallavi & Ed - I think it would be sufficient to email the 
> > definitions to
> > the CPPA team and put Ed's email address on the To: line.  Ed 
> > - could you be
> > the BPSS coordinator/point-of-contact on this?
> > 
> > Brian
> > > -----Original Message-----
> > > From: Malu, Pallavi G [mailto:pallavi.g.malu@intel.com]
> > > Sent: Friday, March 01, 2002 9:26 AM
> > > To: 'Hayes, Brian'
> > > Subject: RE: Persistent/Transient Definitions
> > > 
> > > 
> > > These are the definitions we agreed to at the F2F. If there 
> > > is going to be
> > > any discussion in the CPPA team on this, I think we should 
> > involve ED
> > > Buchinski.
> > > 
> > > -Pallavi
> > > 
> > > -----Original Message-----
> > > From: Hayes, Brian [mailto:Brian.Hayes@Commerceone.com]
> > > Sent: Friday, March 01, 2002 10:05 AM
> > > To: Pallavi Malu (E-mail)
> > > Subject: Persistent/Transient Definitions
> > > 
> > > 
> > > In todays CPPA meeting, the BPSS team has been asked to send out its
> > > definition for persistent confidentiality.  From the notes I 
> > > sent you, do
> > > you have any changes?  It appears that there may be an 
> > > definition issue with
> > > the BPSS persistent confidentiality and Messaging's definition.
> > > 
> > > *	For non-repudiation, the message/document shall be persistently
> > > stored by the receiver (and optionally be the sender).  
> > > Issues associated
> > > with security key expiration dates and notarization, secure 
> > > storage, tamper
> > > resistance/detection is outside of the scope of this document (BPSS
> > > specification).
> > > *	Persistent authentication means you shall keep the 
> > > digital signature
> > > associate with the document.
> > > *	Transient authentication means you can discard the 
> > > digital signature
> > > after you receive the document
> > > *	Persistent confidentiality - the receiver shall 
> > > maintain a copy of
> > > the encrypted item (e.g. document)
> > > *	Transient confidentialty is transport level encryption 
> > > - encryption
> > > is during the transfer process (e.g. SSL).
> > > *	Transient isTamperPoof is the ability to detect if the 
> > > information
> > > has been tampered with during transfer. 
> > > *	Persistent isTamperProof is the ability to detect if 
> > > the information
> > > has been tampered after it has been stored by the receiving 
> > > application.
> > > 
> > > Brian Hayes
> > > Commerce One Labs
> > > 
> > 
> > ----------------------------------------------------------------
> > 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>