Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis

["tom.petch" <[e-mail]>]

----- Original Message -----
From: "Keith Moore" <[e-mail]>
To: "tom.petch" <[e-mail]>
Cc: "Adrien de Croy" <[e-mail]>om>; "Apps Discuss" <[e-mail]>rg>;
<[e-mail]>
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