W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: HTTP working group status & issues

From: <hallam@vesuvius.ai.mit.edu>
Date: Thu, 17 Oct 96 11:13:54 -0400
Message-Id: <9610171513.AA03685@vesuvius.ai.mit.edu>
To: "Donald E. Eastlake 3rd" <dee@cybercash.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: hallam@vesuvius.ai.mit.edu

>> - security 
>>    draft-ietf-wts-shttp-03.txt 'bounced' as Proposed Standard. Most
>>    likely if it progresses at all it will go forward as Experimental,
>>    after editorial work happens (or a disclaimer gets added.)
>> 
>>    I think that the separation and lack of coordination between
>>    WTS and HTTP-WG was a serious problem, and that I should have done
>>    more to prevent this morass.
>
>Was this mis-coordination the real problem here?

I don't think that mis-coordination was an issue at all. Once security was 
separated from the main HTTP spec the end result was inevitable. S-HTTP has 
severe problems and I don't know that its possible to fix them without a very 
radical change of approach. S-HTTP is simply too complex.


>>    I believe the Internet needs documented standards-track security
>>    mechanisms for HTTP & distributed content. Perhaps we should
>>    re-charter a new group to work on standards for SSL and applet
>>    signing.

>Are you aware of the TLS working group which is aiming at a merged 
>SSL/PCT?

Where? according to the IETF the official mailing list for WTS is 
www-security@rutgers. I can find no pointer anywhere to the list where the
real discussion has been going on. I think that that is in itself a serious
problem.

Merging SSL and PCT is not a difficult matter and a good thing to do. I 
think that overall this approach has a lot to offer the Internet 
generally and may well end up rendering the IP-SEC work moot. It is
not a panacea however. Working at the transport layer prevents any
usefull interaction between the application and transport to create the
appropriate security for a particular transaction. 

I think that keeping SSL and transaction layer security separate is essential. 
If people attempt to force SSL to support application oriented features in the 
transport layer the result will be an abomination.


As part of our project I had to create a scheme to allow two web servers to be 
kept in lockstep via authenticated HTTP exchanges. It provides the functionality 
of S-HTTP with the exception of negotiation but uses only five headers instead 
of twenty, does not involve ASN.1 and has a much cleaner interface to a 
negotiation system. If anyone is interested I can finish the writeup and post 
it.

I was planning to write an active-x control and experiment with the protocol 
incorporated into a browser. If anyone has experience of implementing such a 
control or knows of an example I would be very pleased to know! Unfortunately 
Microsoft's documentation is more forthcomming on what one can do with active-x 
than how to do any of it.

If active-x makes any sense it is as a general purpose operating system level 
"component-ware" solution. If I don't like the features provided by the O/S 
provided jpeg filter or HTTP transport I swap in my own. According to the 
propaganda it should provide me with an open testbed to experiment with 
extending the protocols without having to write a browser and server. It should 
be possible for an end user to adopt my modified protocol without having to 
replace his whole browser. Unrfortunately there is a general agreement amongst 
those of us in this building that have tried to do such things that there is a 
distinct lack of concrete examples in this area.


		Phill
Received on Thursday, 17 October 1996 08:35:32 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:15 EDT