OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-messaging message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Let's get to work



Let's have a conference call early next week. I'll try to get it set up.

James

> -----Original Message-----
> From: Hatem ElSebaaly [mailto:hatem@ipnetsolutions.com]
> Sent: Thursday, June 07, 2001 7:14 PM
> To: 'Peter Furniss '; 'bt-messaging@lists.oasis-open.org '
> Subject: RE: Let's get to work
> 
> 
> Peter,
> 
> Actually the point I am trying to make is that, we need to 
> make sure that
> extracting "only" the BTP part of the message is not expensive. It may
> actually not be an issue.
> 
> How do you see us proceeding in order to make progress on defining the
> concrete messages? F2F? Conference Calls?
> 
> Thanks
> Hatem
> 
> -----Original Message-----
> From: Peter Furniss
> To: bt-messaging@lists.oasis-open.org
> Sent: 6/6/01 7:29 PM
> Subject: RE: Let's get to work
> 
> Hatem sent
> 
> (pruned to the paragraph I'm asking about)
> 
> > 2) With regards to whether or not the BTP message is carried in the
> header
> > or the payload, I think we should resolve this issue soon since it
> will
> > impact the format of the message. Of course placing the 
> message in the
> > payload would be less invasive to the carrier protocol, but it
> > would impose
> > a heavy processing price if the message is digitally signed.
> 
> I don't understand the last part. If BTP is used with application
> messages
> that are signed, the BTP messages themselves need to be secured to at
> least
> the same trust level. An attacker able to fake BTP messages 
> can subvert
> the
> authentication of the application, so they would need to be 
> in the same
> secured part of the total message.
> 
> Or is the point to do with re-processing of payload, but not 
> headers, as
> the
> combination is passed along ?
> 
> 
> But we do need to sort out the general BTP message : header / payload
> relationship anyway.  We're trying to sort out the implications and
> options
> arising from the combined message (nee box-carring) decisions. (or
> recommendations, from Tuesday's meeting)
> 
> Peter
> 
> ------------------------------------------
> Peter Furniss
> Technical Director, Choreology Ltd
> email:  peter.furniss@choreology.com
> phone:  +44 20 7670 1679
> direct: +44 20 7670 1783
> mobile: 07951 536168
> 13 Austin Friars, London EC2N 2JX
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC