- From: tom.petch <cfinss@dial.pipex.com>
- Date: Thu, 14 Jun 2007 18:09:29 +0000
- To: "Keith Moore" <moore@cs.utk.edu>
- Cc: "Adrien de Croy" <adrien@qbik.com>, "Apps Discuss" <discuss@apps.ietf.org>, <ietf-http-wg@w3.org>
----- Original Message ----- From: "Keith Moore" <moore@cs.utk.edu> To: "tom.petch" <cfinss@dial.pipex.com> Cc: "Adrien de Croy" <adrien@qbik.com>; "Apps Discuss" <discuss@apps.ietf.org>; <ietf-http-wg@w3.org> Sent: Thursday, June 14, 2007 1:13 PM Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis > >> > >> Seems to me that the issue of securing communications and authenticating > >> or identifying parties are closely aligned, why not just have some form > >> of auth built into TLS, then we could use it for any protocol that can > >> use TLS, instead of having to implement separate auth schemes for every > >> higher protocol. > >> > >> > > TLS can do that but it does not gel with the way in which (many) organisations > > are structured. Those responsible for security, for security credentials and > > their maintenance, do not want to be ferreting around in the depths of a network > > stack, they prefer working at application and database level, a point that has > > already been alluded to in this thread. > > how exactly does sending TLS credentials involve ferreting around in the > depths of a network stack? > It doesn't:-) Those responsible for the creation and maintenance of security credentials - which I see as the major ongoing work of security - prefer to do at an application level, using appropriate databases, which are somewhat removed from the lower layers in which TLS sits. So TLS has a different set of credentials or none, which is the problem that channel binding overcomes. Tom Petch
Received on Thursday, 14 June 2007 18:27:32 UTC