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

[Adrien de Croy <[e-mail]>]

The reason I raised it is that security and authentication / 
identification are 2 concepts that go hand in hand more often than not.

we have a plethora of auth schemes in use on the net - one per 
application protocol.  They sometimes are similar (i.e. SASL ones), but 
often are not.

TLS is a protocol that provides security of communications, and allows 
for mutual identification through certificates.

So it would make sense to solve both problems at the same time, instead 
of one with TLS, and the other with a horde of higher level 
authentication protocols.  Then it gets designed and debugged once, 
instead of once per protocol, with obvious improvements in reliability 
of implementation.

Adrien

Keith Moore wrote:
>   
>>> 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.
>>     
> maybe what I think of as "application level" is different than how you
> think of this term, but I've never heard of a client application that
> uses TLS where TLS wasn't being called by the application, and where the
> application wasn't in a position to supply credentials via TLS to the
> server.
>
> I'm not trying to be picky here.  Rather I think there's probably an
> important principle here that needs to be teased out.
>
> Keith
>
>
>