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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-security message

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


Subject: Re: solicitation for BTP security requirements


Hi Bill,

The most fundamental input should be the decision voted by the Mt Laurel meeting which was minuted as follows:

The security sub-committee will report by the end of the month with an overview of related or relevant standards work that may affect BTP in the mid-term, or that should be taken into account, or referenced, in this first version of the BTP specification. In addition it should consider what is needed (or should be avoided) in order to allow a future version of the specification to become secure. The specification document should make it clear that the first version of BTP is targeted at the intra-trust community, but has been produced with an eye to overlaying security in the future.

In fact, two features that have gone into the proposed protocol will assist in implementation-specific approaches to providing a secure version:

1) A lot of effort has gone into providing for the "single wire" environment, where two BTP-aware endpoints can accept messages which may originate and terminate with other actors (e.g. C -- superior communicator -- inferior communicator -- P). Such communicators can (by inter-party agreement) use any approach to mutual authentication, encryption, etc that might be required. The BTP protocol lays on them the responsibility of message transmission (and a little bit more) but does not exclude any more sophisticated behaviour

2) The provision of free space for application data in protocol messages (in the shape of proprietary qualifiers) also allows adornment with any information that a secure scheme may require.

In my view this is exactly the kind of pragmatic approach that will enable the use of inter-organizational authenticated links, without loading up BTP V1.0 with a full interoperable security scheme, which will assuredly delay the protocol beyond any useful date of adoption.

Obviously what happens with a future version of BTP is another question.

Cheers,

Alastair

Bill Pope wrote:

Currently we have the start of an issues paper for BTP security.
Seems like time to get the security requirements down so we can
agree on what we're addressing.

I'm willing to accept brain dumps and then structure the input
into a document.  Anyone have any input?

=bill

William Z Pope                                    Bowstreet
+1 603 559 1538                           One Harbour Place
bpope@bowstreet.com                 Portsmouth NH 03801 USA



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


Powered by eList eXpress LLC