RE: BTP security

[Bill Pope <bpope@bowstreet.com>]

Hi Jim,
Thanks for the comments.  I'm updating the document and will re-send.

more in-line below ...

=bill

> -----Original Message-----
> From: Jim Webber [mailto:jim.webber@arjuna.com]
> Sent: Tuesday, June 19, 2001 8:52 AM
> To: Bill Pope
> Cc: bt-security@lists.oasis-open.org
> Subject: Re: BTP security
> 
> 
> Bill:
> 
> Some thoughts on the security draft thus far:
> 
> (35) Trust. You say that trust is not a technological issue. 
> To some extent
> I agree with that, but for the purposes of running a BTP 
> transaction some
> pieces of technology somewhere must agree to trust 
> one-another. Now I am no
> expert on trust protocols, but to say that it is not a 
> technological issue
> seems overly strong. Perhaps "not solely a technological 
> issue" would be
> more apt?

Agreed, that is a bit strong.  I'm looking to emphasize that this group
will not be able to address the non-technological issues and so has to
accept the current status quo as the starting point.  I would like to
put the emphasis on pragmaticsm, while still meeting the security
requirements.
 
> (30) Reliable Message Delivery
> 
> I'm not sure that reliable message delivery is particular a high level
> security issue, particularly with something like BTP which runs on the
> Internet, you expect messages to be lost. I agree with your 
> later statment (45-47) that such issues will be addressed by the core 
> BTP protocol work (I suspect via timeouts and suchlike).

Right, it's included to be sure that it is addressed.  It's one of those
areas that has to be addressed in the initial protocol definition.  Then
later versions of the protocols address detecting when messages are 
disappearing on purpose.

It's important to realize that not all of the vendors are interested in 
using BTP over the Internet, more correctly not ONLY over the Internet.  
There are some, and I include myself, that are looking for messages,
protocol,
and interfaces to support transactional web services.  There is also
a lot of interest in providing XML definitions for use with ANY
transactional
system. 

> (53) Auditing. Messages should be exchanged in a 
> non-repudiable way. This
> might well tie in with identifying actor instances (40) (i.e. 
> you as an
> actor have a signature with which you sign your messages). 
> This would also
> help with avoiding message tampering.

Agreed, though probably a QOS type option for each transaction.  I would
say that messages can be exchanged in a non-repudiable way.  Any use of
non-repudiation implies use of asymmetric keys.  

> (110) There is no universal trust system in place. True. But service
> providers will provide various BTP actors which will themselves be
> "trusted." One could imagine some party offering a trusted 
> coordinator for
> example.

Right.  We will need some trust model based on what's deployed and what
people/businesses are willing to accept.  From my experience this is
some variations of islands of trust.  A party Y issues credentials to the
parties that it has an electronic relationship with.  The credentials
are used within the context of that relationship.  Each credential is
a combination of identity and either explicit or implicit capability.
Given the current participant / coordinator / sub-coordinator model we
will need to address, at least abstractly, how third parties are introduced
into a relationship.

> I'll ponder these more, but Bill Gates is about to start to 
> I'll sign off
> now :-)
> 
> Jim
> --
> Dr. James Webber
> Hewlett-Packard Arjuna Lab
> http://www.arjuna.com
> 
>