W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2002

RE: D-AR006.7 discussion points

From: Joseph Hui <Joseph.Hui@exodus.net>
Date: Tue, 7 May 2002 15:23:35 -0700
Message-ID: <45258A4365C6B24A9832BFE224837D551D1BEE@SJDCEX01.int.exodus.net>
To: "Timothy N. Jones" <tim@crossweave.com>, <www-ws-arch@w3.org>
> -----Original Message-----
> From: Timothy N. Jones [mailto:tim@crossweave.com]
> Sent: Tuesday, May 07, 2002 2:40 PM
> To: Joseph Hui; www-ws-arch@w3.org
> Subject: RE: D-AR006.7 discussion points
> > > CrossWeave: This implies an implementation of authentication,
> > > integrity, and/or
> > > confidentiality.  We shouldn't be prescribing implementations.
> > I don't understand how C-AR006.7 could be interpreted this way.
> It assumes that the implementation of these features will be 
> based upon
> public key encryption, which may well be true but is outside 
> the scope of
> the architectural requirement.  The security WG or whatever 
> should be the
> one to decide what specific technologies to use.

Interesting explanation.

Nonetheless, prescribing implementations for the three sec
aspects you mentioned would be like specifying: client is
to ask server for a certificating for _Authc_ before
application data transfer; use SHA-1 (or MD5) for _Integrity_,
use AES ciphers for _Confidentiality_.  D-AR006.7 doesn't
state nor imply any of such.  I.e. to do Key Management (KM)
doesn't mean to prescribe implementations for Authc, Int, and Confi.

So, to the WG, the issue at hand is whether KM should be in
or out of scope.

Joe Hui
Exodus, a Cable & Wireless service
Received on Tuesday, 7 May 2002 18:23:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:56 UTC