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

[Engkee Kwang <ekwang@vitria.com>]

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